Skip to main content
Webhooks push a deposit’s status change to your backend, so you credit a user the moment a deposit completes instead of polling. Until they ship, poll /deposit/status.
Coming soon. The design below is the intended shape - a plan, not a live spec. Exact event names, payloads, and the signing scheme are finalized with the routing layer.

​
How it will work

Each event maps to a transaction status:Common envelope: { id, type, created, data: { ... } }, where data carries the deposit and its transaction hashes.
Every delivery is signed so you can trust it came from Rheon:
  • Header: Rheon-Signature: t=<timestamp>,v1=<signature>
  • Signed payload: <timestamp>.<raw_request_body>
  • HMAC-SHA256 with your endpoint secret, compared in constant time
  • Use the raw request body - if your framework re-serializes it, verification fails (the single most common integration bug)
  • Reject events whose timestamp is older than ~5 minutes (replay protection)
  • Return 2xx before heavy work: verify → enqueue → return 200, then process async.
  • No ordering guarantee - events can arrive out of order; reconcile against /deposit/status.
  • Idempotency - an event can arrive more than once; deduplicate on id.
  • Failed deliveries are retried with backoff over a retry window.
A CLI will forward events to your local endpoint and trigger the full lifecycle (deposit.pending → deposit.completed) on demand in the sandbox, so you can build against webhooks before going live.
For anything your backend must trust (crediting a user), rely on a webhook you verified or a done status you fetched yourself - never on client-side UI state.