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

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

Programming· 8 min read

El Envío de Email se Declaró "Resuelto" Hace una Década — Entonces ¿Por Qué una Startup de Y Combinator Construida Sobre un Solo POST /emails se Llevó a Toda una Generación de Desarrolladores?

Abre tu dashboard de SES. Mira la curva de aprendizaje. Ahora mira tu tiempo hasta el primer email enviado.

El consejo estándar lleva años siendo: "usa SES, es barato y es de Amazon". Infraestructura commodity. Entregabilidad como ventaja. Y sin embargo, en su primer año, Resend — una startup de Y Combinator Winter 2023 fundada por Zeno Rocha, el creador del tema Dracula — se convirtió en la opción por defecto para una nueva generación de desarrolladores.

*El producto que se vende no es infraestructura SMTP. Es experiencia de desarrollador. *

El mercado de APIs de email se reabre cada pocos años: un nuevo entrante re-platforma la misma infraestructura SMTP con mejor DX y gana a la siguiente generación de devs. Postmark lo hizo. Resend lo hizo después. Comparar proveedores por capacidad de relay es un error de categoría — la comparación que gana es tiempo hasta el primer email y workflow de plantillas.

En este tutorial te llevo de cero a producción con Resend en 5 pasos. Terminal en mano.

---

No Quieres Un Proveedor de Email. Quieres una API Minima

El bet de Resend es deliberadamente mínimo: enviar un email es una llamada REST con from/to/subject/body, envuelta por SDKs oficiales delgados.

Un solo endpoint. Sin dashboards gigantes, sin drag-and-drop, sin 40 SDKs pesados que te obligan a leer 200 páginas de docs antes de tu primer send.

La superficie pequeña tiene consecuencias directas: onboarding más rápido, menos bugs, menos docs que leer. Y porque los SDKs son wrappers delgados sobre REST plano, siempre puedes bajar a curl o a cualquier HTTP client. Esa transparencia es una señal de confianza en sí misma.

El primer email con el SDK de Node.js en menos de un minuto:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

¿Ves la superficie completa? Eso es todo. Para probar que el SDK es un wrapper delgado y no una caja negra, aquí está la misma llamada en curl:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Si algo falla y necesitas depurar, no dependes del SDK. Tienes raw HTTP.

Y si tu equipo usa otro lenguaje, no hay problema: Resend tiene SDKs oficiales para Node.js/TypeScript, Python, Ruby, Go, Java, PHP, Elixir, .NET, Swift y Kotlin. No te fuerza a un solo ecosistema.

---

El Paso Que Todos los Tutoriales Omiten: DNS Antes que API

Ahora viene la verdad incómoda.

El onboarding real de Resend no es la llamada a la API. Es verificar tu dominio. Y aquí es donde empiezan el 80% de los problemas de entregabilidad.

La infraestructura SMTP está resuelta. Tu reputación de dominio — y si tu email llega a la bandeja de entrada o a spam — no lo está. Eso se decide con SPF, DKIM y DMARC antes de enviar ni un solo email.

Registra tu dominio vía la API:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

La respuesta te devuelve los registros DNS que tu proveedor de DNS necesita (SPF, DKIM, DMARC). Añádelos en tu proveedor, vuelve a verificar, y ya tienes un dominio verificado.

Este paso — no la llamada de send — es donde se pierde el tiempo y donde la entregabilidad se gana o se pierde. El producto real de Resend es empaquetar esas preocupaciones operativas detrás de una API limpia: verificación de dominio, webhooks para eventos de entrega y rebote, tracking de opens y clicks.

---

React Email: El Cambio de Workflow Que Redefine Qué es una "Plantilla"

Ahora llegamos al bet estratégico de Resend.

React Email deja que escribas tus emails como componentes React tipados que se renderizan a HTML. Tu plantilla de welcome se convierte en un fichero versionado en tu repo, revisable en un pull request, testeable como cualquier otro código.

El mito de que una plantilla de email tiene que vivirse en un dashboard de drag-and-drop se cae aquí. Para equipos que ya revisan código, el email se vuelve revisable como cualquier otra feature.

Un ejemplo de WelcomeEmail.tsx:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Y antes del send, lo renderizas a HTML:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Ya no hay strings HTML gigantes embebidos en tu código de envío. El email es código, versionado, tipado y testeable. Y al final del día, React Email produce HTML estándar — por eso son provider-agnostic. Si mañana cambias de proveedor, tus componentes se quedan.

---

El Patrón de la Campana de Experiencia: 5 Pasos de Resend

Aquí está el framework que he usado en producción con mis propios productos (conversoriaecnae.es, gestoriascercademi.com, findemergencyplumber.com). Le llamo el Patrón de la Campana de Experiencia, porque el valor no está en la campana (el relay) sino en la forma que la envuelve: la experiencia.

Paso 1: Cuenta + Verificación de Dominio

Crea la cuenta y verifica tu dominio primero. Añade SPF, DKIM y DMARC tal y como te los da tu proveedor de DNS. Este paso DNS — no la llamada a la API — es la fricción real del onboarding y donde empiezan la mayoría de los problemas de entregabilidad.

Paso 2: Primer Email desde un Script Local

Usa el SDK oficial de tu lenguaje y apunta a un time-to-first-email por debajo de 5 minutos. La superficie mínima de la API es el punto: si tardas más de 5 minutos en enviar tu primer email, el proveedor está haciendo algo mal.

Paso 3: Plantillas Como Código

Saca tu markup de los strings HTML inline y muévelo a componentes React Email tipados en tu repo. Versionado, testeable, reutilizable entre todos tus flujos transaccionales (welcome, password reset, invoice). Este es el cambio de workflow, no una feature.

Paso 4: Webhooks y Tracking

Conecta los webhooks para email.delivered, email.opened y email.bounced. Loggea lo que pasa después del send y construye un pequeño path de retry para rebotes y fallos de API. La observabilidad post-send es donde pierdes el tiempo de ingeniería que SES nunca te resolvió.

Un handler mínimo:

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Paso 5: Adapter Provider-Agnóstico

Integra el envío detrás de una función adapter delgada y agnóstica al proveedor, para que Resend siga siendo swappable. La superficie de API es pequeña y los SDKs son wrappers delgados, así que la integración es barata de reemplazar. El bet queda reversible.

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Si mañana cambias de proveedor, cambias una función, no toda tu app.

---

Deliverability: El 80% Oculto de "Enviar Email"

La mayoría de los desarrolladores piensan que "enviar email" es la llamada a la API. En realidad, la llamada es el 20% visible. El 80% oculto es: reputación de dominio, alineación SPF/DKIM/DMARC, warm-up, manejo de rebotes.

Resend empaqueta toda esa pila operativa — dominios, webhooks, analytics de opens/clicks — detrás de una API limpia. Y además cubre casos operativos sin librerías extra: attachments y envíos programados.

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Este tutorial te enseña que el trabajo real está en el DNS, no en el send. Esa es la lección que los tutoriales de SES nunca te dieron.

---

¿Y si Ya Uso SES o SendGrid?

La objeción más común: "ya uso Mailgun, ¿por qué migrar?"

La migración es en su mayoría cambiar una función de send por otra. Y las plantillas React Email son HTML provider-agnostic al final del día. La pregunta real es: ¿cuánto tiempo de workflow pierde tu equipo cada vez que toca un email?

¿Y el lock-in? La superficie de API es pequeña y los SDKs son wrappers delgados. El adapter agnóstico del Paso 5 lo convierte en un bet reversible. Vas a querer reemplazar una librería de 20 líneas, no un monolito.

---

Tiempo de Ejecución

El mercado de email se reabre cada pocos años con el mismo movimiento: la misma infraestructura bajo mejor DX gana a la siguiente generación de devs.

Resend es ese movimiento para esta generación. Un solo POST /emails, SDKs delgados, React Email como workflow, y la pila operativa de entregabilidad empaquetada detrás de la API.

El producto no es el relay. Es la campana de experiencia que lo envuelve.

El email dejó de ser un problema de infraestructura hace una década. Se convirtió en un problema de workflow — y Resend lo ganó en su primer año porque entendió exactamente eso.

Artículos relacionados

---

¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter

Brian Mena

Brian Mena

Software engineer building profitable digital products: SaaS, directories and AI agents. All from scratch, all in production.

LinkedIn