Resend No Es Solo ‘SendGrid con Mejor UX’: Lo Que Descubrí Construyendo un Sistema de Batch Emails en 2026
Hoy aprendí que llevaba meses usando Resend a medias.
Lo tenía integrado para emails transaccionales — confirmaciones de registro, reseteo de contraseña, facturas. Funciona bien, la API es limpia, y el tier gratuito de 3.000 emails/mes cubre cualquier proyecto en fase early. Todo bien.
Pero cuando intenté construir un sistema de notificaciones que enviara a segmentos de usuarios — campañas, alertas, actualizaciones de producto — me choqué con una realidad que nadie documenta bien: Resend tiene una arquitectura de batch que es fundamentalmente distinta a enviar emails uno a uno.
Y si no la entiendes desde el principio, vas a construir algo que parece funcionar en local y se rompe en producción.
El Límite Que Nadie Menciona en los Tutoriales
La Batch API de Resend tiene un límite máximo de 50 destinatarios por llamada.
Parece poco, ¿verdad? Pero es una decisión de diseño deliberada. No es una restricción arbitraria — es la diferencia entre un sistema que procesas en colas controladas y un for loop que revienta tu rate limit y te deja sin capacidad de envío durante minutos.
La trampa es que muchos devs, cuando descubren resend.batch.send(), hacen esto:
Lo correcto es procesar en chunks:
Simple, pero crítico.
Idempotency Keys: El Superpower Que Nadie Usa
Aquí es donde Resend empieza a diferenciarse de verdad de otras APIs.
Las idempotency keys son una de esas features que hasta que no te quemas una vez, no entiendes su valor. La situación es esta: tienes un Server Action en Next.js que dispara un email de confirmación. El usuario hace clic dos veces seguidas, o hay un reintento de red, o tu cola de workers procesa el mismo job dos veces.
Resultado: el usuario recibe el mismo email dos veces. Parece un bug pequeño, pero en contextos como confirmaciones de pago o alertas críticas, es un problema serio.
La solución:
Con esta key, aunque el mismo endpoint se llame 10 veces con el mismo orderId, Resend enviará el email exactamente una vez. El resto de llamadas devuelven el mismo resultado sin disparar un nuevo envío.
Esto elimina toda una categoría de bugs de duplicados que en otras APIs tienes que manejar tú mismo con lógica de deduplicación en base de datos.
Natural Language Scheduling: La Feature Que Flipé
Otra cosa que descubrí tarde: Resend permite programar envíos con lenguaje natural.
También acepta ISO 8601 si prefieres precisión:
Para newsletters o digests programados, esto elimina la necesidad de un sistema de colas externo para casos simples. No necesitas Inngest o BullMQ solo para decir “envía esto mañana a las 9”.
Los Secretos del Test Mode Que Casi Todo El Mundo Ignora
Antes de hablar de webhooks, hay algo que me hubiera ahorrado mucho tiempo en staging: los emails de prueba especiales de Resend.
delivered@resend.dev→ simula un envío exitosobounced@resend.dev→ simula un bounce
Así puedes probar tu lógica de manejo de bounces sin contaminar listas reales ni arriesgar tu reputación de dominio.
Webhooks: Cerrar El Loop de Eventos
El sistema de batch sin webhooks está incompleto. Resend emite eventos para cada estado del email:
email.sentemail.deliveredemail.openedemail.clickedemail.bouncedemail.complained
En un Route Handler de Next.js:
Importante: verifica siempre la firma del webhook. Es el error que más veo en code reviews — endpoints de webhook sin verificación de firma son un vector de ataque real.
La Trampa de Pricing Que Requiere Decisión Arquitectónica
Un detalle que hay que tener claro desde el inicio: Resend distingue entre emails transaccionales (cubiertos en el tier gratuito) y marketing (requiere plan de pago para volúmenes altos y IPs dedicadas).
Si tu caso de uso mezcla ambos desde el principio — notificaciones del producto más newsletters — arquitectura las colas y los remitentes por separado desde el día uno. Cambiar esto después es más costoso que configurarlo bien desde el principio.
IPs dedicadas entran en juego cuando superas los 500 emails/día de forma consistente. Antes de ese volumen, las IPs compartidas de Resend tienen buena reputación y no necesitas preocuparte.
Checklist Para No Meterte en La Rabbit Hole de Deliverability
Antes de salir a producción con cualquier volumen de envío, verifica estos tres registros DNS:
- SPF → autoriza qué servidores pueden enviar en nombre de tu dominio
- DKIM → firma criptográfica que verifica la autenticidad del email
- DMARC → política de qué hacer cuando SPF o DKIM fallan
Resend tiene una guía de verificación de dominio decente, pero si empiezas a ver que tus emails caen en spam, el primer sitio donde mirar es DMARC. La mayoría de problemas de deliverability que veo en proyectos de otros devs son p=none en DMARC — que básicamente significa “no hagas nada si algo falla”.
Empieza con p=quarantine desde el principio.
Lo Que Cambié En Mi Stack Después de Todo Esto
La versión corta: Resend no es solo una API de emails más limpia. Es una arquitectura diseñada para developers que construyen productos con React y Next.js, con primitivas (idempotency, scheduling, batch con chunks controlados) que eliminan categorías enteras de bugs.
Pero hay que entender sus límites — el de 50 recipients por batch no es un bug, es una guardarraíl — y sus features menos visibles para aprovecharlo de verdad.
Si ya tienes Resend integrado para transaccional y vas a escalar a campañas: configura webhooks desde el primer día, usa idempotency keys en cualquier flujo que pueda reintentarse, y decide ahora si necesitas IPs dedicadas antes de que el volumen lo decida por ti.
