transaction_id remains constant across every notification for the same transfer, so partners can correlate all status changes to a single deposit or withdrawal.initiated state (returned synchronously by the initiate-deposit endpoint — no webhook is sent for initiated). Subsequent status changes are delivered via this webhook, typically in the following order:pending → approved → credited → finishedrejected status, and the notification carries a rejection_reason. Terminal statuses (rejected, cancelled, refunded) receive no further notifications.manual_review status while a compliance or risk check is carried out. This is not a terminal status: once the review is resolved the transfer resumes its normal flow (e.g. approved, credited, finished) or moves to a terminal outcome (rejected, refunded), and a corresponding notification is sent.pending state (returned synchronously by the initiate-withdrawal endpoint — no webhook is sent for the initial pending state). This webhook then notifies the terminal outcome:finished — the withdrawal completed successfully.refunded — the withdrawal was cancelled and the amount refunded to the user's wallet.manual_review while a compliance or risk check is carried out; once resolved it proceeds to finished or refunded.curl --location 'https://your-api-server.com' \
--header 'X-BTS-Idempotency-Key;' \
--header 'Signature;' \
--header 'Content-Digest;' \
--header 'Date;' \
--header 'Content-Type: application/json' \
--data '{
"params": {
"transaction_id": "a1e00000-0000-0000-0000-000000000001",
"user_id": "c1e00000-0000-0000-0000-000000000001",
"type": "deposit",
"fiat_id": "d1e00000-0000-0000-0000-000000000001",
"amount": "100.50",
"fee": "1.00",
"status": "pending",
"payout_account_id": null,
"event_time": "2025-04-11T08:09:07Z"
}
}'