Tracking de eventos
Eventos webhook por email enviado (email.send, email.delivery, email.bounce, email.complaint, email.deliverydelay, email.open, email.click, email.inbound), bounces hard vs soft con supresión automática, open tracking por pixel, click tracking por redirect 302 y verificación HMAC del payload.
Por cada email que envías, ReallyQuickEmails te dispara un webhook con eventos a medida que ocurren. Algunos vienen del proveedor de envío (entrega, rebote), otros los detecta RQE directamente (apertura, click).
Eventos disponibles
| Evento webhook | Cuándo dispara | Confiabilidad |
|---|---|---|
email.send | RQE aceptó el envío y lo despachó | 100% |
email.delivery | El servidor del destinatario aceptó el email | ~99% |
email.bounce | Email rebotado (hard o soft) | 100% |
email.complaint | Destinatario marcó como spam | 100% |
email.deliverydelay | Entrega temporalmente demorada | 100% |
email.open | Destinatario abrió el email | ~70% |
email.click | Destinatario hizo click en un link | ~99% |
email.inbound | Destinatario respondió tu email (solo envíos vía API) | 100% |
También existe email.reject (envío rechazado antes de salir). El detalle completo de cada evento y sus campos extra está en la referencia de Webhooks.
Bounces — soft vs hard
| Tipo | Descripción | Acción de RQE |
|---|---|---|
| Hard bounce | Dirección no existe (550 5.1.1) | Agrega el destinatario a la suppression list — los próximos envíos se omiten automáticamente |
| Soft bounce | Mailbox lleno, server temporalmente caído | Marca el evento, no agrega a suppression. Puedes volver a enviar |
Las quejas (email.complaint) también agregan al destinatario a la suppression list de forma automática.
Si tu tasa de bounces supera 2%, tu deliverability se degrada. Si supera 5%, el proveedor puede suspender tu envío. Limpia tu lista regularmente — un email viejo es un bounce esperando suceder.
Open tracking
RQE inyecta un pixel 1x1 transparente en el HTML del email. Cuando el cliente del destinatario carga las imágenes, dispara el evento email.open.
Por qué la confiabilidad es ~70%
- Outlook desktop bloquea imágenes externas por default → no detecta open
- Apple Mail iOS 15+ con MPP (Mail Privacy Protection) carga el pixel automáticamente al recibir → reporta open antes de que el usuario abra realmente
- Clientes de texto plano → no cargan imágenes
Trata los opens como aproximados
Los opens son señal de tendencia (¿este send lo abre más gente que aquel?), no de comportamiento individual exacto. Para conversión real, mira los clicks.
Click tracking
Antes de enviar, RQE reescribe los <a href> del HTML para que pasen por un endpoint de tracking que hace 302 redirect al destino original. El usuario no nota nada — el redirect es instantáneo. Solo falla si copia/pega el href manual (extremadamente raro).
Webhook payload
Tu webhook_url recibe POST con HMAC-SHA256 signature en el header X-RQE-Signature, firmada con tu API key del proyecto. Body de ejemplo para un email.delivery:
{
"event": "email.delivery",
"is_test": false,
"timestamp": "2026-04-29T15:30:42.123Z",
"project_id": "...",
"data": {
"activity_id": "...",
"message_id": "...",
"recipient": "user@example.com",
"event_type": "delivery",
"event_timestamp": "2026-04-29T15:30:42.000Z"
}
}Para el shape completo del payload por tipo de evento ver Webhooks → Payload outbound.
Verificación HMAC en Node
const crypto = require('crypto');
const expected = 'sha256=' + crypto
.createHmac('sha256', apiKey)
.update(rawBody)
.digest('hex');
if (req.headers['x-rqe-signature'] !== expected) {
return res.status(401).send('Invalid signature');
}