0Bit Documentation

Webhook events

Catalog the 0Bit webhook event types, payload shapes, handler responsibilities, and product boundaries that public integrators can rely on.

Webhook events tell your backend that a 0Bit object changed state. Treat each event as a signed notification that should be verified, persisted, deduped, and then reconciled against your own order, account, invoice, or balance records.

The event list below is source-backed for 0Gate. 0Base and 0Pools event delivery must remain review-gated until Product and Engineering approve the live event contract for those products.

Do not fulfill from browser callbacks

Browser callbacks are UX hints. Fulfillment, balance updates, invoice status, settlement tasks, and support records must use verified server-side events or trusted API reads.

Envelope

Most product events use the same envelope shape:

FieldMeaningHandler use
idUnique event id.Dedupe retries and replay attempts.
typeEvent type string.Route to the correct handler.
created_atEvent creation time.Audit and stale-event checks.
dataProduct object or event-specific payload.Read status, object id, metadata, and references.

Example:

{
  "id": "evt_test_123",
  "type": "gate_session.completed",
  "created_at": 1782475200,
  "data": {
    "id": "gs_test_123",
    "object": "gate_session",
    "status": "completed",
    "metadata": {
      "order_id": "order_test_123"
    }
  }
}

Delivery headers

0Gate delivery evidence includes these headers:

HeaderPurpose
Gate-SignatureHMAC signature over timestamp and raw request body.
X-0bit-TimestampTimestamp used for replay-window checks.
X-0bit-Event-IdEvent id for logging and dedupe correlation.
X-0bit-Event-TypeEvent type for delivery-level triage.

Always verify the raw body before using the event. Do not parse and reserialize JSON before signature verification.

0Gate session events

Event typeWhen it firesRecommended action
gate_session.createdA session has been created.Store the session id and mark your order as pending.
gate_session.processingThe hosted flow is in progress.Keep the user-facing state pending and wait for terminal status.
gate_session.completedThe session completed successfully.Fulfill only after dedupe and any required trusted API reconciliation.
gate_session.failedThe session failed.Mark the order failed and show a retry path where appropriate.
gate_session.expiredThe session expired before completion.Expire local checkout state and create a new session if the user retries.
gate_session.cancelledThe session was cancelled.Close the local checkout attempt without fulfillment.
gate_session.kyc_package_acceptedA trusted KYC package was accepted for a session.Store the audit correlation only; do not log PII-heavy payloads.

Session events should be joined to your own order using the server-created session id, metadata, or user_reference you provided during session creation.

Gate events

Event typeAreaRecommended action
kyc.requiredGateMove the user into the hosted KYC flow or show a pending KYC state.
quote.consumedGate quoteMark the quote as no longer executable.
webhook.testDelivery testConfirm signature verification and endpoint reachability only.

webhook.test is synthetic. It should never fulfill an order, credit a balance, or mark a real session complete.

Partner quota events

Event typeMeaningRecommended action
partner.quota.warningUsage is approaching a configured limit.Alert operators and decide whether to slow or pause new session creation.
partner.quota.exhaustedUsage limit has been reached.Stop creating new dependent operations until the limit is resolved.

Quota events are operational signals. They should not be exposed to end users as raw webhook errors.

Restricted rail events

The source contains pay-in and pay-out rail event names. These are not general public integration events. Use them only if your account is explicitly entitled for the rail flow and the contract/API review enables them.

Event typeAreaPublic handling boundary
rail.pay_in.processingPay-in railEntitled rail partners only.
rail.pay_in.settledPay-in railEntitled rail partners only.
rail.pay_in.failedPay-in railEntitled rail partners only.
rail.pay_in.cancelledPay-in railEntitled rail partners only.
rail.pay_out.processingPay-out railEntitled rail partners only.
rail.pay_out.settledPay-out railEntitled rail partners only.
rail.pay_out.failedPay-out railEntitled rail partners only.
rail.pay_out.cancelledPay-out railEntitled rail partners only.

Do not publish provider names, bank details, treasury state, reserve logic, routing strategy, or private risk controls when handling rail events.

Product boundaries

ProductWebhook statusPublic-safe guidance
0GateSource-backed signed events and delivery APIs.Use as the default public webhook integration path.
0BaseFoundation/review-only evidence.Treat events as object/reporting model until live behavior is approved.
0PoolsPartner-confidential/liquidity-sensitive evidence.Use only approved partner-safe quote/trade events if enabled.
0LinkApp/link workflow docs only.Do not assume a public event contract without approval.
0Pools ScanExplorer-style read visibility.Use Scan pages for visibility, not as a webhook contract.

Handler checklist

  • Verify the signature with the raw body.
  • Reject stale timestamps.
  • Store the event id before fulfillment.
  • Treat duplicate event ids as successful no-ops.
  • Store object ids, event type, request id, timestamps, and your own references.
  • Queue slow work after durable persistence.
  • Reconcile terminal events with trusted API reads when the business action is high value.
  • Never log API keys, webhook secrets, bank details, provider payloads, or PII-heavy KYC data.

On this page