> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Find answers to common questions about the WhiteBIT API, trading, deposits and withdrawals, webhooks, institutional onboarding, compliance, and integration.

export const RegionBaseUrl = ({className = "", showBaseUrl = true, protocol = "https"}) => {
  const {useState, useEffect, useRef} = React;
  const EU_ENABLED = false;
  const [region, setRegionState] = useState(() => {
    if (!EU_ENABLED) return "com";
    if (typeof window !== 'undefined') {
      return localStorage.getItem("api-region-preference") || "com";
    }
    return "com";
  });
  const [mounted, setMounted] = useState(false);
  const observerRef = useRef(null);
  const isSyncingRef = useRef(false);
  const updateAllContentOnPage = targetRegion => {
    try {
      const domainFrom = targetRegion === "eu" ? "whitebit.com" : "whitebit.eu";
      const domainTo = targetRegion === "eu" ? "whitebit.eu" : "whitebit.com";
      const links = document.querySelectorAll('a');
      links.forEach(link => {
        let href = link.getAttribute('href');
        if (href && href.includes(domainFrom)) {
          link.setAttribute('href', href.replace(domainFrom, domainTo));
        }
      });
      const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT, {
        acceptNode: node => {
          if (node.parentElement?.closest('.region-toggle-component')) {
            return NodeFilter.FILTER_REJECT;
          }
          return node.textContent.includes(domainFrom) ? NodeFilter.FILTER_ACCEPT : NodeFilter.FILTER_REJECT;
        }
      });
      let currentNode;
      while (currentNode = walker.nextNode()) {
        currentNode.textContent = currentNode.textContent.replace(new RegExp(domainFrom, 'g'), domainTo);
      }
      console.log(`[RegionSync] Global content updated to ${domainTo}`);
    } catch (e) {
      console.error("[RegionSync] Error updating content:", e);
    }
  };
  const updateRegion = (newRegion, source) => {
    if (region === newRegion) return;
    console.log(`[RegionBaseUrl] Updating to "${newRegion}" (Source: ${source})`);
    if (source === 'observer') {
      isSyncingRef.current = true;
      setTimeout(() => isSyncingRef.current = false, 1000);
    }
    setRegionState(newRegion);
    localStorage.setItem("api-region-preference", newRegion);
    updateAllContentOnPage(newRegion);
    if (source === 'user-click') {
      window.dispatchEvent(new CustomEvent("regionChange", {
        detail: newRegion
      }));
      attemptToUpdateNativeDropdown(newRegion, 0);
      setTimeout(() => attemptToUpdateNativeDropdown(newRegion, 1), 500);
      setTimeout(() => attemptToUpdateNativeDropdown(newRegion, 2), 1500);
    }
  };
  const attemptToUpdateNativeDropdown = (targetRegion, attempt) => {
    if (isSyncingRef.current) return;
    try {
      const targetUrl = targetRegion === "eu" ? "https://whitebit.eu" : "https://whitebit.com";
      const targetDesc = targetRegion === "eu" ? "EU Server" : "Production Server";
      const selects = document.querySelectorAll('select');
      for (const select of selects) {
        if (select.innerHTML.includes('whitebit.com') || select.innerHTML.includes('whitebit.eu')) {
          select.value = targetUrl;
          select.dispatchEvent(new Event('change', {
            bubbles: true
          }));
          return;
        }
      }
      const buttons = Array.from(document.querySelectorAll('button, [role="combobox"]'));
      const serverSelector = buttons.find(btn => {
        if (btn.closest('a') || btn.closest('[class*="card"]') || btn.closest('nav')) {
          return false;
        }
        const txt = btn.textContent || "";
        const isServerDropdown = (txt.includes('Production Server') || txt.includes('EU Server') || txt.includes('WhiteBIT Global Server') || txt.includes('WhiteBIT EU Server')) && !txt.includes('Run') && !txt.includes('Send') || btn.getAttribute('role') === 'combobox';
        return isServerDropdown;
      });
      if (serverSelector) {
        const currentText = serverSelector.textContent || "";
        if (currentText.includes(targetDesc)) return;
        serverSelector.click();
        setTimeout(() => {
          const options = document.querySelectorAll('[role="option"], li, button');
          for (const opt of options) {
            const optText = opt.textContent || "";
            if (optText.includes(targetDesc) || optText.includes(targetUrl)) {
              opt.click();
              return;
            }
          }
        }, 100);
      }
    } catch (e) {
      console.error("[Sync] Error:", e);
    }
  };
  useEffect(() => {
    if (!EU_ENABLED) return;
    setMounted(true);
    updateAllContentOnPage(region);
    const handleStorageChange = e => {
      if (e.key === "api-region-preference" && e.newValue) {
        updateRegion(e.newValue, 'storage');
      }
    };
    const handleRegionChange = e => {
      if (e.detail !== region) {
        updateRegion(e.detail, 'event');
      }
    };
    window.addEventListener("storage", handleStorageChange);
    window.addEventListener("regionChange", handleRegionChange);
    observerRef.current = new MutationObserver(mutations => {
      if (isSyncingRef.current) return;
      updateAllContentOnPage(region);
      for (const mutation of mutations) {
        if (mutation.type !== 'childList' && mutation.type !== 'characterData') continue;
        const target = mutation.target;
        const el = target.nodeType === Node.TEXT_NODE ? target.parentElement : target;
        if (el && (el.getAttribute('role') === 'option' || el.closest('[role="listbox"]'))) continue;
        const text = target.textContent || "";
        if (text.includes('WhiteBIT EU Server') || text.includes('https://whitebit.eu') && text.includes('Server')) {
          if (el && el.tagName !== 'A' && !el.closest('.region-toggle-component')) {
            if (region !== 'eu') updateRegion('eu', 'observer');
          }
        } else if (text.includes('WhiteBIT Global Server') || text.includes('https://whitebit.com') && text.includes('Server')) {
          if (el && el.tagName !== 'A' && !el.closest('.region-toggle-component')) {
            if (region !== 'com') updateRegion('com', 'observer');
          }
        }
      }
    });
    observerRef.current.observe(document.body, {
      childList: true,
      subtree: true,
      characterData: true
    });
    if (typeof window !== 'undefined') {
      const current = localStorage.getItem("api-region-preference");
      if (current) attemptToUpdateNativeDropdown(current, 'init');
    }
    return () => {
      window.removeEventListener("storage", handleStorageChange);
      window.removeEventListener("regionChange", handleRegionChange);
      if (observerRef.current) observerRef.current.disconnect();
    };
  }, [region]);
  const apiBaseUrl = protocol === "wss" ? region === "eu" ? "wss://api.whitebit.eu/ws" : "wss://wss.whitebit.com/ws" : region === "eu" ? "https://whitebit.eu" : "https://whitebit.com";
  const baseUrlLabel = protocol === "wss" ? "WebSocket URL" : "Base URL";
  if (!EU_ENABLED) {
    if (!showBaseUrl) return null;
    return <div className={`flex items-center gap-2 flex-wrap my-4 region-toggle-component ${className}`}>
                <span className="text-sm text-gray-500 dark:text-gray-400 font-mono">
                    {baseUrlLabel}
                </span>
                <span className="text-sm text-gray-400">:</span>
                {protocol === "wss" ? <code className="text-sm font-mono text-primary dark:text-primary-light">
                        {apiBaseUrl}
                    </code> : <a href={apiBaseUrl} target="_blank" rel="noopener noreferrer" className="text-sm font-mono text-primary dark:text-primary-light hover:underline">
                        {apiBaseUrl}
                    </a>}
            </div>;
  }
  if (!mounted) return null;
  return <div className={`flex items-center gap-2 flex-wrap my-4 region-toggle-component ${className}`}>
            <span className="text-sm text-gray-500 dark:text-gray-400 font-mono">
                {baseUrlLabel}
            </span>
            <span className="text-sm text-gray-400">(</span>
            <div className="inline-flex bg-gray-100 dark:bg-gray-800 rounded-lg p-0.5 border border-gray-200 dark:border-gray-700">
                <button onClick={() => updateRegion("com", "user-click")} className={`px-2 py-0.5 text-xs font-medium rounded-md transition-all ${region === "com" ? "bg-white dark:bg-gray-700 text-gray-900 dark:text-gray-100 shadow-sm" : "text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-200"}`}>
                    .com
                </button>
                <button onClick={() => updateRegion("eu", "user-click")} className={`px-2 py-0.5 text-xs font-medium rounded-md transition-all ${region === "eu" ? "bg-white dark:bg-gray-700 text-gray-900 dark:text-gray-100 shadow-sm" : "text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-200"}`}>
                    .eu
                </button>
            </div>
            <span className="text-sm text-gray-400">)</span>
            {showBaseUrl && <>
                    <span className="text-sm text-gray-400">:</span>
                    {protocol === "wss" ? <code className="text-sm font-mono text-primary dark:text-primary-light">
                            {apiBaseUrl}
                        </code> : <a href={apiBaseUrl} target="_blank" rel="noopener noreferrer" className="text-sm font-mono text-primary dark:text-primary-light hover:underline">
                            {apiBaseUrl}
                        </a>}
                </>}
        </div>;
};

<RegionBaseUrl />

## Rate limits and errors

<AccordionGroup>
  <Accordion title="Rate limit 429 errors">
    Rate limit 429 errors occur when an endpoint exceeds the rate limit. To resolve:

    * Wait for the rate limit window to reset
    * Check the specific rate limit value in the endpoint documentation
    * Implement rate limiting in code

    For more details, see the [API v4 overview](/api-reference/market-data/overview).
  </Accordion>

  <Accordion title="CORS errors on ticker endpoint">
    CORS requests to the ticker endpoint are forbidden for security reasons. Make the request from a backend server instead of client-side code. For endpoint details, see the [Market activity endpoint](/api-reference/market-data/market-activity).
  </Accordion>

  <Accordion title="Nonce error troubleshooting">
    Nonce errors occur when timestamps or request ordering are invalid. To resolve:

    1. Debug the code implementation
    2. Recreate API keys
    3. Ensure system time is properly synchronized

    For details on nonce requirements, see the [Authentication guide](/api-reference/authentication). For full details on HMAC-SHA512 signing and nonce requirements, see [Authentication](/api-reference/authentication).
  </Accordion>

  <Accordion title="Lending (Smartplan) endpoint 403 access errors">
    Lending endpoints require B2B partner permissions. This applies to both Fixed (`/api/v4/main-account/smart/`) and Flex (`/api/v4/main-account/smart-flex/`) endpoints. Until access is granted, these endpoints return `403` with the message `You don't have permission to use this endpoint. Please contact support for more details`. To gain access:

    * Fill the institutional services form at [https://whitebit.com/institutional-services/b2b](https://whitebit.com/institutional-services/b2b)
    * Provide use case details

    For endpoint details, see the [Crypto Lending documentation](/api-reference/account-wallet/get-plans).
  </Accordion>

  <Accordion title="Common API error codes quick reference">
    The most frequent API errors and corresponding causes: `422` — validation failed (check required parameters); `429` — rate limit exceeded (wait for window reset); `401` — authentication failed (check API key and HMAC signature); `403` — insufficient permissions (verify API key permissions). See [Errors and Error Handling](/api-reference/rate-limits) for the complete error code reference.
  </Accordion>
</AccordionGroup>

## WebSocket

<AccordionGroup>
  <Accordion title="Multiple time periods in WebSocket Kline">
    Multiple time periods for pairs are available through multiple WebSocket connections or the HTTP method. Two solutions:

    1. Open multiple WebSocket connections
    2. Use the equivalent HTTP method instead

    For more details, see the [Kline documentation](/websocket/market-streams/kline).
  </Accordion>

  <Accordion title="Trade history limitations (24-hour window)">
    The system shows only the last 100 deals by default. To access more:

    * Subscribe to the WebSocket feed
    * Accumulate and store the data
    * Process the data as needed

    For more details, see the [Trades channel documentation](/websocket/market-streams/trades).
  </Accordion>

  <Accordion title="Server locations and colocation regions">
    WhiteBIT offers colocation across EEA/EMEA and APAC regions. Colocation provides access to a subset of 35 trading endpoints. See [Colocation](/platform/colocation) for infrastructure details and the [Market Maker Guide](/guides/market-maker-integration) for the full endpoint list.
  </Accordion>
</AccordionGroup>

## Transfers and withdrawals

<AccordionGroup>
  <Accordion title="Transfer delays between balances">
    Transfers may take up to 2 seconds to complete. When making transfers and withdrawals:

    * Wait for transfers to complete (approximately 2 seconds)
    * Avoid initiating withdrawals before transfer completion
    * Implement proper error handling for transfer states

    For endpoint details, see the [Transfer between balances](/api-reference/account-wallet/transfer-between-balances) documentation. For details on account types (Main, Trade, Collateral), see [Balances & Transfers](/concepts/balances).
  </Accordion>

  <Accordion title="Insufficient funds errors despite available balance">
    Withdrawal amount plus fee must not exceed the available balance. Calculate the total required using the [fee endpoint](/api-reference/account-wallet/get-fees). Check the withdrawable amount before initiating a withdrawal. If the issue persists, review open orders possibly reserving funds. See [Balances & Transfers](/concepts/balances) for explanation of available vs. frozen balances.
  </Accordion>

  <Accordion title="Network confirmation requirements for deposits">
    Each cryptocurrency network requires a specific number of block confirmations before a deposit is credited. The webhook payload includes `confirmations.actual` and `confirmations.required` fields. Check the [Asset Status endpoint](/api-reference/market-data/asset-status-list) for per-currency confirmation requirements.
  </Accordion>

  <Accordion title="USDT alternatives for EEA users (MiCA compliance)">
    Since December 30, 2024, EEA users cannot deposit, withdraw, or create WhiteBIT Codes in USDT. Use USDC (Circle holds an EU e-money license) or EURI (euro-pegged, MiCA-compliant) as alternatives. See [Regulatory Compliance](/institutional/compliance) for details.
  </Accordion>

  <Accordion title="Below-minimum deposit handling">
    Deposits below the minimum amount for a currency are not credited to the account balance. Check the minimum deposit amount via the [Asset Status endpoint](/api-reference/market-data/asset-status-list) before generating deposit addresses. No mechanism exists to recover below-minimum deposits.
  </Accordion>
</AccordionGroup>

## Webhooks

<AccordionGroup>
  <Accordion title="Webhook HTTPS requirements and port">
    HTTPS is required for Webhook API communication:

    * Communication occurs over port 443
    * SSL/TLS encryption is mandatory
    * HTTP connections are not supported

    For more details, see the [Webhook documentation](/platform/webhook).
  </Accordion>

  <Accordion title="Webhook signature verification">
    Each webhook request includes an `X-TXC-APIKEY` header and an `X-TXC-PAYLOAD` + `X-TXC-SIGNATURE` for verification. Verify the HMAC-SHA512 signature using the webhook secret key to confirm the request originates from WhiteBIT. See the [Webhook](/platform/webhook) reference for the full verification flow.
  </Accordion>

  <Accordion title="Webhook retry behavior">
    WhiteBIT retries failed webhook deliveries 5 times at 10-minute intervals, providing up to 50 minutes of coverage. There is no replay mechanism after the retry window expires. Implement polling of the deposit and withdrawal history endpoints as a fallback for outages exceeding 50 minutes. See [Webhook](/platform/webhook) for details.
  </Accordion>
</AccordionGroup>

## API and assets

<AccordionGroup>
  <Accordion title="Currency deposit and withdrawal availability">
    Check currency status through the assets endpoint:

    * URL: [https://whitebit.com/api/v4/public/assets](https://whitebit.com/api/v4/public/assets)
    * The endpoint provides real-time status of all currencies
    * Check the currency-specific enabled/disabled flags

    For endpoint details and response schema, see the [Asset status list](/api-reference/market-data/asset-status-list) documentation.
  </Accordion>
</AccordionGroup>

## Trading

<AccordionGroup>
  <Accordion title="Collateral endpoint naming — Margin vs Futures">
    The API uses "collateral" as a shared prefix for both Margin Trading (up to 10x leverage on spot pairs like `BTC_USDT`) and Futures Trading (up to 100x leverage on perpetual pairs like `BTC_PERP`). The market pair determines the product — not the endpoint path. All endpoints under `/api/v4/order/collateral/` and `/api/v4/collateral-account/` serve both products. See [Margin Trading](/products/margin/overview) and [Futures Trading](/products/futures/overview).
  </Accordion>

  <Accordion title="Minimum order sizes per market">
    Each market has a minimum order amount (`minAmount`) and minimum order value (`minTotal`). Retrieve these values from `GET /api/v4/public/markets` (spot) or `GET /api/v4/public/futures` (futures). Orders below the minimum are rejected. See [Markets & Trading Pairs](/concepts/markets).
  </Accordion>

  <Accordion title="Kill-switch for emergency order cancellation">
    The kill-switch automatically cancels all active orders after a configurable timeout. Activate via `POST /api/v4/order/kill-switch` with a `timeout` parameter (in seconds). Use `POST /api/v4/order/kill-switch/status` to check the current state. Designed as a safety mechanism for automated trading strategies. See the [Market Maker Guide](/guides/market-maker-integration) for usage patterns.
  </Accordion>

  <Accordion title="Bulk order limits">
    The bulk order endpoint (`POST /api/v4/order/bulk`) accepts up to 20 limit orders in a single request. All orders in the batch must be for the same market pair. The collateral bulk endpoint (`POST /api/v4/order/collateral/bulk`) follows the same 20-order limit.
  </Accordion>

  <Accordion title="Market order price in API response">
    The price returned in a market order response may reflect an internal limit price, not the actual execution price. To obtain the true fill price, check the trade history via `POST /api/v4/trade-account/executed-history` or subscribe to the WebSocket deals channel. See [Order Types](/concepts/order-types) for market order execution details.
  </Accordion>

  <Accordion title="Reduce-only order parameter">
    A reduce-only order guarantees that the order only decreases or closes an existing position — the order cannot increase the position or open a new one. Set `reduceOnly: true` on any collateral order creation endpoint. Available on margin and futures markets only.

    If no open position exists or the order direction matches the position direction, the API returns error code `116`. If the order amount exceeds the current position size, the system reduces the order to match automatically.

    Pending reduce-only orders are auto-canceled with status `AUTO_CANCELED_REDUCE_ONLY` when the associated position closes.

    See [Order Types — Reduce-only orders](/concepts/order-types#reduce-only-orders) for full details.
  </Accordion>
</AccordionGroup>

## Security and API keys

<AccordionGroup>
  <Accordion title="API key security best practices">
    Store API keys securely using environment variables, restrict IP access, and use minimum required permissions. Never commit keys to version control.

    For details, see the [Authentication guide](/api-reference/authentication). For comprehensive security guidance, see [Security Best Practices](/best-practices/security).
  </Accordion>

  <Accordion title="Compromised API key response">
    Immediately delete the compromised key, review account activity for unauthorized actions, and create new API keys. Contact support if unauthorized activity is detected.

    For details, see the [Authentication guide](/api-reference/authentication).
  </Accordion>

  <Accordion title="API key auto-deactivation after inactivity">
    The platform automatically deactivates an API key that receives no requests for 14 consecutive days. An IP whitelist does not exempt a key from this rule — whitelisted and non-whitelisted keys deactivate on the same schedule. Reactivate a deactivated key at [whitebit.com/settings/api](https://whitebit.com/settings/api). See [Key rotation](/best-practices/security#key-rotation).
  </Accordion>

  <Accordion title="Keeping spare API keys active">
    Send at least one authenticated request from each spare key every 14 days. Any authenticated endpoint resets the inactivity timer — a balance check via `POST /api/v4/main-account/balance` is sufficient. Keys held in reserve without periodic traffic deactivate on the same schedule as unused keys. See [Main balance](/api-reference/account-wallet/main-balance).
  </Accordion>

  <Accordion title="Reasons an API key becomes disabled">
    An API key becomes disabled after 14 consecutive days without requests, or when deactivated from the account settings. Check the key status at [whitebit.com/settings/api](https://whitebit.com/settings/api), resolve the cause, then re-enable the key. See [Security best practices](/best-practices/security).
  </Accordion>
</AccordionGroup>

## API usage

<AccordionGroup>
  <Accordion title="High-frequency trading API optimization">
    Use WebSocket for real-time data, batch requests when possible, implement proper rate limiting, and cache frequently accessed data.

    For details, see the [WebSocket API](/websocket/market-streams/overview). For rate limit tiers and endpoint-specific limits, see [Rate Limits](/api-reference/rate-limits). For colocation infrastructure, see the [Market Maker Guide](/guides/market-maker-integration).
  </Accordion>

  <Accordion title="API disconnection handling">
    Implement automatic reconnection with exponential backoff. Maintain local order state and set up monitoring and alerts for connection issues.

    For details, see the [WebSocket API](/websocket/market-streams/overview). For a pre-launch readiness checklist including reconnection testing, see the [Go-Live Checklist](/best-practices/go-live-checklist).
  </Accordion>

  <Accordion title="Getting started with the WhiteBIT API">
    Start with the [First API Call](/guides/first-api-call) guide for an orientation. The recommended path: create an API key, make a public endpoint call (no auth required), then authenticate a private endpoint call.
  </Accordion>

  <Accordion title="Available SDKs and quickstart examples">
    Official SDKs exist for Go, Python, and PHP. See the [SDKs page](/sdks) for installation instructions and GitHub links. For raw HMAC-SHA512 signing without an SDK, see [First API Call](/guides/first-api-call).
  </Accordion>

  <Accordion title="Testing without a sandbox environment">
    WhiteBIT does not offer a public testnet or sandbox. For risk-free Spot testing, activate
    Demo Tokens (DBTC + DUSDT) from the [WhiteBIT Codes page](https://whitebit.com/codes) —
    no KYC required. Trade the `DBTC_DUSDT` pair via the standard API to validate the full
    order lifecycle without real funds. For Margin, Futures, and fund-movement testing, use
    minimum order sizes on the live API. See the
    [Go-Live Checklist](/best-practices/go-live-checklist) for the complete testing strategy.
  </Accordion>

  <Accordion title="REST API vs WebSocket — when to use each">
    Use the REST API for one-time request–response calls: checking balances, fetching trade history, and placing orders. Use the WebSocket API for real-time streaming data: live orderbook updates, trade feeds, and balance changes. Order placement, modification, and cancellation are also available over WebSocket as an alternative transport, on the global platform only — the [order methods](/websocket/order-management/overview) run on the same authorized connection as the streams, which suits low-latency placement without opening and re-authenticating a connection per request. REST polling at high frequency consumes rate limits — switch to WebSocket for data that updates continuously. See [Rate Limits](/api-reference/rate-limits) for REST constraints, [WebSocket Rate Limits](/websocket/rate-limits) for the per-connection WebSocket request budgets, [WebSocket Quickstart](/guides/websocket-quickstart) for streaming setup, and [Order Management](/websocket/order-management/overview) for the WebSocket order methods.
  </Accordion>

  <Accordion title="Choosing the right SDK">
    Official SDKs are available for Go, Python, and PHP. Check the [SDKs page](/sdks) for current version, maintenance status, and whether each SDK handles HMAC signing automatically.
  </Accordion>

  <Accordion title="API access levels and prerequisites">
    Public endpoints (market data, tickers, orderbook) require no account or authentication. Private endpoints (trading, account management) require API keys — create these keys in account Settings. Institutional features (colocation, OTC, Embedded Trading) require [institutional onboarding](/institutional/onboarding). See [First API Call](/guides/first-api-call) for the recommended integration path.
  </Accordion>
</AccordionGroup>

## Institutional and partner onboarding

<AccordionGroup>
  <Accordion title="Available institutional products">
    WhiteBIT offers Market-Making Programs, Embedded Trading (up to 40% fee share), Sub-Account management, OTC trading, Crypto Lending for business, colocation, and Liquidity Provision. See the [Institutional Overview](/institutional/overview) for the full catalog.
  </Accordion>

  <Accordion title="Institutional onboarding process">
    Onboarding has two phases: Phase 1 (crypto access) requires account registration, KYC for the director, and KYB verification. Phase 2 (fiat/SEPA access) requires additional documentation through the fiat processing partner. See [Institutional Onboarding](/institutional/onboarding) for the step-by-step process.
  </Accordion>

  <Accordion title="Fee structure for institutional clients">
    Base trading fees are 0.1% maker / 0.1% taker. The Market-Making Program offers rebates up to -0.012% maker. Embedded Trading provides up to 40% fee share on referred user trading fees; the applicable rate is agreed individually during enrollment. Contact [institutional@whitebit.com](mailto:institutional@whitebit.com) for volume-based arrangements.
  </Accordion>

  <Accordion title="Sandbox or testnet availability">
    WhiteBIT does not offer a public testnet or sandbox. However, free Demo Tokens
    (0.5 DBTC + 1,000 DUSDT) are available for risk-free Spot trading via the
    [WhiteBIT Codes page](https://whitebit.com/codes) — no KYC required. The `DBTC_DUSDT`
    pair works with all standard Spot API endpoints. For Margin, Futures, and deposit/withdrawal
    testing, use minimum order sizes on the live API. See the
    [Go-Live Checklist](/best-practices/go-live-checklist) for the complete testing strategy.
  </Accordion>

  <Accordion title="Regulatory licenses and certifications">
    WhiteBIT holds licenses in multiple EU jurisdictions and maintains ISO 27001, PCI DSS, and CCSS security certifications, with the CCSS Level 3 assessment conducted by Hacken. GDPR compliance is maintained for data processing. For specific VASP authorization details and jurisdiction information, contact [institutional@whitebit.com](mailto:institutional@whitebit.com). See [Regulatory Compliance](/institutional/compliance).
  </Accordion>

  <Accordion title="Colocation for low-latency trading">
    Colocation is available across EEA/EMEA and APAC regions. Access is limited to a subset of 35 trading endpoints. See [Colocation](/platform/colocation) for setup details and the [Market Maker Guide](/guides/market-maker-integration) for the full endpoint list.
  </Accordion>

  <Accordion title="Sub-account permissions not applied after creation">
    A sub-account created with its own email address (dedicated KYC, `shareKyc: false`) must have that email confirmed before permissions can be configured. The end customer confirms it by opening the personal link from [`POST /api/v4/sub-account/kyc-url`](/api-reference/sub-accounts/kyc-url) and completing verification, which covers both identity verification and email confirmation.

    Permissions configured before that confirmation are not retained. Re-apply the permission set with [`POST /api/v4/sub-account/edit`](/api-reference/sub-accounts/edit-sub-account) once the sub-account is active, and send the full `permissions` object on every edit: flags omitted from an edit request are turned off without a warning.

    A sub-account created with `shareKyc: true` accepts permissions immediately at creation. See the [Sub-account integration guide](/guides/sub-account-integration) for the full flow.
  </Accordion>
</AccordionGroup>

## Compliance and regulatory

<AccordionGroup>
  <Accordion title="MiCA USDT restrictions for EEA users">
    Since December 30, 2024, EEA accounts cannot deposit, withdraw, or create WhiteBIT Codes in USDT under MiCA regulation. USDC and EURI are available as compliant alternatives. See [Regulatory Compliance](/institutional/compliance) for the full list of affected operations and recommended alternatives.
  </Accordion>

  <Accordion title="Travel Rule requirements for EEA withdrawals">
    Since May 19, 2025, crypto withdrawals from EEA accounts require a `travelRule` object in the withdrawal request body. The object uses a structured format: `walletType` (hosted or unhosted destination), `beneficiary` (receiver details), and `vaspData` (destination platform identification). See [Regulatory Compliance](/institutional/compliance) for the field reference and code examples.
  </Accordion>

  <Accordion title="Security certifications and audits">
    WhiteBIT holds ISO 27001, PCI DSS, and CCSS security certifications, with the CCSS Level 3 assessment conducted by Hacken. GDPR is a regulation (not a certification) — WhiteBIT processes data in accordance with GDPR requirements. For audit reports or verification details, contact [institutional@whitebit.com](mailto:institutional@whitebit.com).
  </Accordion>
</AccordionGroup>

## What's Next

<CardGroup cols={2}>
  <Card title="First API Call" icon="rocket" href="/guides/first-api-call">
    First steps for API integration — account setup, API keys, and the first authenticated call.
  </Card>

  <Card title="Partner Solutions" icon="signs-post" href="/guides/partner-solutions">
    Find the recommended integration path for market makers, account operators, bot platforms, wallet backends, payment providers, prop firms, and institutional clients.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.