Debug sessions and webhooks
Investigate checkout, embed, webhook, and reconciliation issues with stable identifiers and redacted evidence.
Debugging should start from identifiers, not raw payloads. Link your local attempt id, product object id, request id, webhook event id, delivery id, and final business state. For a hosted 0Gate flow, the product object id is the 0Gate session id.
Do not debug by sharing secrets
Support tickets should never contain secret keys, webhook secrets, authorization headers, client secrets, raw KYC data, provider responses, or unredacted webhook bodies.
Debug path
Evidence table
| Identifier | Source | Use |
|---|---|---|
| Local attempt id | Your database | Anchor the support case. |
| Product object id | 0Gate session, 0Base checkout/payment intent, 0Pools quote/trade, or other approved object | Join 0Bit state to your state. |
| Request id | API response header or error body | Ask 0Bit support to trace an API call. |
| Event id | Webhook body and header | Dedupe and trace event processing. |
| Delivery id | Webhook delivery log | Replay or diagnose delivery failures. |
| User reference | Your server-created session metadata | Correlate to your account/order safely. |
Triage questions
- Did your server create a local attempt before creating the 0Bit product object?
- Did the product-object creation call succeed, timeout, or return a known error?
- Did the browser receive only browser-safe values?
- Did the widget mount from an allowed origin?
- Did a signed webhook arrive?
- Did the event log dedupe and queue the event?
- Did the worker apply the expected terminal transition?
- Is reconciliation needed because the webhook is delayed or dead-lettered?
Redacted ticket shape
type SupportTicketContext = {
localAttemptId: string;
productObjectId?: string;
requestId?: string;
eventIds: string[];
deliveryIds: string[];
observedStatus: string;
expectedStatus: string;
occurredAt: string;
};