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.
Webhook‑Design für belastbare ERP‑Integrationen
So gestalten Sie Webhooks, die mit Schweizer ERP‑Systemen robust, sicher und skalierbar zusammenarbeiten. Tipps zu Retries, Signaturen, Event‑IDs und Monitoring.
Kurzantwort
Ein belastbares Webhook‑Design stellt sicher, dass ERP‑Systeme in Zürich, Bern oder Basel Ereignisse zuverlässig empfangen und verarbeiten. Setzen Sie idempotente Events mit eindeutigen IDs, signierte Payloads, exponentielle Retries und klaren HTTP‑Statuscodes ein. Ergänzen Sie Dead‑letter‑Queues, Beobachtbarkeit und SLA‑gerechte Dokumentation, damit wiederholte oder verspätete Zustellungen sicher gehandhabt werden.
Warum ein solides Webhook‑Design wichtig ist
ERP‑Systeme sind zentral für Rechnungen, Bestellungen und Lagerstände. Webhooks übertragen Änderungen in Echtzeit. Falsch gestaltete Webhooks führen zu doppelten Buchungen, verlorenen Events oder Sicherheitsrisiken. Ein klares Design reduziert Wiederherstellungsaufwand und verbessert Geschäftsprozesse in Schweizer KMU.
Eindeutige Event‑IDs und Idempotenz
Jedes Event braucht eine global eindeutige ID (UUID oder Kombination aus Objekt‑ID und Sequenz). Empfänger müssen Events idempotent verarbeiten: ein Event mit derselben ID darf keine zusätzlichen Seiteneffekte erzeugen. Speichern Sie verarbeitete IDs für eine sinnvolle Aufbewahrungszeit, abhängig von Geschäftsregeln.
Signatur und Authentizität
Schützen Sie Payloads mit HMAC‑Signaturen (z. B. SHA‑256) und einem gemeinsamen Secret oder mit JWT. Prüfen Sie die Signatur bei Empfang und verweigern Sie unautorisierte Requests. Zusätzlich hilft ein Zeitstempel gegen Replay‑Attacken: verwerfen Sie Nachrichten ausserhalb eines definierten Zeitfensters.
Retry‑Strategien und Backoff
Implementieren Sie exponentielles Backoff mit Jitter statt fester Intervalle. Beispiel: immediate retry, dann 2s, 8s, 1min, 5min, 30min. Begrenzen Sie Anzahl und Gesamtdauer der Versuche. Verwenden Sie klare HTTP‑Statuscodes: 2xx = Erfolg, 4xx = Clientfehler (nicht erneut versuchen), 5xx = Serverfehler (retry). Dokumentieren Sie das Verhalten im API‑Contract.
Deduplikation und Sequenzkontrolle
Nutzen Sie Event‑IDs und optional Sequenznummern oder Versionsfelder. Bei Reihenfolgeabhängigkeiten (z. B. Bestellstatus) implementieren Sie eine Sequenzprüfung. Bei fehlender Reihenfolgeversorgung erlauben Sie versetzte Verarbeitung oder führen Reconciliation‑Jobs durch.
Dead‑letter‑Queues und Nachbearbeitung
Wenn Zustellungen scheitern, schreiben Sie Events in eine Dead‑letter‑Queue. Dort kann ein Operator in Zürich oder automatisierte Prozesse Fehler analysieren und manuell oder per Retry korrigieren. Halten Sie Metadaten bereit: zuletzt gemachter Status, Anzahl Versuche, letzte Antwort des Empfängers.
Häufige Fragen
Wie lange soll ich verarbeitete Event‑IDs speichern?
Speichern Sie IDs mindestens so lange, wie eine typische Geschäftstransaktion rückwirkend verändert werden kann. In vielen Firmen sind 30 bis 90 Tage praktikabel. Entscheiden Sie anhand Compliance‑ und Audit‑Anforderungen.
Welche HTTP‑Statuscodes sollten Webhooks verwenden?
2xx für Erfolg. 4xx für dauerhafte Clientfehler (z. B. ungültige Signatur oder fehlende Ressourcen) — keine Retries. 5xx für temporäre Serverfehler — Retries geplant. 429 für Rate‑Limiting; geben Sie Retry‑After‑Header an.
Wie verhindere ich Replay‑Angriffe?
Kombinieren Sie Signaturprüfung mit Zeitstempel und Single‑use‑Nonces oder prüfen bereits verarbeitete Event‑IDs. Verwerfen Sie Nachrichten ausserhalb des erlaubten Zeitfensters.
Wann ist eine Dead‑letter‑Queue sinnvoll?
Sobald automatische Retries nach definierter Anzahl scheitern oder wenn Events fehlerhafte Payloads haben. DLQs ermöglichen gezielte manuelle Korrektur und verhindern Datenverlust.