INBOUND-WEBHOOKS

Ereignisse der Außenwelt werden zu Auslösern in Ihrem Panel.

Zahlungsbestätigung, neue Bestellung, Anrufstatus, Release — die Webhooks Ihrer Anbieter sammeln sich an einer Adresse. SendNomi verifiziert die Signatur und leitet das Event sauber an Ihren eigenen Endpoint weiter; Nichtzugestelltes landet in der Queue und kehrt mit einem Klick zurück. Die Ära handgeschriebener Webhook-Handler endet heute.

6 Quellen
Zahlungen · CI · Telefonie · E-Commerce · CRM · Custom HMAC
HMAC + Replay
SHA-256/SHA-1-Signaturen, Timestamp- + Nonce-Schutz
Dead-Letter
nicht zugestellte Events landen in der Queue — ein Klick zurück
Delivery-Tester
Test-Event senden, Antwort inline sehen
01 / Verbinden

Sechs Quellkategorien, eine Empfangsadresse.

Im Panel legen Sie einen Empfänger an: Quelltyp wählen, das Shared Secret Ihres Anbieters einfügen. Tragen Sie die für Sie erzeugte SendNomi-Adresse in den Webhook-Einstellungen des Anbieters ein — fertig ist die Verbindung. Für Zahlungen, Code-Hosting, Telefonie, E-Commerce und CRM sind die gängigsten Signaturschemata integriert; einen Dienst außerhalb der Liste verbinden Sie per Custom-HMAC-Definition mit eigenem Secret und Header-Namen.

QUELLKATEGORIEN
  • Zahlungen & Abrechnung HMAC-SHA256
    Zahlung erfolgreich/fehlgeschlagen, Abonnement-Lebenszyklus, Rechnungsstellung.
  • Code-Hosting & CI HMAC-SHA256
    Push, Pull Request, Issue, Release.
  • Telefonie & SMS HMAC (URL-aware)
    SMS-Zustellberichte (DLR), Anrufstatus, Messaging-Benachrichtigungen.
  • E-Commerce-Plattformen HMAC-SHA256
    Bestellerstellung, Kundenaktualisierung, Fulfillment.
  • CRM & Außendienst-Tools HMAC oder OAuth-Bearer
    Lead, Deal, Support-Ticket, Kunden-Lebenszyklus.
  • Custom HMAC Ihr eigenes Secret
    Ein Dienst außerhalb der Liste: eigenes Shared Secret + Header-Name.
Frage zu einem bestimmten Anbieter? Der Support bestätigt innerhalb von 1 Werktag.
02 / Verifizieren

Gefälschte Payloads enden bei 401; Unsigniertes kommt nicht hinein.

Jeder Anbieter hat sein eigenes HMAC-Schema; SendNomi verifiziert die Signatur für Sie. SHA-256- und SHA-1-Signaturen werden unterstützt; die Timestamp- + Nonce-Prüfung verhindert, dass dieselbe Anfrage erneut abgespielt wird (Replay). Eine Anfrage, die die Prüfung nicht besteht, wird mit 401 abgewiesen — und jedes Event, akzeptiert oder abgelehnt, wird ins Log geschrieben. Eine Payload reist nur weiter, wenn ihre Signatur besteht.

# Signiertes Test-Event senden — Verifizierung live verfolgen
curl -X POST https://app.sendnomi.com/api/webhooks/inbound/<account-id>/test \
  -H "Content-Type: application/json" \
  -H "X-Signature: sha256=<signatur>" \
  -d '{"event":"test","payload":{...}}'

# 200 OK → Signatur gültig, Event akzeptiert
# 401    → Signatur ungültig oder wiederholte (Replay-)Anfrage
SHA-256SHA-1Timestamp + Nonce
03 / Verarbeiten

Ein verifiziertes Event erreicht Ihren Endpoint sauber.

Header werden normalisiert, die Payload wird auf Wunsch transformiert, und das Event wird an Ihre eigene Endpoint-URL weitergeleitet. Kann Ihr Endpoint gerade nicht antworten, wiederholt SendNomi mit 3 Versuchen + exponentiellem Backoff und Jitter; jeder Versuch ist an ein Timeout von 30 Sekunden gebunden. Trifft dieselbe Event-ID zweimal ein, sorgt das 24-Stunden-Dedup-Fenster für einmalige Verarbeitung — Ihr Kunde sieht nie eine doppelte E-Mail oder einen doppelten Datensatz.

EVENT-PFAD · VON DER QUELLE ZUM ENDPOINT
  1. Quell-Event
  2. Signaturprüfung
  3. Normalisierung
  4. Ihr Endpoint
Wiederholungen
3 Versuche
Backoff
exponentiell + Jitter
Timeout
30 Sekunden
Dedup-Fenster
24 Stunden — Event-ID oder sha(payload)
Trifft dieselbe Event-ID zweimal ein, wird sie einmal verarbeitet — keine doppelten Datensätze.
Drei häufige Workflows — ein Event trifft ein, die Aktion folgt von selbst

Zahlung erfolgreich → Rechnungs-E-Mail

  1. Das checkout-completed-Event trifft auf Ihrer SendNomi-Adresse ein
  2. Die Signatur wird verifiziert, das Event akzeptiert
  3. Eine Automation sendet die transaktionale E-Mail mit Ihrer Rechnungsvorlage
  4. Der Kunde findet die Rechnung innerhalb von Sekunden im Postfach

Neue Bestellung → Willkommensserie

  1. Das order-created-Event kommt von Ihrer E-Commerce-Plattform
  2. Der Kontaktdatensatz wird automatisch angelegt oder aktualisiert
  3. Bei der ersten Bestellung landet der Kontakt im Segment „first_purchase“
  4. Eine Willkommensserie aus 3 E-Mails startet von selbst

Neues Release → Changelog-Ankündigung

  1. Code-Hosting / CI sendet das Release-Event
  2. Der Release-Body wird von Markdown zu HTML gerendert
  3. Eine Kampagne geht an das Segment der Changelog-Abonnenten
  4. Ein-Klick-Abmeldung (RFC 8058) ist inklusive
04 / Überwachen

Eine gescheiterte Zustellung geht nicht verloren.

Der Live-Event-Feed listet jeden Webhook mit seinem Status: akzeptiert, abgelehnt, zugestellt, in Wiederholung. Mit dem Delivery-Tester senden Sie vom Panel ein Test-Event an Ihren Endpoint und sehen die Antwort inline. Ein Event, das alle Versuche verfehlt, fällt in die Dead-Letter-Queue; sobald Sie die Ursache behoben haben, senden Sie es mit einem Klick erneut. Kein Event verschwindet lautlos.

LIVE-EVENT-FEED · BEISPIELANSICHT
  • 14:32:07 payment.checkout_completed 200 · zugestellt
  • 14:31:52 order.created 200 · zugestellt
  • 14:31:40 call.status_changed Wiederholung 2/3
  • 14:31:05 release.published Dead-Letter Erneut senden
  • 14:30:48 unknown.source 401 · Signatur ungültig
Delivery-Tester: Senden Sie vom Panel ein Test-Event an Ihren Endpoint und sehen Sie die Antwort inline.
LOSLEGEN

Ihr erster Versand in wenigen Minuten.

Erstellen Sie Ihr kostenloses Konto — 500 Sendungen pro Monat, unbefristet.