Webhooks · Aktualisiert 6. April 2026 · ~7–10 Min

Make Webhooks (2026)

Webhooks sind der sauberste Weg, Szenarien sofort auszulösen, wenn ein Event passiert (Zahlung, Bestellung, Formular, Ticket…).

Sobald du Webhooks nutzt, wird dein Szenario Teil deiner „Realtime“-Oberfläche – und sollte entsprechend robust (und sicher) gebaut werden.

1) Instant (Webhook) vs Scheduled (Polling)

• Instant: Events werden an dich „gepusht“ → schnell, oft effizienter.
• Scheduled: du „pullst“ alle X Minuten → einfacher, aber kann bei Volumen viele unnötige Runs erzeugen.

Wenn die Quelle Webhooks anbietet und sie stabil sind: Instant bevorzugen.

2) Setup in 6 Schritten (bewährter Flow)

Typische Architektur:

1. Custom Webhook (Trigger)
2. Validierung (Pflichtfelder, Typen, erwartete Event-Typen)
3. Dedupe/Idempotenz (Event-ID speichern, Unique Key)
4. Routing (Router nach Event-Typ, Sprache, Team, Region …)
5. Write in Zielsystem(e)
6. Optional: Webhook Response (ACK, Redirect, Message)

Wichtig: Halte den Response-Pfad schlank. Wenn ein Anbieter nach wenigen Sekunden abbricht, kann „zu viel Arbeit vor dem Response“ Retries provozieren.

3) Payload-Design (damit du später skalierst)

Damit Webhooks sauber funktionieren, brauchst du einen stabilen Kern:

• Event-ID (oder eine Kombination aus Feldern, die eindeutig ist)
• Event-Typ (z. B. order.created, payment.succeeded)
• Timestamp (für Reihenfolge und Debugging)
• Version (falls du das Payload-Format änderst)

Wenn du selbst den Webhook sendest (z. B. aus deiner App): baue diese Felder von Anfang an ein. Das spart später extrem viel Zeit.

4) Sicherheit (Basics + DSGVO)

Minimum-Set:

• Payload strikt prüfen (Allowlist für Felder/Typen)
• Secret/Tokens verwenden (Header oder Query)
• Wenn verfügbar: Signaturen verifizieren (Stripe-Style)
• Sensible Daten nicht unnötig in Logs/Run-History speichern

DSGVO-Prinzip: Sende nur Daten, die du für die Automatisierung wirklich brauchst, und dokumentiere Zweck + Empfänger (Datenflüsse).

5) Retries & Fehlerpfade

Retries passieren u. a. bei:

• Timeouts (zu langsam geantwortet)
• Rate Limits beim Zielsystem
• transienten API-Fehlern

Best Practices:

• Idempotenz (Retry ≠ Duplicate)
• Backoff bei API-Calls, statt aggressiver Wiederholung
• Error Handler + Alerts bei wiederholten Failures
• „Dead letter“-Pfad: problematische Events sammeln, später manuell/automatisch neu abarbeiten

6) Operations & Kosten

Webhooks können bei Volumen schnell „skalieren“ – und damit Operations.

Kontrolle bekommst du durch:

• frühe Filter (irrelevante Events direkt stoppen)
• Loops begrenzen (Limit/Pagination sauber)
• Aggregation/Batching (wenn möglich)
• Retries nur gezielt, nicht überall

Wenn du es konkret rechnen willst: nutze den Kostenrechner und schätze Operations aus Event-Volumen × Steps × Sicherheitsmarge.