Troubleshooting
Support escalation
What to collect before escalating an integration issue.
Support escalation
Escalation quality depends on identifiers, not screenshots alone.
Always include
- operator name or operator ID
- affected environment
- exact UTC timestamp window
- request path
- HTTP status code
- error code or status message
Include by workflow
Launch issues
external_user_id- launch request correlation ID if available in your logs
- returned launch error payload
Trade or redemption issues
order_idtrade_idif presentredemption_item_idif presentidempotency_key- balance operation IDs if wallet mutation happened
Webhook issues
event_idevent_type- webhook endpoint ID
- webhook delivery ID
- last status code
- last response body sample
Wallet adapter issues
- operator-side request and response logs
- raw request body for signed mutations
- whether lookup endpoint was queried after unknown result
Never send
- raw API bearer tokens
- webhook secrets
- wallet adapter secrets
- private signing keys
- database dumps with unrelated user data
Safe escalation flow
- reproduce once more if safe
- collect IDs and UTC timestamps
- collect minimal sanitized request and response samples
- note whether issue is deterministic, intermittent, or already recovered
- include what changed before failure: key rotation, webhook secret rotation, config patch, deploy, or receiver release
Fastest route to resolution
- include one concrete failing example
- include one known-good example from same environment if available
- state whether money movement may be affected
- state whether webhook replay already attempted
