Modos Live y Test

ReallyQuickEmails separa tráfico productivo y de desarrollo por el prefijo de la API key, no por un parámetro del request. Así un dev no manda tráfico de pruebas como producción por olvidar un flag.

El modelo

	Live	Test
Prefijo de key	`sk_proj_` o `sk_live_`	`sk_test_*`
Cuota mensual	cuenta	también cuenta — el envío es real
Payload `is_test`	`false`	`true`
Métricas del dashboard	producción	separadas (filtro Live/Test)
Webhook outbound	`webhook_url`	`webhook_url_dev`
Webhook inbound (replies)	`inbound_webhook_url`	`inbound_webhook_url_dev`
Envío real al inbox	sí	sí, también
Rate limit y suppression list	compartidos	compartidos

Test mode SÍ envía emails realesEl email sale de verdad y llega al inbox del destinatario. Puedes probar deliverability, render visual y comportamiento de los clientes de email igual que en producción. La diferencia está en métricas y routing de webhooks, no en el envío. Por eso, los envíos test también consumen cuota mensual.

Cómo se decide el modo

El modo viaja en la key. No hay parámetro mode, ni headers especiales, ni flag por endpoint:

Live
Test

curl -X POST https://api.reallyquickemails.com/v1/send-email \
  -H "Authorization: Bearer sk_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "recipient_email": "cliente@empresa.com",
    "sender_email": "noreply@tudominio.com",
    "subject": "Confirmación de pedido",
    "html_body": "<p>Tu pedido fue confirmado.</p>"
  }'

→ webhook a webhook_url → payload con is_test: false → actividad visible en las métricas de producción

curl -X POST https://api.reallyquickemails.com/v1/send-email \
  -H "Authorization: Bearer sk_test_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "recipient_email": "qa@empresa.com",
    "sender_email": "noreply@tudominio.com",
    "subject": "QA — confirmación",
    "html_body": "<p>Test desde staging.</p>"
  }'

→ webhook a webhook_url_dev → payload con is_test: true → actividad marcada como test, separada de tus métricas live

Webhook routing

Cada proyecto tiene cuatro URLs configurables (en pares outbound/inbound, una para cada modo):

project/
├─ outbound (delivered, bounced, opened, clicked)/
│  ├─ webhook_url        — recibe eventos de sk_live_* / sk_proj_*
│  └─ webhook_url_dev    — recibe eventos de sk_test_*
└─ inbound (replies con adjuntos)/
   ├─ inbound_webhook_url      — recibe replies de envíos live
   └─ inbound_webhook_url_dev  — recibe replies de envíos test

Si la URL `_dev` está vacía

Fallback a la URL de liveSi tu proyecto no tiene webhook_url_dev y envías con sk_test_*, los eventos caen a webhook_url. El payload llega con is_test: true para distinguirlos. Si ambas URLs están vacías, el evento no se entrega, pero el email sigue saliendo al inbox real. Ver el detalle en Webhooks.

`is_test` en el payload

Todos los webhooks (outbound e inbound) incluyen is_test: boolean en el body. Si quieres, recibe todo en una sola URL (webhook_url) y filtra lado-cliente, dejando webhook_url_dev vacío:

{
  "event": "email.delivery",
  "is_test": true,
  "data": { "...": "..." }
}

Pero mantenerlas separadas es lo recomendado para evitar accidentes operativos.

Caso de uso: setup multi-environment

Local dev
Staging
Production

# .env.local
RQE_API_KEY=sk_test_xxxxxxxxxxxx

Tu app local usa sk_test_. Los emails que mandes en desarrollo:

Llegan al inbox real (pruebas render, deliverability)
Quedan marcados con is_test: true — no mezclan métricas con prod
Webhooks funcionan idéntico (si configuras webhook_url_dev apuntando a un ngrok o servicio de testing)

# Variables del ambiente staging
RQE_API_KEY=sk_test_xxxxxxxxxxxx

Mismo sk_test_* que local. Staging manda emails reales marcados como test. Si tienes webhook listener en staging, apunta webhook_url_dev a esa URL.

# Variables del ambiente prod
RQE_API_KEY=sk_live_xxxxxxxxxxxx

Producción usa sk_live_* (o sk_proj_*). Webhooks a webhook_url (production listener).

Tu código no necesita saber el modoEl modo depende solo de qué env var lees. Los call sites a la API son idénticos. El switch vive en las variables de entorno de tu hosting, no en código donde es fácil olvidar un flag.

Casos extremos

Suppression list

Es compartida entre live y test. Si un destinatario se dio de baja por un envío live, los envíos test al mismo recipient también se omiten. En /v1/send-template-email recibes 200 con skipped: true; en /v1/send-email la supresión se aplica en segundo plano y la actividad queda con estado suppressed. Así, los tests de QA no reactivan la entrega a usuarios que ya no quieren tus emails.

Rate limit

Live y test comparten el rate limit y la cuota mensual de tu proyecto. Un spike de tests consume cuota real y afecta tu envío productivo.

Regenerar keys

Live y test se regeneran independientemente desde el dashboard: regenerar una no afecta la otra. La key anterior queda invalidada al instante.

Próximos pasos

API Keys — referencia completa con ejemplos de idempotency y dry-run.
Webhooks — formato de payload y verificación HMAC.
Quickstart — primer envío end-to-end con sk_test_*.

Guías

La app

Conceptos

API Reference

El modelo

Cómo se decide el modo

Webhook routing

Si la URL `_dev` está vacía

`is_test` en el payload

Caso de uso: setup multi-environment

Casos extremos

Suppression list

Rate limit

Regenerar keys

Próximos pasos

​El modelo

​Cómo se decide el modo

​Webhook routing

​Si la URL _dev está vacía

​is_test en el payload

​Caso de uso: setup multi-environment

​Casos extremos

​Suppression list

​Rate limit

​Regenerar keys

​Próximos pasos

El modelo

Cómo se decide el modo

Webhook routing

Si la URL `_dev` está vacía

`is_test` en el payload

Caso de uso: setup multi-environment

Casos extremos

Suppression list

Rate limit

Regenerar keys

Próximos pasos