Skip to main content

How to use

Requirements

Webhook methods

WhiteBIT withdraw from main balance

Why Webhooks?

Webhooks deliver real-time HTTP notifications when events occur on a WhiteBIT account — deposits arriving, withdrawals completing, codes being applied, and refunds processing. Without webhooks, the only alternative is polling the deposit/withdrawal history endpoints repeatedly. Webhooks vs polling:
There is no webhook replay mechanism. If every delivery attempt fails, the event is dropped. Implement polling of the deposit / withdrawal history endpoint as a fallback so events can be reconciled after extended consumer downtime.
Common use cases:
  • Payment processing — Detect incoming deposits and credit end users automatically
  • Withdrawal monitoring — Track withdrawal lifecycle from creation to completion or cancellation
  • Code redemption — Receive notification when a WhiteBIT Code is applied
  • Refund handling — Detect successful or failed refunds for reconciliation

How to use

  1. Log in to whitebit.com.
  2. Open the API keys tab.
  3. Select the web-hook configuration tab for the API keys.
  4. Paste the correct URI for the web server to process web-hook calls.
  5. Press Generate a new key button and toggle the activation switcher to “Activated”.
The secret key is shown only once. Save it in a secure key store.

Requirements

For web hook keys generation

Before using webhooks, verify ownership of the domain set as the webhook destination. Use one of three methods:
  1. Add a TXT DNS record to the domain with the webhook public key.
  2. Add the plain text file whiteBIT-verification.txt to the root domain folder and provide public web access. Place the public webhook key in the file.
  3. Implement the /whiteBIT-verification endpoint to respond with 200 OK and return a JSON array containing the public webhook key. Example: ["<public-webhook-key>"]
Passing one of these checks enables the webhook.

For processing web-hook requests

All web hook requests are performing using POST method and with application/json content type. Consumer server should respond with 200 HTTP status code. If the consumer cannot handle the webhook, the platform retries delivery a small number of times spaced roughly an hour apart, over a window of about one day. Treat the exact cadence as best-effort, not a contract, and pair webhook consumption with periodic history polling for reconciliation.

Body data

All web-hook requests are performing with
method - string. The name of method which was evaluated. Web hooks API supports such web-hook methods:
  • code.apply. Performs when code owned by a customer was applied.
id - string. Uuid to identify every request. params - the request payload. Contains data about the actions triggering the webhook call. The field also contains a nonce. ‘nonce’ - a number always greater than the previous request’s nonce number

Request headers

Also, all request contains additional data in headers:
  1. 'Content-type': 'application/json'
  2. 'X-TXC-APIKEY': api_key - the WhiteBIT webhook API key
  3. 'X-TXC-PAYLOAD': payload' - where payload is base64-encoded body data
  4. 'X-TXC-SIGNATURE': signature - where signature is hex(HMAC_SHA512(payload), key=api_secret))
On the consumer side, process the security headers to verify the request originated from WhiteBIT.

WebHook Methods

WhiteBIT code apply

Performed when code was applied. Request example:

WhiteBIT deposit to main balance

Performed when deposit was accepted. Request example:
Performed when deposit was update. Request example:
Performed when the deposit was processed and is available on the balance. Request example:
Performed when deposit was canceled. Request example:

Travel Rule deposit statuses (EEA)

For EEA users, an inbound deposit may be frozen pending Travel Rule verification, and the deposit carries a Travel Rule status code (see the table below). There is currently no webhook for these transitions, so track them via the deposit/withdraw history. When the Travel Rule API is enabled for the account, submit the deposit originator data via Submit deposit originator data (POST /api/v4/travel-rule/deposit/verification); otherwise the deposit is verified manually at whitebit.com. Funds are credited only after successful verification. For details on Travel Rule requirements and the travelRule object for withdrawals, see Regulatory Compliance. Deposit status codes:

WhiteBIT withdraw from main balance

Performed when withdraw was created. Request example:
Performed when withdraw is pending. Request example:
Performed when withdraw was canceled. Request example:
Performed when withdraw was completed. Request example:

WhiteBIT refund successful

Triggered after the system successfully completes a refund. Request example:

WhiteBIT refund failed

Triggered after the system fails to complete a refund. The system rejects the refund if the destination address does not support the required network or asset, or if validation fails. Use a different address or contact support. Request example:

What’s Next

Payment Integration

End-to-end guide for deposit and withdrawal processing with webhook reconciliation.

Security Best Practices

HMAC-SHA512 signature verification, API key management, and production hardening.