Monitor · Webhooks
Email Webhooks
Hören Sie auf, Dashboards für Zustell-Updates zu pollen. Akzeptiert, zugestellt, gebounct und beschwert – direkt in Ihre Anwendung und Workflows.
Repräsentative Produkt-UI — Beispieldaten, keine Live-Kundenmetriken.
Von Blackbox zu Event-Stream
Ereignisgesteuerte E-Mail-Operations
Webhooks synchronisieren Produktstatus, lösen Retries aus, alarmieren Teams und halten Kundenstatus aktuell.
# Kritische E-Mail über eine Routing-Policy senden curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# Drop-in SMTP — Integration behalten, Control Plane gewinnen host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Webhook-Funktionen
Webhooks machen aus E-Mail einen Event-Stream, den Ihr Produkt in Echtzeit auswerten kann.
Zustellstatus-Sync
Nutzerseitigen Status aktualisieren, wenn Nachrichten von akzeptiert zu zugestellt oder gebounct wechseln.
Fehler-Automatisierung
Retry-Pfade und interne Alerts auslösen bei transienten oder permanenten Fehlern.
Reputationsschutz
Complaint- und Bounce-Events automatisiert behandeln, damit problematische Adressen nicht erneut angesprochen werden.
Workflow-Integrationen
Events in CRM, Data Warehouse, Queue-Worker und Incident-Response-Systeme einspeisen.
Signatur-Verifizierung
Eingehende Webhook-Signaturen prüfen, damit nur vertrauenswürdige Sendarix-Events verarbeitet werden.
Retry-sichere Consumer
Idempotente Handler entwerfen, die doppelte Zustellungen und verzögerte Events sicher verarbeiten.
Webhook-Lebenszyklus
Ein klarer Ablauf für zuverlässige ereignisgesteuerte Automatisierungen.
1. Nachricht senden
Nachricht gelangt über API oder SMTP in die Zustell-Pipeline.
2. Event erzeugt
Das Zustellsystem erzeugt Status-Events (akzeptiert, zugestellt, gebounct, beschwert).
3. Webhook zugestellt
Events werden an Ihren Endpunkt zur sofortigen Verarbeitung gepostet.
4. App reagiert
Ihre Systeme aktualisieren Nutzerstatus, starten Jobs oder benachrichtigen Teams automatisch.
Häufig gestellte Fragen
Können Webhooks Polling vollständig ersetzen?
Für die meisten ereignisgesteuerten Workflows ja. Analytics nutzen Teams weiterhin für historische Analyse und Reporting.
Mit welchen Events sollten wir starten?
Beginnen Sie mit zugestellt, gebounct und beschwert. Erweitern Sie um Engagement oder benutzerdefinierte Workflow-Events.
Sind Webhooks nur für große Systeme?
Nein. Auch kleine Apps profitieren von sofortigem Status-Sync und weniger manuellem Support-Debugging.
Wie prüfen wir, dass Webhook-Requests echt sind?
Shared Secrets, Signaturen oder HMAC-Header wo vorhanden; Zeitstempel validieren gegen Replays; Payloads mit fehlgeschlagenen Checks ablehnen, bevor Produktstatus geändert wird.
Was, wenn unser Endpunkt beim Webhook ausfällt?
Auf Retry-Richtlinien setzen und Handler idempotent gestalten. Empfangene Event-IDs loggen, damit Duplikate aus Retries Datenbank oder Nutzerbenachrichtigungen nicht korrumpieren.
Soll die Webhook-Verarbeitung synchron in der HTTP-Anfrage laufen?
Meist nein. Schnell bestätigen, Arbeit in einen Job-Runner einreihen und asynchron verarbeiten – damit langsame Tasks keine Timeouts und unnötige Retries auslösen.
Können wir dasselbe Event an mehrere interne Services verteilen?
Ja, z. B. über einen Message Bus oder Router. Ein Eingang validiert und normalisiert Payloads, dann Verteilung an Billing, CRM, Data Warehouse oder Alerting.
Wie helfen Webhooks bei Bounce- und Complaint-Handling?
Sie aktualisieren Suppression-Listen, pausieren riskante Kampagnen oder markieren Konten nahezu in Echtzeit – statt Stunden später über Support-Tickets.
Brauchen wir separate Webhook-URLs für Staging und Produktion?
Sehr empfehlenswert. Isolierte Endpunkte verhindern, dass Test-Events Live-Daten berühren, und erleichtern unabhängiges Credential-Rotation.
What is the format of webhook payloads?
All payloads are JSON with a consistent envelope: event type, timestamp, message ID, and event-specific data. See the Payload Examples section for full schemas.
What happens if our endpoint returns a non-2xx response?
Any response outside the 2xx range triggers a retry. Timeouts, connection refusals, and DNS failures also count as failures and trigger retry logic.
How long does Sendarix wait for our endpoint to respond?
Default timeout is 10 seconds. If your endpoint does not respond within this window, the request is considered failed and enters the retry queue.
Can we filter which events we receive?
Yes. Configure event type filters per endpoint to receive only the events relevant to your integration (e.g., bounces and complaints only).
What HTTP methods does Sendarix use for webhook delivery?
Sendarix sends POST requests only. If your endpoint receives a GET, PUT, PATCH, or DELETE request to the webhook URL, return 405 Method Not Allowed. This prevents accidental processing of unrelated traffic that may hit your endpoint.
How do we handle webhooks during deployment downtime?
Sendarix queues events during the retry window. If your endpoint is down for less than 5 hours, all events are preserved and delivered when your endpoint returns. For extended downtime (maintenance windows, incidents), queue events in Sendarix and process them after recovery via the event replay API.
Should our webhook endpoint be idempotent across different event types?
Yes. Process the event_id regardless of event_type. A given event_id represents one specific event (e.g., evt_abc123 = bounce for msg_xyz). If you receive evt_abc123 twice, return 200 OK on the second attempt without reprocessing. The event_id is globally unique across all event types.
How do we test webhooks in a staging environment without affecting production data?
Configure a separate webhook endpoint in your staging environment with its own secret. Use the Sendarix sandbox mode to send test events that do not count against production limits or affect real recipient addresses. This allows integration testing without generating fake suppression entries or polluting analytics.
What is the maximum number of events we can receive per second?
Sendarix delivers events in real time with no artificial rate limit on webhook delivery. During burst scenarios (e.g., a campaign delivery wave), your endpoint may receive hundreds of events per second. Design your endpoint to scale horizontally and your job queue to absorb these spikes. Monitor queue depth via the API to detect when processing falls behind.
Verwandte Produkte
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
