Webhooks

Wird ausgelöst, sobald eine lokale Lieferbestellung (Delivery / Pickup / P2P) angelegt wird — über beliebigen Weg: Webformular, REST/GraphQL-API, E-Commerce-Plattform-Synchronisation, automatische Regeln, Importzeilen usw. Label-Service- und andere Nicht-Lieferarten sind ausgeschlossen. Wird im Batch-Flow übersprungen, wenn für denselben Empfänger auch order_create_async_postback_url konfiguriert ist. Konfigurieren Sie mit order_create_webhook_url.

Wird bei jedem Statuswechsel ausgelöst — abgeholt, unterwegs, zugestellt, Ausnahme, storniert. Konfigurieren Sie mit order_status_change_webhook_url.

Wird bei jedem Tracking-Lebenszyklusereignis ausgelöst (Daten übermittelt, Zustellung gestartet, erfolgreich zugestellt usw.). Konfigurieren Sie mit tracking_event_webhook_url. Zustell- und Abholereignisse enthalten außerdem den Zustellnachweis: proof_files sowie proof_files_detail (file_id, type, url, full_url, signierte Download-URL). Nach dem Ereignis hochgeladene Fotos kommen als pod.files_updated. Jede Datei trägt zusätzlich ihren Ereigniskontext: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) und service_status (1 = success / 2 = failed); bei Altdateien ohne erfasstes Ereignis sind sie null.

Wird einmal ausgelöst, nachdem ein Stapelimport abgeschlossen ist. Payload enthält die Ergebnisse pro Zeile. Konfigurieren Sie mit order_create_async_postback_url.

Wird ausgelöst, wenn ein Zustellfoto oder eine Unterschrift hinzugefügt, ersetzt oder entfernt wird (action: added / updated / removed) — eine Zustellung pro Datei, kein Abfragen von Anhängen mehr. Aktivierung über pod_files_webhook_url. Jede Datei trägt zusätzlich ihren Ereigniskontext: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) und service_status (1 = success / 2 = failed); bei Altdateien ohne erfasstes Ereignis sind sie null.

Wird ausgelöst, wenn eine Bestellung endgültig gelöscht wird, damit Ihr System die Entfernung nachvollziehen kann. Aktivierung über order_deleted_webhook_url.

Wird ausgelöst, wenn ein Stornierungsversuch abgelehnt wird (z. B. weil die Bestellung bereits in Zustellung ist), damit Ihre Betriebsprozesse fehlgeschlagene Stornierungen ohne API-Abfragen überwachen können. Aktivierung über order_cancel_failed_webhook_url.

Wird ausgelöst, wenn ein Platz auf dem Routen-Board den Besitzer wechselt oder das Board seinen Status ändert — das Feld action sagt, was passiert ist (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Nur auf Unternehmensebene. Opt-in über route_board_webhook_url.

Türen Geöffnet — Wird ausgelöst, sobald sich die Fachtüren für einen Zustellversuch öffnen — egal ob der Kurier den Zugangscode am Bildschirm des Schließfachs eingegeben oder die Fernöffnungs-API genutzt hat — einschließlich erneuter Öffnungen nach Fachwechsel. Der opening-Block listet jedes geöffnete Fach mit grid_id, Hardware-Fachnummer compartment_number und pickup_locker_number (fortlaufende Anzeigenummer, spaltenweise von oben nach unten, dann von links nach rechts). Jedes Fach führt zusätzlich pickup_locker_code — die Bezeichnung "{shelf_code}-{pickup_locker_number}", zu der der Empfänger geschickt wird; null, wenn das Fach keine Abholnummer hat. Die Nutzlast enthält außerdem pickup_code — den Abholcode des Empfängers, der im Moment des Türöffnens vergeben wird; er bleibt nach der Einlegebestätigung des Kuriers derselbe Code und kann erst nach dieser Bestätigung zur Abholung verwendet werden.

In Paketfach zugestellt — Wird ausgelöst, wenn eine Einlagerung bestätigt wurde und die Pakete im Schließfach liegen. Die Nutzlast enthält den Abholcode des Empfängers. Jedes Fach führt zusätzlich pickup_locker_code — die Bezeichnung "{shelf_code}-{pickup_locker_number}", zu der der Empfänger geschickt wird; null, wenn das Fach keine Abholnummer hat. Bei über die Fernöffnungs-API geöffneten Türen schließt die Plattform die Einlagerung selbst ab, sobald der Schrank alle geöffneten Türen als geschlossen meldet; das Ereignis wird dann ohne confirm-Aufruf ausgelöst. confirmed_by nennt den Abschlussweg: courier_terminal, partner_api, door_close, timeout_door_closed oder console.

Abgeholt — Wird ausgelöst, wenn der Empfänger die eingelagerten Pakete abgeholt hat.

Zustellung fehlgeschlagen — Wird ausgelöst, wenn eine Zustellung fehlschlägt; Fehlercodes pro Paket sind enthalten.

Abgelaufen — Wird ausgelöst, wenn ein ungenutzter Zustellcode oder eine nicht abgeholte Einlagerung die Ablaufzeit überschreitet.

Storniert — Wird ausgelöst, wenn eine Zustellung vor Abschluss storniert wird.

Korrektur-Öffnung — Wird ausgelöst, wenn die belegten Fächer innerhalb des Korrekturfensters erneut geöffnet werden, um eine falsche Platzierung zu beheben — am Schließfach-Bildschirm oder über die API. Der correction-Block listet die wieder geöffneten Fächer auf. Jedes Fach führt zusätzlich pickup_locker_code — die Bezeichnung "{shelf_code}-{pickup_locker_number}", zu der der Empfänger geschickt wird; null, wenn das Fach keine Abholnummer hat.

partner_locker_delivery.event_type_code_rotated — Wird ausgelöst, wenn der Partner den Zustell- oder Abholcode einer Zustellung erneuert. Der rotation-Block nennt, welcher Code ersetzt wurde, wann, und ob die Empfängerbenachrichtigung erneut gesendet wurde — der neue Code selbst wird nie per Webhook übertragen; er wird nur in der direkten Antwort der Rotations-API offengelegt.

Zuweisung erstellt — Wird ausgelöst, wenn ein Auftrag dem Anbieter zugewiesen wird — durch eine automatische Regel oder manuell. Die Nutzlast enthält die Zuweisungsnummer, Auftragskennungen und die Paket-Trackingnummern.

Pakete übergeben — Wird ausgelöst, wenn das Lager alle Pakete der Zuweisung physisch an den Anbieter übergeben hat.

Zuweisung storniert — Wird ausgelöst, wenn die Plattform eine Zuweisung vom Anbieter zurückzieht. Das Feld reason unterscheidet cancelled (die Zuweisung wurde beim Frachtführer storniert), fallback_to_self_delivery (die Plattform hat den Auftrag zurück in die Eigenzustellung genommen) und reassigned (der Auftrag wurde an einen anderen Anbieter übertragen).

Teilweise zugestellt — Wird ausgelöst, wenn ein Teil einer Sendung zugestellt wurde, während andere Pakete noch unterwegs sind. Das Array packages enthält das Ergebnis je Paket, legs listet die beim Frachtführer gebuchten externen Aufträge auf — bei Frachtführern ohne mehrstückige Sendungen einen pro Paket.

Dem Auftrag wurde ein Fahrer zugewiesen (manuell, per Tourenplanung oder per automatischer Zuweisung). data.source = auto_assign, wenn der Orchestrator es getan hat.

Der Auftrag hat seinen Fahrer verloren (Übergabe, Entzug, Ablehnung, Zeitüberschreitung). data.previous_driver_id gibt an, wer ihn hatte.

Der Fahrer hat einen automatisch zugewiesenen Auftrag in der App angenommen (Fahrerdienst mit Annahmepflicht).

Der Fahrer hat einen zugewiesenen Auftrag abgelehnt; data.reason enthält den optionalen Freitextgrund.

Der Fahrer hat die Abholung begonnen (Status Abholung gestartet / Wird abgeholt).

Das Paket wurde abgeholt (Status Bereits abgeholt).

Das Paket ist unterwegs zum Empfänger (Status Zustellung gestartet / Wird zugestellt).

Die Zustellung war erfolgreich (Status Erfolgreich).

Der Zustellversuch ist fehlgeschlagen (Später erneut zustellen, Neuplanung erforderlich, Vom Empfänger abgelehnt).

Der Auftrag wurde storniert.

Mitarbeiter (oder, falls zugelassen, ein Fahrer) haben den Auftrag als bereit zur Abholung markiert (Dispositionsoptionen → Bereit zur Abholung).

Ein Fahrer hat sich in der App in den Dienst oder aus dem Dienst gemeldet (Option Fahrerdienst).

Eine Fahrerposition aus der App oder vom Tracker, je Fahrer gedrosselt über driver_location_min_interval_sec (Standard 60 s). Wird nur an driver_location_webhook_url gesendet.

Ein Paket wurde in das Gerät gelegt und wartet auf die nächste Person (Empfänger, Kurier oder Betreiber, siehe data.device_order.next_actor). due_at ist die Abholfrist.

Das Paket wurde von der Person entnommen, auf die es gewartet hat — dem Empfänger, dem Kurier oder dem Personal, das einen Smart Drop leert.

Das Personal hat das Paket aus dem Gerät entnommen. removal_reason nennt den Grund: overdue_return, handover, relay, anomaly oder recovery.

Das Paket hat sein due_at überschritten, ohne abgeholt zu werden. Es liegt noch im Gerät und sein Code funktioniert weiterhin; overdue_at wird gesetzt und next_actor wird zu operator.

Zu diesem Vorgang wurde ein Problem eröffnet (zum Beispiel door_left_open, deposit_unverified, item_missing, overdue). data.exception enthält id, type, severity und status.

Eine Person hat ein Problem zu diesem Vorgang geschlossen. data.exception.status ist resolved oder dismissed, und resolution_action gibt an, was getan wurde.