Zum Hauptinhalt springen

Statusupdates, Retries und Webhook-Strategie

Aktuelles Muster für Statusabfragen und empfohlene Retry-Logik.

M
Verfasst von Max Valjan
Heute aktualisiert

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.

Hat dies deine Frage beantwortet?