Status updates, retries, and webhook strategy

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\}/status for 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.