Resend API Tutorial: React Email + SDK en 5 Pasos para Dejar de Escribir HTML en Strings

La Guerra de las APIs de Email ya Terminó. Resend Ganó.

La mayoría de los desarrolladores sigue pegando strings HTML en variables de entorno.

Como si fuera 2015.

*El problema no es que SendGrid o AWS SES no funcionen. Es que hacéis 20 pasos para algo que debería tomar uno. *

Llevo años desplegando sistemas de email transaccional para agencias y productos digitales. He visto equipos pasarse semanas configurando SPF, DKIM y DMARC en SendGrid, solo para descubrir que sus correos iban a spam porque la verificación de dominio estaba mal.

Resend elimina ese problema con una sola decisión de diseño: un endpoint POST /emails, un SDK que cabe en una línea, e integración nativa con React Email.

Vale, suena a hype de startup. Pero los datos no mienten: el tiempo de first-to-send con Resend se mide en minutos, no en horas. Y la entregabilidad mejora no porque Resend tenga servidores mágicos, sino porque fuerza la configuración correcta desde el primer paso.

Vamos al código.

---

El Problema: El 95% del Email Stack es Configuración Inútil

La sabiduría convencional dice que necesitas un proveedor legacy como SendGrid o AWS SES porque están "battle-tested".

*La verdad incómoda: la mayoría de los problemas de entregabilidad no son de infraestructura. Son de configuración. *

SendGrid tiene APIs separadas para:

Mail send
Template management
Sender identities
Suppression lists
Stats y analytics

Cada una con esquemas de autenticación diferentes. Cada una con su propia curva de aprendizaje.

El resultado: equipos que saltan entre cinco paneles de control, copian plantillas HTML desde el WYSIWYG del proveedor, y acaban con emails que renderizan fatal en Outlook o Gmail.

Resend reduce todo a una llamada HTTP con cinco campos: from, to, subject, html (o text), y opcionalmente react (para usar componentes React Email).

Y sí, sé lo que estás pensando: "Es que SendGrid tiene A/B testing, predictive sending, y mil features más."

*El 90% de los equipos no usa ni una de esas features. *

Las pocas veces que las necesitas, las integras con herramientas especializadas como Customer.io que se sientan encima de Resend. No necesitas un proveedor de email que también sea plataforma de marketing. Necesitas un proveedor que mande emails y no se interponga en tu camino.

---

La Evidencia: Resend No es un Proveedor Pequeño

Si tu objeción es que Resend es "demasiado nuevo para producción", mirad esto:

Empresas como Vercel, Arc y Dub.co envían millones de emails al mes con Resend.
Resend adquirió la infraestructura de email de Request Network en 2023, señal clara de adopción enterprise.
Por debajo, Resend usa AWS SES con enrutamiento inteligente. Te da la fiabilidad de AWS con una experiencia de desarrollador infinitamente mejor.

No estás apostando por una startup sin respaldo. Estás pagando por la capa que elimina la fricción que AWS SES te impone.

El verdadero riesgo no es que Resend falle. Es que sigas perdiendo horas con configuraciones que Resend resuelve en cinco minutos.

---

🔥 El Método de 5 Pasos para Abandonar SendGrid

Aquí va el framework. Son cinco pasos. Si ya tienes un proyecto Node.js, en menos de una hora estás enviando emails en producción.

1. Verifica tu Dominio en Resend

Esto es lo único que no puedes saltarte. Y es donde Resend gana la partida.

Entra en el dashboard de Resend, añade tu dominio, y te dará tres registros DNS que añadir:

DKIM: firma criptográfica que prueba que el email viene de tu dominio
SPF: autoriza a Resend a enviar en tu nombre
DMARC: política sobre qué hacer si DKIM o SPF fallan

❌ En SendGrid: tienes que investigar qué valores poner, repetir el proceso para cada subdominio, y rezar para que los registros propaguen bien.

✅ En Resend: el dashboard te da las instrucciones exactas. Las pegas en Cloudflare o tu DNS provider. Esperas 5-10 minutos. Listo.

*El 80% de los problemas de entregabilidad desaparecen en este paso. *

La mayoría de equipos que venían de SendGrid o Mailgun tenían DKIM mal configurado desde el día uno. Emails en spam. Clientes que no recibían confirmaciones de registro. Y echaban la culpa al proveedor.

Resend fuerza la configuración correcta. No te deja opción a equivocarte.

2. Instala el SDK y Configura tu Cliente

Abre tu terminal y ejecuta:

Luego crea una instancia del cliente:

Una línea. Ya tienes tu cliente de email listo.

No necesitas configurar transportes, ni autenticación SMTP, ni recordar qué puerto usa SendGrid para la API v3. El SDK maneja todo.

Resend tiene SDKs para TypeScript/JavaScript, Python, Ruby, Go, PHP, Elixir y Rust. El patrón es idéntico en todos los lenguajes. Si sabes uno, sabes todos.

3. Crea tu Primer Componente React Email

Aquí viene lo que realmente diferencia a Resend.

En lugar de escribir HTML plano en un string:

Escribes un componente React:

Esto no es "un extra". Esto es el núcleo del ahorro de tiempo.

Con React Email puedes:

Type-checkear props (adiós a los undefined en los templates)
Reutilizar componentes entre emails (header, footer, botones)
Previsualizar en tiempo real con el servidor de desarrollo de React Email
Renderizar server-side y pasarle el HTML directamente a Resend

El salto de productividad es enorme. Pasas de gestionar templates en un editor WYSIWYG externo a tratarlos como el resto de tu interfaz.

4. Envía tu Primer Email con Resend SDK

Renderizas el componente y lo envías:

Cinco campos. Una llamada. El email está en el buzón del usuario en segundos.

Comparad esto con SendGrid, donde necesitas:

Crear un sender identity
Configurar un template en el dashboard
Obtener el ID del template
Llamar a /v3/mail/send con un payload de 30 campos
Gestionar los errores con códigos HTTP oscuros

La diferencia no es marginal. Es estructural.

5. Configura Webhooks para Eventos en Producción

Enviar emails es solo la mitad del trabajo. Saber qué ha pasado con ellos es la otra.

Resend expone webhooks con esquemas JSON consistentes para:

email.delivered: el email llegó al buzón
email.opened: el usuario lo abrió
email.clicked: el usuario hizo clic en un enlace
email.bounced: el email rebotó (dirección inválida)
email.complained: el usuario marcó como spam

Aquí tienes un manejador de webhook para Next.js 16:

Los webhooks de Resend tienen reintento automático y entrega garantizada. No como otros proveedores donde el payload cambia de estructura sin avisar y tienes que debuggear con logs opacos.

Esto te permite:

Limpiar automáticamente tu base de datos de emails inválidos
Responder a quejas de spam antes de que afecten tu reputación
Monitorizar tasas de apertura y clics en tiempo real

---

Análisis: Por Qué Resend Gana a Largo Plazo

No estoy diciendo que Resend sea perfecto para todos los escenarios.

Si necesitas enviar millones de emails promocionales con segmentación compleja, probablemente quieras una herramienta de marketing automation dedicada.

Pero para el 95% de los casos — email transaccional, notificaciones, confirmaciones, recuperación de contraseñas — Resend es superior. No por la tecnología subyacente, sino por la experiencia del desarrollador.

Cada minuto que ahorras en configuración de email es un minuto que puedes invertir en producto, en testing, en lo que realmente importa.

Los equipos que migran a Resend suelen descubrir que sus problemas de entregabilidad eran culpa de configuraciones incorrectas en la plataforma anterior, no de limitaciones técnicas.

*El email no debería ser el cuello de botella de tu producto. Con Resend, deja de serlo. *

---

Conclusión

Resend no gana por ser más barato o por tener más servidores.

Gana porque respeta tu tiempo como desarrollador.

Un solo endpoint. React Email nativo. Webhooks que funcionan. SDKs que caben en un tuit.

El mito de que necesitas un proveedor legacy "battle-tested" se cae cuando te das cuenta de que la mayoría de sus features no las usas, y lo que sí usas está peor diseñado.

La guerra de las APIs de email ha terminado. El ganador es el que te deja volver a lo que importa: construir producto.

Instala `resend`, escribe un componente React, y haz tu primer send en los próximos diez minutos. El resto del stack legacy que dejes atrás no te va a hacer falta.