Statusupdates, Retries und Webhook-Strategie

Dieser Artikel erklärt den aktuell produktionssicheren Ansatz für Status-Synchronisation, Retries und den phasenweisen Webhook-Rollout.

Was das ist

Order-Status wird über Status-/History-Endpunkte bezogen, während öffentliche Partner-Webhooks je Kohorte ausgerollt werden.

Was Sie angeben müssen

• /v1/orders/\{id\}/status für aktuellen Status-Snapshot nutzen.
• Status- und Waypoint-History-Endpunkte für Zeitverlauf nutzen.
• Lifecycle-Status konsistent abbilden (z. B. pending, assigned, in transit, completed, cancelled).
• Retry-Policy für 429/5xx mit Jitter-Backoff definieren.

Was als Nächstes passiert

• Verfügbar: Polling mit exponentiellem Backoff ist aktuell das empfohlene Produktionsmuster.
• Verfügbar: 429- und 5xx-Antworten als retrybar mit Jitter behandeln.
• Kommt bald: breitere öffentliche Partner-Webhooks für Lifecycle-Events mit fortschreitendem Rollout.
• Support kann Rollout-Stand und Migrationszeitpunkt von Polling zu Webhook-First bestätigen.

Bis zum vollständigen Webhook-Rollout ist Polling mit Backoff der empfohlene produktionssichere Ansatz.