Skip to main content

Status updates, retries, and webhook strategy

Current status retrieval pattern and recommended retry behavior.

M
Written by Max Valjan
Updated today

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.

Did this answer your question?