Monitor · Webhooks
Webhooks de correo
Deje de sondear paneles en busca de actualizaciones de entrega. Envíe eventos aceptado, entregado, rebotado y con queja directamente a su aplicación y flujos de trabajo.
UI de producto representativa — datos ilustrativos, no métricas reales de clientes.
De caja negra a flujo de eventos
Operaciones de correo orientadas a eventos
Use webhooks para sincronizar el estado del producto, activar reintentos, alertar equipos y mantener el estado del cliente preciso.
# Enviar un email crítico mediante una 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 — conserva tu integración y gana un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Capacidades de webhook
Los webhooks convierten el correo de una caja negra en un flujo de eventos que su producto puede interpretar en tiempo real.
Sincronización del estado de entrega
Actualice el estado visible para el usuario a medida que los mensajes pasan de aceptado a entregado o rebotado.
Automatización de fallos
Active rutas de reintento y alertas internas cuando se detecten fallos transitorios o permanentes.
Protección de reputación
Maneje eventos de queja y rebote automáticamente para mantener direcciones malas fuera de envíos futuros.
Integraciones de flujo de trabajo
Alimente CRM, almacén de datos, trabajadores de cola y sistemas de respuesta a incidentes.
Verificación de firmas
Valide firmas de webhooks entrantes para procesar solo eventos Sendarix de confianza.
Consumidores seguros ante reintentos
Diseñe manejadores idempotentes que procesen de forma segura entregas duplicadas y eventos retrasados.
Ciclo de vida del webhook
Un flujo directo para construir automatizaciones confiables orientadas a eventos.
1. Enviar mensaje
El mensaje entra en la canalización de entrega por API o SMTP.
2. Evento generado
El sistema de entrega crea eventos de estado (aceptado, entregado, rebotado, con queja).
3. Webhook entregado
Los eventos se publican en su punto final para procesamiento inmediato.
4. La aplicación reacciona
Sus sistemas actualizan el estado del usuario, activan trabajos o notifican equipos automáticamente.
Preguntas frecuentes
¿Los webhooks reemplazan por completo el sondeo?
Para la mayoría de los flujos orientados a eventos, sí. Los equipos aún usan analítica para análisis histórico e informes.
¿Qué eventos son más importantes al empezar?
Comience con entregado, rebotado y con queja. Luego amplíe a participación o eventos de flujo de trabajo personalizados.
¿Los webhooks son solo para sistemas grandes?
No. Incluso aplicaciones pequeñas se benefician de sincronización inmediata del estado y menos depuración manual de soporte.
¿Cómo verificamos que las solicitudes webhook son genuinas?
Use secretos compartidos, firmas o encabezados HMAC donde se proporcionen; valide marcas de tiempo para bloquear repeticiones; rechace cargas que fallen las comprobaciones antes de actualizar el estado de producción.
¿Qué pasa si nuestro punto final está caído cuando se dispara un webhook?
Confíe en políticas de reintento y haga manejadores idempotentes. Registre ID de eventos recibidos para que duplicados por reintentos no corrompan su base de datos ni notificaciones.
¿El procesamiento webhook debe ser síncrono en la solicitud HTTP?
Por lo general no. Acuse de recibo rápido, ponga el trabajo en cola y procese de forma asíncrona para que tareas lentas no provoquenos tiempos de espera y reintentos innecesarios.
¿Podemos distribuir el mismo evento a varios servicios internos?
Sí, mediante un bus de mensajes o enrutador. Mantenga un solo ingreso que valide y normalice cargas, luego distribuya a facturación, CRM, almacén o alertas.
¿Cómo ayudan los webhooks con rebotes y quejas?
Permiten actualizar listas de supresión, pausar campañas riesgosas o marcar cuentas casi en tiempo real en lugar de descubrir problemas horas después por tickets.
¿Necesitamos URL de webhook separadas para staging y producción?
Muy recomendado. Puntos finales aislados evitan que eventos de prueba toquen datos de usuarios reales y facilitan rotar credenciales de forma independiente.
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.
Productos relacionados
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
