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.
Digitale Schnittstellen für SLA-Tracking
Praktische Anleitung, wie Schweizer Firmen SLA‑Tracking per API oder Webhook in ERP/TMS einbinden — inklusive Statuscodes, Beispiele und Implementationstipps.
Kurzantwort
SLA‑Tracking lässt sich mit klaren API‑Routen und Webhooks schnell in Ihr ERP oder TMS integrieren. Verwenden Sie Statuscodes für Pickup, InTransit, AttemptedDelivery und Delivered, abonnieren Sie Webhooks für Echtzeit‑Events und bauen Sie ein Fallback‑Polling für Ausfallzeiten. So sehen Sie Termine, Eskalationen und SLA‑Verletzungen direkt in Ihren Systemen.
Was ist das Ziel der Integration?
Ziel ist, SLA‑Daten automatisiert und zuverlässig ins ERP oder TMS zu bringen. Damit automatisieren Sie Eskalationen, informieren Kunden und messen Laufzeiten. Für Schweizer Firmen bedeutet das: transparente Lieferfenster, pünktliche Übergaben und dokumentierte SLA‑Verstösse.
Kernkomponenten: API, Webhook und Polling
Nutzen Sie eine REST‑API für Abfragen zu Aufträgen und Historie. Webhooks liefern Echtzeit‑Events bei Statuswechseln. Polling dient als Fallback, falls Webhooks ausfallen. Kombinieren Sie alle drei für Zuverlässigkeit: Webhooks für normale Operation, Polling z. B. alle 5–15 Minuten bei fehlender Webhook‑Bestätigung.
Empfohlene Statuscodes und Bedeutung
Definieren Sie eine kleine, klare Liste an Statuscodes. Beispiel: CREATED (Auftrag angelegt), ACCEPTED (Fahrer zugewiesen), PICKED_UP (Abholung erfolgt), IN_TRANSIT (Unterwegs), ATTEMPTED_DELIVERY (Zustellversuch), DELIVERED (Zugestellt), EXCEPTION (Problem), CANCELLED (Storniert). Jeder Code braucht ein Timestamp‑Feld und optional einen kurzen Reason‑Text für Exception‑Fälle.
API‑Beispiele und Payloads
GET /shipments/{id} liefert aktuellen Status, geplante SLA‑Zeitfenster und Historie. POST /shipments/{id}/events akzeptiert Status‑Updates vom Carrier. Beispiel‑Payload: {"status":"PICKED_UP","timestamp":"2026-09-07T09:12:00+02:00","location":{"lat":46.95,"lng":7.44}}. Validieren Sie Zeitstempel nach ISO‑8601 und verwenden Sie UTC oder Schweizer Zeitzone einheitlich.
Webhooks: Design und Sicherheitsbestimmungen
Webhooks senden Events an Ihre URL. Implementieren Sie HMAC‑Signaturen oder ein Shared‑Secret zur Verifikation. Bestätigen Sie eingegangene Events mit HTTP 200. Entwurf: POST /webhook/shipment_event mit JSON‑Body und Header x‑x25pronto‑signature. Planen Sie idempotente Handler, damit wiederholte Events die Daten nicht verfälschen.
SLA‑Logik und Alerts
Legen Sie Regeln für SLA‑Verstösse fest: z. B. wenn DELIVERED nach dem vereinbarten Zeitfenster eintrifft oder ATTEMPTED_DELIVERY ohne erneuten Versuch bleibt. Systemseitig lösen Sie automatische E‑Mails, Tickets oder SMS aus. Dokumentieren Sie Eskalationsstufen in Ihrem TMS oder Ticketing‑System.
Häufige Fragen
Wie schnell soll ich Polling konfigurieren?
Als Richtwert 5–15 Minuten. Für kritische Sendungen können Sie kürzere Intervalle wählen, aber Webhooks sind effizienter für Echtzeit‑Tracking.
Wie mache ich Webhooks idempotent?
Speichern Sie für jedes Event eine eindeutige Event‑ID. Wenn dieselbe ID erneut eintrifft, ignorieren Sie das Duplikat. So bleiben Status und Historie konsistent.
Welche Zeitstempelformate sind empfohlen?
Nutzen Sie ISO‑8601 mit Zeitzone, z. B. 2026-09-07T09:12:00+02:00. Alternativ UTC (Z‑Suffix) ist ebenfalls gut, wichtig ist Konsistenz.
Wie teste ich die Integration lokal?
Verwenden Sie ngrok oder ähnliche Tools, um lokale Endpoints zu exponieren. Simulieren Sie Webhooks und API‑Antworten mit Postman oder curl und prüfen Sie Idempotenz und Fehlerbehandlung.