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 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 and withdrawal history endpoints as a fallback.
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 consumer was unable to handle web-hook, the request will be retry every 10 minutes but not more than 5 times.

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 events (EEA)

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. 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.