whitebit-exchange · mintlify · May 25, 2026
diff --git a/concepts/balances.mdx b/concepts/balances.mdx
@@ -64,9 +64,9 @@
 
 ## Deposit flow
 
-1. Generate a deposit address. Use `POST /api/v4/main-account/create-new-address` ([API Reference](/api-reference/account-wallet/create-new-address-for-deposit)) to generate a unique address per request, or `POST /api/v4/main-account/address` ([API Reference](/api-reference/deposits/get-deposit-address)) to retrieve a persistent reusable address. Alternatively, create an address through the platform UI.
+1. Generate a deposit address. Use `POST /api/v4/main-account/create-new-address` ([API Reference](/api-reference/account-wallet/create-new-address-for-deposit)) to generate a unique address per request, or `POST /api/v4/main-account/address` ([API Reference](/api-reference/account-wallet/get-cryptocurrency-deposit-address)) to retrieve a persistent reusable address. Alternatively, create an address through the platform UI.
 2. Send crypto to the generated address.
 3. Funds arrive in Main balance after blockchain confirmations. Confirmation requirements vary by asset.
 4. Transfer from Main to Trade (for spot orders) or to Collateral (for margin/futures positions).

 ## Withdrawal flow
@@ -77,7 +77,7 @@
 4. Withdrawal processes after security checks complete.

 <Note>
  **EEA users:** Crypto withdrawals require a `travelRule` object with beneficiary
  information (name, address, VASP). Deposits may be held for Travel Rule
  verification (status codes 27, 28). See [Regulatory Compliance](/institutional/compliance)
  for full details.

diff --git a/guides/broker-guide.mdx b/guides/broker-guide.mdx
@@ -8,7 +8,7 @@

 <RegionBaseUrl />

 The WhiteBIT Broker Program enables trading platforms and fintechs to offer WhiteBIT exchange access to end users. Brokers earn up to **40% of trading fees** generated by referred customers. Each customer trades from a dedicated sub-account under the broker's master account, with fee-free internal transfers and per-customer API keys.

 ## Broker Program overview

@@ -52,13 +52,13 @@

 ## Customer onboarding flow

 Each end customer is onboarded as a sub-account under the broker's master account.

 <Steps>
   <Step title="Create a sub-account">
     Call the sub-account creation endpoint to create a new sub-account for the customer. Each sub-account receives an independent balance and can have dedicated API keys.
 
-    **Endpoint:** `POST /api/v4/sub-account/create` — [API Reference](/api-reference/sub-accounts/create)
+    **Endpoint:** `POST /api/v4/sub-account/create` — [API Reference](/api-reference/sub-accounts/create-sub-account)
   </Step>
   <Step title="Generate a KYC verification URL">
     Generate a KYC URL for the sub-account holder. The end customer completes KYC verification through the WhiteBIT interface (WhiteBIT-branded, not white-label).
@@ -167,7 +167,7 @@
 
 **Fee-free transfers:**
 
-Transfer funds between the master account and any sub-account without fees using `POST /api/v4/sub-account/transfer` — see the [API Reference](/api-reference/sub-accounts/transfer).
+Transfer funds between the master account and any sub-account without fees using `POST /api/v4/sub-account/transfer` — see the [API Reference](/api-reference/sub-accounts/sub-account-transfer).
 
 - Master to sub-account: funding a customer account
 - Sub-account to master: revenue collection
@@ -216,7 +216,7 @@

 European broker end users frequently expect EUR deposit and withdrawal capabilities.

 Fiat operations (EUR/SEPA) require institutional onboarding with fiat access approval. The broker's master account must complete the two-phase onboarding process (crypto access via KYB, then fiat access via fiat processing partner review). Once fiat access is approved on the master account, sub-accounts can process fiat deposits and withdrawals.

 See [Institutional Onboarding](/institutional/onboarding) for the two-phase process. See [Payment Integration](/guides/payment-integration) for fiat endpoint details.


diff --git a/guides/integration-paths.mdx b/guides/integration-paths.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Integration Paths"
 description: "Find the recommended integration path for each partner type — market makers, brokers, algo traders, payment providers, prop trading firms, and institutional clients."
 sidebarTitle: "Integration Paths"
 ---

@@ -8,13 +8,13 @@

 <RegionBaseUrl />

 WhiteBIT supports six partner types: market makers, brokers, algo traders, payment providers, prop trading firms, and institutional clients. Each section lists the program terms, the relevant endpoints, and the next guide to read.

 ## Market makers

 Professional market-making firms benefit from the [Market-Making Program](https://institutional.whitebit.com/market-making-program), which offers maker rebates up to -0.012%, [colocation](/platform/colocation) infrastructure in Frankfurt and Tokyo (3-5ms latency), and [bulk order](/api-reference/spot-trading/bulk-limit-order) capabilities (up to 20 orders per call). The program includes a dedicated account manager and cross-marketing support.

 For the complete integration walkthrough, see the [Market Maker Guide](/guides/market-maker-guide).

 ## Brokers and trading platforms

@@ -22,9 +22,9 @@

 Brokers that need to issue per-customer API keys via OAuth (alongside or instead of the sub-account model) can use the [Fast API Key via OAuth](/guides/fast-api-key-via-oauth) flow to bootstrap keys on behalf of users without manual copy-paste.

 For the complete integration walkthrough, see the [Broker Guide](/guides/broker-guide).

 ## Algo trading and bot providers

 Algorithmic trading systems and trading bots integrate through a combination of REST API for order management and WebSocket for real-time market data.

@@ -33,19 +33,19 @@
 **Key technical considerations:**
 
 - [Rate limits](/api-reference/rate-limits): polling frequency must stay within per-endpoint limits; WebSocket streaming is recommended for real-time data to reduce REST polling
-- [Kill-switch](/api-reference/spot-trading/kill-switch): emergency mechanism to cancel all open orders after a configurable timeout — critical safety feature for unattended bots
+- [Kill-switch](/api-reference/spot-trading/sync-kill-switch-timer): emergency mechanism to cancel all open orders after a configurable timeout — critical safety feature for unattended bots
 - [Order Types](/concepts/order-types): Market, Limit, Stop-Limit, Stop-Market, Stock-Market, and Bulk-Limit — availability varies by market type
 - [Client Order ID](/guides/client-order-id): attach custom identifiers to orders for tracking across systems
 
 **Infrastructure recommendations:**
 
 - Use [sub-accounts](/products/sub-accounts/overview) for strategy separation when running multiple bots
 - Consider [colocation](/platform/colocation) (3-5ms latency) for latency-sensitive strategies
-- Implement the [kill-switch](/api-reference/spot-trading/kill-switch) as a circuit breaker for all production bots
+- Implement the [kill-switch](/api-reference/spot-trading/sync-kill-switch-timer) as a circuit breaker for all production bots
 - Set up [Account Monitoring](/guides/account-monitoring) for balance tracking, deposit/withdrawal alerts, and order activity monitoring
 
 <Note>
  WhiteBIT does not offer a public testnet. Test all trading flows on the live API with minimum order amounts. Use `GET /api/v4/public/markets` to find pairs with the lowest minimum order sizes for testing.
 </Note>

 ## Payment and ramp providers
@@ -58,7 +58,7 @@

 **Key considerations:**

 - [Travel Rule](/institutional/compliance): EEA crypto withdrawals require a `travelRule` object with beneficiary information
 - MiCA compliance: USDT operations are restricted for EEA users since December 30, 2024 — use USDC or EURI as alternatives
 - [Webhook signature verification](/platform/webhook): validate HMAC-SHA512 on all incoming webhooks
 - [Currency conversion](/platform/convert): when the held currency differs from the withdrawal currency, use the Convert feature with a Main → Trade → Convert → Trade → Main transfer pattern — see [Payment Integration](/guides/payment-integration) for the full flow
@@ -67,7 +67,7 @@

 - Primary: webhook-based notifications for deposits and withdrawals
 - Fallback: poll the deposit/withdraw history endpoint for reconciliation
 - Deduplication: use `uniqueId` across both channels
 - See the [Payment Integration](/guides/payment-integration) guide for the full reconciliation strategy

 ## Prop trading firms
@@ -90,7 +90,7 @@

 ## Institutional clients

 Institutional clients — hedge funds, asset managers, family offices, banks, fintechs, and exchanges — access the institutional product catalog through institutional onboarding. The onboarding process covers KYB verification, fiat access approval, and dedicated account management.

 The institutional product catalog includes OTC Trading, Portfolio Margin (200,000 USDT minimum), Crypto-as-a-Service (CaaS), Wallet-as-a-Service (WaaS), and Custody solutions. See the [Institutional Overview](/institutional/overview) for the full product matrix and the [Institutional Onboarding](/institutional/onboarding) guide for the step-by-step process.

@@ -101,7 +101,7 @@
 | Use case | Recommended | Reason |
 |----------|------------|--------|
 | Live prices | WebSocket (`lastprice` channel) | No polling needed; instant updates |
 | Orderbook depth | WebSocket (`depth` channel) | Real-time depth snapshots |
 | Place / modify / cancel orders | REST API | Request-response pattern with confirmation |
 | Monitor balances | WebSocket (`balanceSpot` / `balanceCollateral`) | Real-time balance changes |
 | Fetch historical trades | REST API | One-time queries, paginated |
@@ -116,6 +116,6 @@
    Make a first authenticated API call in 5 minutes.
  </Card>
  <Card title="SDKs" icon="code" href="/sdks">
    Official SDKs in Go, Python, and PHP.
  </Card>
 </CardGroup>
diff --git a/guides/payment-integration.mdx b/guides/payment-integration.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Payment Integration"
 description: "Complete guide to crypto deposits, withdrawals, withdrawals with currency conversion, fiat SEPA operations, and WhiteBIT Codes — including status state machines, fee calculation, and webhook reconciliation."
 sidebarTitle: "Payment Integration"
 ---

@@ -8,7 +8,7 @@

 <RegionBaseUrl />

 The Payment Integration guide covers every step required to move funds into and out of WhiteBIT programmatically — crypto deposits, crypto withdrawals, crypto withdrawals with currency conversion, fiat (SEPA) operations, and WhiteBIT Codes. Each section includes the full transaction lifecycle, status state machine, fee calculation, and webhook events.

 <Warning>
  **EEA users:** USDT deposits and withdrawals are not available since December 30, 2024 (MiCA compliance). Use USDC or EURI as alternatives. See [Regulatory Compliance](/institutional/compliance) for details.
@@ -19,14 +19,14 @@
 
 ## Deposit address generation
 
-Generate a deposit address by calling `POST /api/v4/main-account/address`. See the [API Reference](/api-reference/deposits/get-deposit-address) for the full endpoint specification.
+Generate a deposit address by calling `POST /api/v4/main-account/address`. See the [API Reference](/api-reference/account-wallet/get-cryptocurrency-deposit-address) for the full endpoint specification.
 
 **Required parameters:**
 
 | Parameter | Type | Description |
 |-----------|------|-------------|
 | `ticker` | string | Currency ticker (e.g., `BTC`, `ETH`). The currency must have `can_deposit: true` in the [Asset Status](/api-reference/market-data/asset-status-list) response. |
 | `network` | string | Cryptocurrency network (e.g., `ERC20`, `TRC20`). Required for multi-network currencies like USDT. Query the [Asset Status](/api-reference/market-data/asset-status-list) endpoint for available networks per currency. |

 The endpoint returns the same address for the same ticker and network combination on repeated calls — addresses are permanent and reusable, not ephemeral.

@@ -120,7 +120,7 @@
 | Parameter | Type | Description |
 |-----------|------|-------------|
 | `ticker` | string | Currency ticker (e.g., `BTC`, `ETH`) |
 | `network` | string | Cryptocurrency network (e.g., `ERC20`, `TRC20`). Required for multi-network currencies. |

 **Rate limit:** 1,000 requests per 10 seconds.

@@ -164,7 +164,7 @@
 After funds arrive at a generated deposit address, the deposit passes through a defined sequence of states before crediting to the Main balance.

 1. Address generated (`POST /api/v4/main-account/address`)
 2. Funds sent by the external party — mempool detection begins
 3. Confirmation tracking begins — `deposit.accepted` webhook fires, `confirmations.actual` < `confirmations.required`
 4. Confirmations reach the required threshold — `deposit.updated` webhook fires with updated `confirmations.actual`
 5. Deposit credited to Main balance — `deposit.processed` webhook fires — **terminal success state**
@@ -193,11 +193,11 @@

 ## Network confirmations

 Each cryptocurrency network requires a different number of block confirmations before a deposit is credited.

 Webhook payloads include `confirmations.actual` and `confirmations.required` fields — use the `confirmations.required` value to determine when the deposit will complete. Query the [Asset Status](/api-reference/market-data/asset-status-list) endpoint (`GET /api/v4/public/assets`) for per-currency confirmation requirements.

 Confirmation requirements vary by currency and network. Do not hardcode specific numbers — always retrieve the current values from the Asset Status endpoint.

 ## Required endpoints for deposits

@@ -210,12 +210,12 @@
 | `POST /api/v4/main-account/fee` | Available currencies, networks, and deposit limits | [Get Fees](/api-reference/account-wallet/get-fees) |
 
 <Note>
-  For integrations that use a single persistent deposit address instead of unique addresses per user, substitute `POST /api/v4/main-account/address` ([API Reference](/api-reference/deposits/get-deposit-address)) for the `/create-new-address` endpoint.
+  For integrations that use a single persistent deposit address instead of unique addresses per user, substitute `POST /api/v4/main-account/address` ([API Reference](/api-reference/account-wallet/get-cryptocurrency-deposit-address)) for the `/create-new-address` endpoint.
 </Note>
 
 ## Travel Rule (EEA and Turkey)

 Since May 19, 2025, inbound crypto deposits for EEA and Turkey accounts are placed on hold until Travel Rule verification completes.

 - **Status 27** (`DEPOSIT_TRAVEL_RULE_FROZEN`): deposit frozen, awaiting Travel Rule data from the account holder
 - **Status 28** (`DEPOSIT_TRAVEL_RULE_FROZEN_PROCESSING`): Travel Rule data submitted, under review by WhiteBIT
@@ -231,7 +231,7 @@
 
 ## Create a withdrawal
 
-Submit a crypto withdrawal by calling `POST /api/v4/main-account/withdraw`. See the [API Reference](/api-reference/withdrawals/create-withdraw) for the full endpoint specification.
+Submit a crypto withdrawal by calling `POST /api/v4/main-account/withdraw`. See the [API Reference](/api-reference/account-wallet/create-withdraw-request) for the full endpoint specification.
 
 Two withdrawal endpoints are available:
 
@@ -288,7 +288,7 @@

 ## Travel Rule for EEA withdrawals

 Crypto withdrawals from EEA accounts require a `travelRule` object in the request body. The `travelRule` object is required when the currency is crypto AND the account is from the EEA.

 | Field | Type | Description |
 |-------|------|-------------|
@@ -419,7 +419,7 @@
 
 When a deposit is canceled (status 4 or 9), a refund may be available.
 
-**Endpoint:** `POST /api/v4/main-account/refund-deposit` — see the [API Reference](/api-reference/deposits/refund-deposit) for the full specification.
+**Endpoint:** `POST /api/v4/main-account/refund-deposit` — see the [API Reference](/api-reference/account-wallet/refund-deposit) for the full specification.
 
 **Prerequisites:**
 
@@ -471,7 +471,7 @@
 | Endpoint | Purpose | API Reference |
 |----------|---------|---------------|
 | `POST /api/v4/main-account/balance` | Check Main balance before withdrawal | [Main Balance](/api-reference/account-wallet/main-balance) |
-| `POST /api/v4/main-account/withdraw` or `/withdraw-pay` | Create a withdrawal request | [Create Withdraw](/api-reference/withdrawals/create-withdraw) |
+| `POST /api/v4/main-account/withdraw` or `/withdraw-pay` | Create a withdrawal request | [Create Withdraw](/api-reference/account-wallet/create-withdraw-request) |
 | Webhooks (`withdraw.unconfirmed`, `withdraw.pending`, `withdraw.successful`, `withdraw.canceled`) | Withdrawal status notifications | [Webhooks](/platform/webhook) |
 | `POST /api/v4/main-account/history` | Query deposit and withdrawal history | [History](/api-reference/account-wallet/get-deposit-withdraw-history) |
 | `POST /api/v4/main-account/fee` | Available currencies, networks, and withdrawal limits | [Get Fees](/api-reference/account-wallet/get-fees) |
@@ -491,11 +491,11 @@
  Fiat operations require completion of institutional onboarding including KYB verification and fiat provider approval. See [Institutional Onboarding](/institutional/onboarding) for the full two-phase process. Fiat endpoints are not available until fiat access is explicitly approved.
 </Warning>

 The onboarding process has two phases: Phase 1 (crypto access via KYB) and Phase 2 (fiat access via fiat processing partner review). Fiat access is NOT automatic after KYB approval — a separate review process with the fiat processing partner is required.
 
 ## Fiat deposit (SEPA)
 
-Generate a fiat deposit invoice by calling `POST /api/v4/main-account/fiat-deposit-url`. See the [API Reference](/api-reference/deposits/fiat-deposit-url) for the full specification.
+Generate a fiat deposit invoice by calling `POST /api/v4/main-account/fiat-deposit-url`. See the [API Reference](/api-reference/account-wallet/get-fiat-deposit-address) for the full specification.
 
 <Note>
   The fiat deposit endpoint works on demand. Contact WhiteBIT support and provide the API key to get access.
@@ -520,7 +520,7 @@

 ## Fiat withdrawal (SEPA)

 Create a fiat withdrawal using the same `POST /api/v4/main-account/withdraw` endpoint used for crypto, specifying a fiat ticker.

 The same withdrawal endpoints apply (`/withdraw` and `/withdraw-pay`). Use fiat-specific tickers such as `EUR`, `UAH_IBAN`, `USD_VISAMASTER`, `EUR_VISAMASTER`.

@@ -557,7 +557,7 @@
 |-----------|------|----------|-------------|
 | `ticker` | string | Yes | Currency ticker (e.g., `BTC`, `ETH`) |
 | `amount` | string | Yes | Amount to transfer (max precision: 8) |
 | `passphrase` | string | No | Passphrase for protection (up to 25 characters, latin letters, numbers, and symbols) |
 | `description` | string | No | Description visible only to the creator (up to 75 characters) |

 Rate limit: 1,000 requests per 10 seconds.
@@ -608,7 +608,7 @@
  <Tab title="Python">
    ```python
    # Create a WhiteBIT Code
    create_response = send_request("/api/v4/main-account/codes", {
        "ticker": "USDT",
        "amount": "100",
        "passphrase": "securePass123",
@@ -669,13 +669,13 @@
   <Step title="Create withdrawal request">
     Submit a withdrawal to the end user's external address.
 
-    **Endpoint:** `POST /api/v4/main-account/withdraw` or `POST /api/v4/main-account/withdraw-pay` — [API Reference](/api-reference/withdrawals/create-withdraw)
+    **Endpoint:** `POST /api/v4/main-account/withdraw` or `POST /api/v4/main-account/withdraw-pay` — [API Reference](/api-reference/account-wallet/create-withdraw-request)
   </Step>
   <Step title="Receive webhook confirmation">
     The `withdraw.successful` webhook fires when the withdrawal completes. See [Webhooks](/platform/webhook) for setup and signature verification.
  </Step>
  <Step title="Verify via history">
    Query the history endpoint with `transactionMethod: 2` to confirm the withdrawal status. See the Crypto Withdrawals tab for the full status state machine.

    **Endpoint:** `POST /api/v4/main-account/history` — [API Reference](/api-reference/account-wallet/get-deposit-withdraw-history)
  </Step>
@@ -687,7 +687,7 @@

 ## Code example

 Convert USDT to BTC and withdraw BTC to an external address. The `send_request()` helper used below is defined in the Crypto Deposits tab.

 <Tabs>
  <Tab title="Python">
@@ -827,7 +827,7 @@
 | `POST /api/v4/convert/estimate` | Request a conversion quote | [Convert Estimate](/api-reference/convert/convert-estimate) |
 | `POST /api/v4/convert/confirm` | Confirm and execute a conversion | [Convert Confirm](/api-reference/convert/convert-confirm) |
 | `GET /api/v4/public/markets` | Available markets and trading limits | [Market Info](/api-reference/market-data/market-info) |
-| `POST /api/v4/main-account/withdraw` | Create a withdrawal request | [Create Withdraw](/api-reference/withdrawals/create-withdraw) |
+| `POST /api/v4/main-account/withdraw` | Create a withdrawal request | [Create Withdraw](/api-reference/account-wallet/create-withdraw-request) |
 | Webhooks (`withdraw.successful`) | Withdrawal status notifications | [Webhooks](/platform/webhook) |
 | `POST /api/v4/main-account/history` | Query deposit and withdrawal history | [History](/api-reference/account-wallet/get-deposit-withdraw-history) |
 | `POST /api/v4/main-account/fee` | Currencies, networks, and withdrawal limits | [Get Fees](/api-reference/account-wallet/get-fees) |
@@ -854,7 +854,7 @@
 - Recommended polling interval: every 5 minutes for active monitoring
 - Rate limit: 200 requests per 10 seconds

 **Deduplication:** Use the `uniqueId` from webhook payloads and history responses to deduplicate across webhook and polling paths.

 <Note>
  WhiteBIT does not offer a webhook replay mechanism. Implement polling as a fallback for outages longer than 50 minutes. Store all processed `uniqueId` values to prevent double-processing.
@@ -863,7 +863,7 @@
 **Reconciliation pattern:**

 1. Receive webhook — verify signature — extract `uniqueId` and `status`
 2. Store the event with `uniqueId` as the idempotency key
 3. On polling cycle: query the history endpoint — compare `uniqueId` values against stored events
 4. Process any events found via polling that the webhook path did not deliver
 5. Mark transactions as complete only when a terminal status is reached (3/7 for success, 4/9 for canceled deposits, 4 for canceled withdrawals)

diff --git a/platform/webhook.mdx b/platform/webhook.mdx
@@ -53,7 +53,7 @@
 | Recommended for | Production payment flows | Fallback during outages > 50 minutes |
 
 <Note>
-  There is no webhook replay mechanism. If the consumer server is unreachable for more than 50 minutes (5 retries x 10-minute intervals), those events are lost. Implement polling of the [deposit history](/api-reference/account-wallet/get-deposit-history) and [withdrawal history](/api-reference/account-wallet/get-withdrawal-history) endpoints as a fallback.
+  There is no webhook replay mechanism. If the consumer server is unreachable for more than 50 minutes (5 retries x 10-minute intervals), those events are lost. Implement polling of the [deposit history](/api-reference/account-wallet/get-deposit-withdraw-history) and [withdrawal history](/api-reference/account-wallet/get-deposit-withdraw-history) endpoints as a fallback.
 </Note>
 
 **Common use cases:**
@@ -261,7 +261,7 @@

 For EEA users, deposits may be frozen pending Travel Rule verification. When a deposit is frozen, the webhook delivers deposit.updated events with Travel Rule-specific status codes. The end user must complete Travel Rule verification through the WhiteBIT platform UI — the partner cannot submit Travel Rule data via API.

 For details on Travel Rule requirements and the travelRule object for withdrawals, see [Regulatory Compliance](/institutional/compliance).

 Deposit status codes: