Monitor · Webhooks
Webhook e-mail
Smetti di fare polling delle dashboard per aggiornamenti di consegna. Invia accettato, consegnato, rimbalzato e reclamo direttamente alla tua applicazione e ai tuoi workflow.
UI prodotto rappresentativa — dati illustrativi, non metriche live dei clienti.
Da black box a flusso eventi
Operazioni e-mail guidate dagli eventi
Usa webhook per sincronizzare stato prodotto, attivare retry, avvisare team e mantenere accurato lo stato cliente.
# Invia un’email critica tramite 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 — mantieni l’integrazione e ottieni un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Capacità webhook
I webhook trasformano l'e-mail da scatola nera in flusso di eventi che il prodotto può interpretare in tempo reale.
Sincronizzazione stato consegna
Aggiorna lo stato visibile all'utente mentre i messaggi passano da accettato a consegnato o rimbalzato.
Automazione fallimenti
Attiva percorsi di retry e avvisi interni quando si rilevano fallimenti transitori o permanenti.
Protezione reputazione
Gestisci automaticamente reclami e rimbalzi per tenere indirizzi problematici fuori dagli invii futuri.
Integrazioni workflow
Alimenta CRM, data warehouse, worker di coda e sistemi di risposta agli incidenti.
Verifica firme
Valida le firme dei webhook in ingresso così elabori solo eventi Sendarix fidati.
Consumer sicuri con retry
Progetta handler idempotenti che elaborano in sicurezza consegne duplicate ed eventi ritardati.
Ciclo di vita webhook
Un flusso chiaro per costruire automazioni affidabili guidate dagli eventi.
1. Invia messaggio
Il messaggio entra nella pipeline di consegna tramite API o SMTP.
2. Evento generato
Il sistema di consegna crea eventi di stato (accettato, consegnato, rimbalzato, reclamo).
3. Webhook consegnato
Gli eventi vengono inviati al tuo endpoint per elaborazione immediata.
4. L'app reagisce
I tuoi sistemi aggiornano stato utente, attivano job o avvisano team automaticamente.
Domande frequenti
I webhook sostituiscono completamente il polling?
Per la maggior parte dei flussi guidati dagli eventi, sì. I team usano ancora analitica per analisi storica e reporting.
Quali eventi sono più importanti all'inizio?
Inizia con consegnato, rimbalzato e reclamo. Poi espandi a coinvolgimento o eventi workflow personalizzati.
I webhook sono solo per sistemi grandi?
No. Anche app piccole beneficiano di sincronizzazione immediata dello stato e meno debug supporto manuale.
Come verifichiamo che le richieste webhook siano autentiche?
Usa segreti condivisi, firme o header HMAC dove forniti; valida timestamp contro replay; rifiuta payload che falliscono i controlli prima di aggiornare stato produzione.
Se il nostro endpoint è giù quando parte un webhook?
Affidati a policy di retry e handler idempotenti. Registra ID evento ricevuti così duplicati da retry non corrompono database o notifiche utente.
L'elaborazione webhook deve essere sincrona nella richiesta HTTP?
Di solito no. Accetta rapidamente, metti in coda il lavoro a un job runner ed elabora in modo asincrono così task lenti non causano timeout e retry innecessari.
Possiamo fan-out dello stesso evento a più servizi interni?
Sì, tramite message bus o router. Un solo ingresso che valida e normalizza payload, poi distribuzione a fatturazione, CRM, warehouse o alerting.
Come aiutano i webhook con rimbalzi e reclami?
Permettono di aggiornare liste di soppressione, mettere in pausa campagne rischiose o segnalare account quasi in tempo reale invece di scoprire ore dopo dai ticket.
Servono URL webhook separati per staging e produzione?
Fortemente consigliato. Endpoint isolati evitano che eventi di test tocchino dati utenti reali e facilitano rotazione credenziali in modo indipendente.
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.
Prodotti correlati
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
