Express Kurier. Direkt.
Auch Overnight.
x25pronto Schweiz bringt Ware direkt ans Ziel. Für kleine Ware fährt ein Auto. Für mehr Platz gibt es Transporter oder XL. Direkt, Express und Overnight fahren von Montag bis Sonntag. Freie Zeiten stehen im Kalender.
Webhooks richtig nutzen: Echtzeit‑Events für Ihre Lieferkette
Webhooks liefern Pickup-, Zustell- und Verzögerungs‑Ereignisse in Echtzeit an ERP, WMS oder CRM. Dieser Leitfaden zeigt Architektur, Sicherheit und Best Practices für Schweizer Firmen.
Kurzantwort
Webhooks sind eine einfache Methode, um Pickup-, Zustell- und Verzögerungs‑Events in Echtzeit an Ihr ERP, WMS oder CRM zu pushen. Richten Sie eine sichere HTTPS‑Endpoint ein, validieren Sie Signaturen, gestalten Sie Payloads idempotent und bauen Sie ein Retry‑/Dead‑letter‑Verfahren ein. So behalten Sie in Zürich, Basel oder Genf jederzeit den aktuellen Status Ihrer Sendungen.
Was Webhooks in der Logistik leisten
Webhooks sind HTTP‑Calls, die ein Kurierdienst sendet, wenn sich der Status einer Sendung ändert. Typische Events sind Pickup bestätigt, Fahrer unterwegs, zugestellt, verzögert oder Ablageort. Statt periodischer Abfragen (Polling) erhalten Ihre Systeme die Änderung sofort. Das reduziert Latenz, vereinfacht Inventar‑Updates und verbessert die Kundenkommunikation.
Welche Events Sie an ERP, WMS und CRM pushen sollten
Standard‑Events: pickup_requested, pickup_confirmed, in_transit, delayed, delivered, exception. Für ERP relevant sind Bestellnummern, Artikelmengen und Zustellstatus. WMS braucht Lagerplatzfreigabe, Retourinformationen und Zeitfenster. CRM bekommt Sendungsverfolgung, Empfangsbestätigung und Benachrichtigungs‑Trigger für Kundenkommunikation.
Payload‑Design und Idempotenz
Gestalten Sie Payloads klar und stabil: enthaltene Felder sollten feste Namen haben (z. B. order_id, shipment_id, event_type, timestamp, location). Fügen Sie ein event_id hinzu, das jede Nachricht eindeutig macht. Die Empfängerseite sollte Events anhand von event_id oder shipment_id deduplizieren. Idempotente Verarbeitung verhindert Doppelbuchungen oder falsche Lagerstände.
Sicherheit und Authentizität
Nutzen Sie HTTPS mit TLS und stellen Sie ein, dass nur bekannte IP‑Bereiche oder Signatur‑Header akzeptiert werden. Ein gängiger Ansatz ist ein HMAC‑Signature Header (z. B. X‑X25pronto‑Signature) über den Payload mit einem geteilten Secret. Vergleichen Sie die Signatur zeitfest, um Replay‑Angriffe zu verhindern. Loggen Sie verdächtige Versuche getrennt.
Zuverlässigkeit: Retries, Backoff und Dead‑letter
Planen Sie wiederholte Zustellversuche mit exponentiellem Backoff. Markieren Sie beim Empfängersystem erfolgreiche Verarbeitung mit HTTP 200/201. Bei anhaltenden Fehlern leiten Sie die Nachricht in eine Dead‑letter‑Queue und alarmieren ein On‑call oder ein Monitoring‑Dashboard. So gehen keine wichtigen Zustell‑Infos verloren.
Praktische Integrationstipps für Schweizer Unternehmen
Starten Sie mit einer Test‑Sandbox und minimalem Event‑Set. Verwenden Sie korrelierende IDs, die zu Ihren Bestellnummern in SAP, Abacus oder anderen ERP‑Systemen passen. Testen Sie Verzögerungs‑Szenarien (z. B. Stau auf A1) und prüfen Sie, wie Ihr CRM automatische Kundenbenachrichtigungen auslöst. Dokumentieren Sie das Schema und veröffentlichen Sie eine Change‑Policy für neue Events.
Häufige Fragen
Wie schnell kommen Webhook‑Events an?
Webhooks liefern Events in Sekunden bis wenigen Minuten, abhängig von Netzwerk und Verarbeitung. Sie sind deutlich schneller als Polling‑Intervalle.
Was tun bei doppelten Events?
Nutzen Sie event_id und idempotente Verarbeitung. Ignorieren Sie wiederholte event_id oder verifizieren Sie, ob der Status bereits angewendet wurde.
Wie prüfe ich die Echtheit eines Webhooks?
Verifizieren Sie eine HMAC‑Signatur im Header mit Ihrem Secret. Akzeptieren Sie nur HTTPS‑Verbindungen und erlauben Sie Anfragen nur aus bekannten IP‑Ranges, falls möglich.
Welche Felder sollten mindestens im Payload sein?
Mindestens: event_id, shipment_id, order_id, event_type, timestamp, location (optional: lat/long) und optional eine human_readable_message.