Monitor · Webhooks
Webhooks e-mail
Arrêtez de poller les tableaux de bord. Poussez accepté, livré, rebond et plainte directement vers votre application et vos workflows.
UI produit représentative — données illustratives, pas de métriques client live.
De la boîte noire au flux d’événements
Opérations e-mail pilotées par les événements
Utilisez les webhooks pour synchroniser l’état produit, déclencher des nouvelles tentatives, alerter les équipes et garder le statut client exact.
# Envoyer un email critique via une routing policy 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" });
# SMTP drop-in — gardez votre intégration et gagnez un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Capacités des webhooks
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.
Synchronisation de l’état de livraison
Mettez à jour le statut utilisateur quand les messages passent d’accepté à livré ou rebond.
Automatisation des échecs
Déclenchez nouvelles tentatives et alertes internes en cas d’échecs transitoires ou permanents.
Protection de la réputation
Traitez plaintes et rebonds automatiquement pour exclure les mauvaises adresses des envois futurs.
Intégrations de workflow
Alimentez CRM, entrepôt de données, workers de file et systèmes d’incident.
Vérification des signatures
Validez les signatures des webhooks entrants pour ne traiter que des événements Sendarix de confiance.
Consommateurs sûrs face aux nouvelles tentatives
Concevez des gestionnaires idempotents pour dupliquer livraisons et événements retardés sans corruption.
Cycle de vie du webhook
Un flux simple pour des automatisations fiables pilotées par les événements.
1. Envoyer le message
Le message entre dans le pipeline via API ou SMTP.
2. Événement généré
Le système de livraison crée des événements de statut (accepté, livré, rebond, plainte).
3. Webhook livré
Les événements sont postés vers votre point de terminaison pour traitement immédiat.
4. L’application réagit
Vos systèmes mettent à jour l’état utilisateur, lancent des jobs ou notifient les équipes.
Questions fréquentes
Les webhooks remplacent-ils entièrement le polling ?
Pour la plupart des workflows pilotés par les événements, oui. L’analytique reste utile pour l’historique et le reporting.
Quels événements prioriser au départ ?
Commencez par livré, rebond et plainte. Étendez ensuite à l’engagement ou à des événements métier.
Les webhooks sont-ils réservés aux gros systèmes ?
Non. Même les petites applications gagnent en synchronisation immédiate et en moins de debug support manuel.
Comment vérifier que les requêtes webhook sont authentiques ?
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.
Si notre point de terminaison est indisponible ?
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.
Le traitement webhook doit-il être synchrone dans la requête HTTP ?
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.
Peut-on dupliquer le même événement vers plusieurs services ?
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.
Comment les webhooks aident-ils rebonds et plaintes ?
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.
Faut-il des URL webhook distinctes pour recette et production ?
Fortement recommandé. Des points de terminaison isolés évitent que les tests touchent les données réelles et facilitent la rotation des identifiants.
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.
Produits associés
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
