Arrêtez de poller les tableaux de bord. Poussez accepté, livré, rebond et plainte directement vers votre application et vos workflows.
Utilisez les webhooks pour synchroniser l’état produit, déclencher des nouvelles tentatives, alerter les équipes et garder le statut client exact.
Webhook delivery depends on stable routing and proper retry logic. Pair with email routing for failover-aware delivery and deliverability monitoring for reputation-aware event handling.
Les webhooks transforment l’e-mail d’une boîte noire en flux d’événements que votre produit peut interpréter en temps réel.
Mettez à jour le statut utilisateur quand les messages passent d’accepté à livré ou rebond.
Déclenchez nouvelles tentatives et alertes internes en cas d’échecs transitoires ou permanents.
Traitez plaintes et rebonds automatiquement pour exclure les mauvaises adresses des envois futurs.
Alimentez CRM, entrepôt de données, workers de file et systèmes d’incident.
Validez les signatures des webhooks entrants pour ne traiter que des événements Sendarix de confiance.
Concevez des gestionnaires idempotents pour dupliquer livraisons et événements retardés sans corruption.
Un flux simple pour des automatisations fiables pilotées par les événements.
Le message entre dans le pipeline via API ou SMTP.
Le système de livraison crée des événements de statut (accepté, livré, rebond, plainte).
Les événements sont postés vers votre point de terminaison pour traitement immédiat.
Vos systèmes mettent à jour l’état utilisateur, lancent des jobs ou notifient les équipes.
An application POSTs a message via the email API. The recipient server returns a hard bounce, which is captured by email webhooks and relayed to your system. Your handler adds the address to the suppression list, ensuring no further send attempts. email analytics reflects the suppressed status in the next reporting cycle.
Sendarix delivers webhooks for the following event types. Filter by event type when configuring your endpoint.
| Event Type | Description |
|---|---|
accepted | Message accepted by Sendarix infrastructure |
delivered | Message accepted by recipient mail server |
bounce | Permanent delivery failure (invalid address) |
soft_bounce | Temporary delivery failure (mailbox full, Greylisted) |
complaint | Recipient marked message as spam |
unsubscribe | Recipient clicked unsubscribe link |
open | Message opened (tracking pixel fired) |
click | Tracked link clicked |
deferred | Temporary delay - will retry automatically |
Below is a simplified example of a delivery event:
{
"event": "delivered",
"message_id": "abc123",
"recipient": "user@example.com",
"timestamp": 1710000000
}
Not handling retries properly
Ignoring duplicate events (lack of idempotency)
Not verifying webhook signatures
Slow endpoints causing delivery timeouts
Pair webhooks with the email API for event-driven automation, and use email analytics to monitor delivery rates and identify issues in real time.
Every webhook delivers a JSON payload with a consistent envelope structure. Below are examples of the most common event types.
All payloads share this top-level structure:
{
"event_id": "evt_8f3k2j1h9g6d",
"event_type": "delivered",
"timestamp": "2026-04-19T14:32:01Z",
"message_id": "msg_abc123xyz",
"recipient": "user@example.com",
"data": {
// event-specific fields
}
}
Fired when a message is accepted by the recipient's mail server.
{
"event_id": "evt_8f3k2j1h9g6d",
"event_type": "delivered",
"timestamp": "2026-04-19T14:32:01Z",
"message_id": "msg_abc123xyz",
"recipient": "user@example.com",
"data": {
"smtp_response": "250 OK",
"server": "mail-sor-iad.example.com",
"delivery_latency_ms": 312
}
}
Fired when a message is rejected by the recipient's mail server. Includes bounce type (hard/soft) and error code.
{
"event_id": "evt_9h4k3l2m7n5p",
"event_type": "bounce",
"timestamp": "2026-04-19T14:30:45Z",
"message_id": "msg_abc123xyz",
"recipient": "invalid@example.com",
"data": {
"bounce_type": "hard",
"bounce_category": "invalid_email",
"smtp_code": 550,
"smtp_message": "No such user",
"was_automatic": true
}
}
Fired when a recipient marks your message as spam. Automatically suppressed for future sends.
{
"event_id": "evt_1a2b3c4d5e6f",
"event_type": "complaint",
"timestamp": "2026-04-19T15:01:22Z",
"message_id": "msg_abc123xyz",
"recipient": "user@example.com",
"data": {
"complaint_type": "abuse",
"feedback_type": "auth-failure",
"user_agent": "Mozilla/5.0 (complaint reporter)"
}
}
Fired when a message is opened by the recipient (requires tracking pixel).
{
"event_id": "evt_7g8h9i0j1k2l",
"event_type": "open",
"timestamp": "2026-04-19T14:45:10Z",
"message_id": "msg_abc123xyz",
"recipient": "user@example.com",
"data": {
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"os": "Windows 10",
"client": "Chrome 124.0"
}
}
Fired when a recipient clicks a tracked link in the message.
{
"event_id": "evt_3m4n5o6p7q8r",
"event_type": "click",
"timestamp": "2026-04-19T14:47:33Z",
"message_id": "msg_abc123xyz",
"recipient": "user@example.com",
"data": {
"link_id": "lnk_abc123",
"url": "https://yoursite.com/confirm?token=xyz",
"ip": "203.0.113.42",
"user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4)",
"os": "iOS 17.4"
}
}
Webhook delivery uses exponential backoff with jitter to handle transient failures without overwhelming your endpoint.
Failed deliveries (non-2xx, timeout, connection error) are retried at increasing intervals: attempt 1 immediately, attempt 2 after 30 seconds, attempt 3 after 5 minutes, attempt 4 after 30 minutes, attempt 5 after 2 hours, attempt 6 after 5 hours. After 6 failed attempts, the event is marked as permanently failed and no further retries occur.
▶ Use the event ID in a deduplication table or cache to prevent duplicate processing.
▶ Acknowledge the HTTP request immediately (< 1 second) and process events asynchronously.
▶ Return 2xx before validating signatures to avoid timeout-triggered retries of valid events.
▶ Log received event IDs to aid debugging and manual replay if needed.
▶ Implement a dead-letter queue for events that permanently fail so they can be manually inspected.
If your endpoint does not respond within 10 seconds, the delivery is marked as failed and enters the retry queue immediately.
Webhook endpoints should validate that requests originate from Sendarix and are not replayed or tampered with.
Each webhook request includes an X-Sendarix-Signature header containing an HMAC-SHA256 signature of the raw request body, signed with your endpoint's shared secret. Always verify this signature before processing the payload.
// Node.js signature verification example
const crypto = require('crypto');
function verifySignature(rawBody, signature, secret) {
const expected = crypto
.createHmac('sha256', secret)
.update(rawBody, 'utf8')
.digest('hex');
return crypto.timingSafeEqual(
Buffer.from(signature),
Buffer.from(expected)
);
}
// Express.js middleware
app.post('/webhooks', (req, res) => {
const signature = req.headers['x-sendarix-signature'];
const timestamp = req.headers['x-sendarix-timestamp'];
const secret = process.env.WEBHOOK_SECRET;
// Check timestamp freshness (reject > 5 min old)
if (Date.now() - parseInt(timestamp, 10) * 1000 > 300000) {
return res.status(401).send('Timestamp expired');
}
// Verify signature
const rawBody = req.rawBody; // must be raw buffer, not parsed JSON
if (!verifySignature(rawBody, signature, secret)) {
return res.status(401).send('Invalid signature');
}
// Process event
const event = JSON.parse(rawBody);
res.status(200).send('OK');
});
Requests also include an X-Sendarix-Timestamp header. Reject any request where the timestamp is older than 5 minutes to prevent replay attacks.
▶ Never expose your webhook secret in client-side code or version control.
▶ Use HTTPS endpoints only. HTTP endpoints will be rejected.
▶ Rotate secrets periodically and immediately upon suspected compromise.
▶ Validate both signature and timestamp on every request.
▶ Log all validation failures for security audit purposes.
Duplicate webhook deliveries are a reality, not an edge case. Network timeouts trigger Sendarix retries, and your endpoint may receive the same event more than once. Idempotent handlers ensure duplicates do not corrupt your application state.
Sendarix retries any delivery that returns non-2xx, times out, or fails DNS. If your endpoint returns 200 OK but the response is lost mid-network, Sendarix retries and delivers a second copy. Some load balancers also cause duplicate deliveries when retrying failed requests upstream.
The standard approach uses a deduplication table keyed on event_id. Before processing, check if the event_id has been processed. If yes, return 200 OK immediately. If no, process the event, mark it as processed, then return 200 OK.
This example uses a simple in-memory store. In production, use Redis or your database for durability across restarts.
// Node.js idempotent webhook handler
const processedEvents = new Map(); // Replace with Redis/DB in production
app.post('/webhooks', (req, res) => {
const event = req.body;
const eventId = event.event_id;
// Idempotency check - reject if already processed
if (processedEvents.has(eventId)) {
console.log(`Duplicate event received: ${eventId}`);
return res.status(200).send('OK'); // Still return 200 to stop retries
}
// Process the event
try {
switch (event.event_type) {
case 'delivered':
updateNotificationStatus(event.message_id, 'delivered');
break;
case 'bounce':
suppressRecipient(event.recipient);
break;
case 'complaint':
suppressRecipient(event.recipient, 'complaint');
break;
}
// Mark as processed before returning
processedEvents.set(eventId, Date.now());
return res.status(200).send('OK');
} catch (err) {
console.error('Processing error:', err);
return res.status(500).send('Processing failed');
}
});
// TTL cleanup - run periodically in production
setInterval(() => {
const cutoff = Date.now() - 24 * 60 * 60 * 1000;
for (const [id, timestamp] of processedEvents) {
if (timestamp < cutoff) processedEvents.delete(id);
}
}, 60 * 60 * 1000);
▶ Always check event_id before processing, never after.
▶ Mark events processed atomically: use INSERT ON CONFLICT UPDATE (Postgres) or equivalent.
▶ Keep processed event IDs for at least 24 hours to handle delayed retries.
▶ Process business logic in a separate transaction from the dedup check to avoid race conditions.
▶ Consider setting a TTL on your dedup cache so it does not grow indefinitely for high-volume event streams.
A robust webhook endpoint goes beyond signature verification. These practices ensure your integration handles production workloads reliably and avoids the pitfalls that cause data inconsistency and missed events.
Configure your HTTP client with a 10-second timeout for webhook requests. Sendarix waits up to 10 seconds for a response before triggering a retry. If your handler takes longer (e.g., database writes, external API calls), acknowledge the request immediately with 200 OK and process asynchronously via a job queue.
Webhook handlers should acknowledge within 1 second and defer actual work to a background job. This prevents timeout-triggered retries during slow processing and keeps your endpoint responsive for high event volumes. Use Redis, SQS, or a database-backed job queue.
Return 200 OK for successful processing or permanent failures (unknown event type, invalid payload structure). Return non-2xx only for transient errors (database unavailable, dependency timeout). This tells Sendarix whether to retry immediately or stop retrying.
Log the event_id, timestamp, and event_type on receipt before processing. Log the outcome (success/failure) and any error details after processing. This gives you a complete record for debugging missed events and reconstructing state during incidents.
After 6 failed delivery attempts, Sendarix marks the event as permanently failed. However, your handler may encounter errors that are not retriable (e.g., a specific recipient is blacklisted in your system, a custom business rule fails). Route these to a dead-letter queue for manual inspection rather than returning a retryable error code.
Campaign launches and provider incidents can generate webhook bursts of 10,000+ events per minute. Ensure your endpoint scales horizontally (multiple instances behind a load balancer) and your job queue can absorb spikes without losing events or falling behind.
These mistakes cause the most production incidents in webhook integrations. Avoid them to build a reliable event-driven system.
If your handler writes to a database, calls an external API, or performs complex computation before returning 200 OK, you risk timeouts and unnecessary Sendarix retries. Always enqueue work and return 200 immediately.
Events may arrive out of order (e.g., a complaint arrives before the delivered event for the same message). Your system must handle this by using message_id as the primary key for state, not relying on event arrival order.
If processing fails because the event is malformed or violates a business rule, return 200 OK to tell Sendarix not to retry. Returning 500 causes Sendarix to retry, which generates duplicate processing attempts and potentially corrupts your state.
Some webhook libraries accept GET and POST to the same endpoint. Sendarix sends POST only. Validate the HTTP method and return 405 Method Not Allowed for any other verb to prevent unexpected behavior.
Without event_id deduplication, retry-triggered duplicates cause double-processing: marking a user as unsubscribed twice, decrementing a credit balance twice, sending a notification twice. This is the most common cause of data corruption in webhook integrations.
Embedding the webhook secret in source code means rotation requires a code deployment. Store secrets in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault) and rotate without redeployment.
If your endpoint goes down, events queue at Sendarix for up to 5 hours. Monitor your endpoint's availability, queue depth in the Sendarix dashboard, and set up alerts for queue depth exceeding 1,000 events or processing lag exceeding 5 minutes.
Webhook event data is your primary signal for improving deliverability. Combine bounce and complaint events with your deliverability dashboard to identify reputation issues before they affect your sender score. High bounce rates (>5%) signal list quality problems; high complaint rates trigger provider-level filtering.
Webhook events integrate with your transactional email workflow to provide real-time status updates in your application UI. When a delivery confirmation webhook arrives, update the order status. When a bounce fires, trigger an alternative notification path.
Raw webhook events feed your email analytics pipeline with complete delivery and engagement data. Stream events to BigQuery or Redshift for custom reporting, A/B test analysis, and long-term trend tracking beyond what the Sendarix dashboard provides.
Real-time event delivery enables patterns that are difficult or impossible to implement with polling.
Update the notification_status field in your user database when messages are delivered or bounce. Show "Email sent" → "Delivered" in the UI without refreshing.
Automatically add bounced and complained addresses to your suppression list via webhook handler. Prevents wasted send attempts and protects sender reputation.
Feed open and click events into your CRM to score leads, trigger follow-up sequences, or update deal stages based on email engagement.
Monitor bounce rates and complaint rates via webhooks. Alert on-call engineers when bounce rates exceed 5% or complaint webhooks fire, indicating potential reputation issues.
Stream all email events to your data warehouse (BigQuery, Redshift, Snowflake) via webhook handler for real-time analytics, ML feature engineering, or compliance archival.
Trigger downstream workflows when email events fire: send a Slack message to sales when a lead opens a demo email, update shipping status when delivery confirmation arrives.
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
Chronologies client, nouvelles tentatives de notification, journalisation conformité, tableaux de support et synchronisation d’engagement CRM.
À utiliser avec l’API e-mail pour la logique produit et l’analytique e-mail pour l’analyse multi-flux.
What sets Sendarix apart: Webhooks on Sendarix are not a polling mechanism — they are pushed events with built-in retry, signature verification, and delivery confirmation. You get infrastructure control over event routing, not just a webhook URL.
Pour la plupart des workflows pilotés par les événements, oui. L’analytique reste utile pour l’historique et le reporting.
Commencez par livré, rebond et plainte. Étendez ensuite à l’engagement ou à des événements métier.
Non. Même les petites applications gagnent en synchronisation immédiate et en moins de debug support manuel.
Secrets partagés, signatures ou en-têtes HMAC ; validez les horodatages contre les rejoueurs ; rejetez les charges invalides avant de modifier l’état de production.
Comptez sur les politiques de nouvelle tentative et des gestionnaires idempotents. Journalisez les ID d’événements pour que les doublons ne corrompent pas la base ni les notifications.
En général non. Accusez réception vite, mettez le travail en file, traitez de façon asynchrone pour éviter timeouts et nouvelles tentatives inutiles.
Oui, via bus de messages ou routeur. Un point d’entrée unique valide et normalise, puis distribue vers facturation, CRM, entrepôt ou alertes.
Mise à jour des listes de suppression, pause de campagnes à risque ou signalement de comptes en quasi temps réel au lieu de découvrir le problème des heures plus tard.
Fortement recommandé. Des points de terminaison isolés évitent que les tests touchent les données réelles et facilitent la rotation des identifiants.
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.
Any response outside the 2xx range triggers a retry. Timeouts, connection refusals, and DNS failures also count as failures and trigger retry logic.
Default timeout is 10 seconds. If your endpoint does not respond within this window, the request is considered failed and enters the retry queue.
Yes. Configure event type filters per endpoint to receive only the events relevant to your integration (e.g., bounces and complaints only).
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.
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.
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.
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.
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.
Démarrez gratuitement sans carte bancaire, ou échangez avec les ventes pour les gros volumes et l’offre entreprise.
Commencer à envoyerParler aux ventes