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:
Webhooks
Polling
Latency
Real-time (seconds)
Depends on polling interval
Server load
Event-driven — no wasted requests
Constant requests, mostly empty
Reliability
~3 delivery attempts spaced roughly hourly over a ~1-day window
As reliable as the polling loop
Recommended for
Production payment flows
Fallback for outages exceeding the delivery window
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
Before using webhooks, verify ownership of the domain set as the webhook destination. Use one of three methods:
Add a TXT DNS record to the domain with the webhook public key.
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.
Implement the /whiteBIT-verification endpoint to respond with 200 OK and return a JSON array containing the public webhook key. Example: ["<public-webhook-key>"]
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.
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
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:
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: