Status updates, retries, and webhook strategy
Current status retrieval pattern and recommended retry behavior.
This article explains the current production-safe approach for status sync, retries, and phased webhook rollout.
What this is
Order status can be read from status/history endpoints while public partner webhooks are still rolling out by cohort.
What to provide
- Use
/v1/orders/\{id\}/statusfor latest status snapshot. - Use status and waypoint history endpoints for timeline reconstruction.
- Map lifecycle states consistently (for example pending, assigned, in transit, completed, cancelled).
- Define retry policy for 429/5xx responses with jittered backoff.
What happens next
- Available now: polling with exponential backoff is the recommended production pattern.
- Available now: treat transient 429/5xx responses as retryable with jitter.
- Coming soon: broader public partner webhooks for lifecycle events as rollout progresses.
- Support can confirm rollout stage and migration timing from polling to webhook-first flows.
Until webhook rollout is complete for your integration, polling with backoff is the recommended production-safe approach.
Was this article helpful?
Related articles
API access quickstart and authentication
How to start integration access and understand current authentication modes.
Orders API fields and multi-stop payloads
Required order structure and how to model intermediate stops.
API security, rate limits, idempotency, and support
Integration hardening practices for production-safe API clients.
← Back to API and Integrations
Still need help? Contact support