OpenPoly logo
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_id
  • trade_id if present
  • redemption_item_id if present
  • idempotency_key
  • balance operation IDs if wallet mutation happened

Webhook issues

  • event_id
  • event_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

  1. reproduce once more if safe
  2. collect IDs and UTC timestamps
  3. collect minimal sanitized request and response samples
  4. note whether issue is deterministic, intermittent, or already recovered
  5. 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
Copyright © 2026