Skip to main content

Handle failures by class

  1. Parse error class from response and status code.
  2. For RateLimit, apply bounded retry with backoff and jitter.
  3. For ServiceUnavailable, retry with backoff and health checks.
  4. For SafetyFailure, do not retry blindly; fix payload first.
  5. For malformed request classes, fail fast and alert.
  6. On WebSocket disruptions, rebuild state from REST then resubscribe.

Recovery map

Error familyRecovery move
malformed payload or schema failurestop, repair serialization or field shape, then rebuild
signer, session, or encryption failurerepair identity or cryptographic material before retry
nonce, timestamp, or replay-window failureregenerate replay fields instead of resending unchanged
safety failurefix product, price, amount, collateral, or strategy state first
rate-limit or temporary service faultbounded retry with backoff, jitter, and correlation logging
WebSocket disruptionreconnect, re-bootstrap state from REST, then resubscribe

Protocol-specific recovery decisions

If you see…Do this
InvalidRecvWindowrebuild the request with a valid receive window; the public upper bound is 60000 ms
FutureTimestampcorrect client clock skew; requests beyond the server’s future cutoff are rejected rather than queued
ExpiredTimestamprebuild with a fresh timestamp instead of resending stale payloads
NotAcceptingRequests or ServiceUnavailableretry with bounded backoff and health awareness; these can reflect leader unavailability, pending durable commit, or missing mark-price readiness
WebSocket disconnect or replay gapreconnect, restore the latest state from REST, then resubscribe to realtime updates

Minimum observability fields

  • request hash or client nonce
  • endpoint and transport
  • error class and reason enum
  • retry decision and attempt count

Escalate after recovery fails

  1. Recheck Error Reference to confirm the class and recovery posture.
  2. Recheck Rate Limits and Access Tiers if retries are colliding with quota behavior.
  3. Use Troubleshooting when the failure remains ambiguous after classification.
  4. Use Support Channels when the published public routes do not explain the remaining behavior.

Boundary rule

This page tells you how to recover once the error class is known. Use Error Reference for canonical classification and REST Errors when you need the REST-family framing around the same failures.

Next routes

Last modified on April 13, 2026