API de correo compatibles con Resend: lo que la compatibilidad no cubre

Qué significa realmente la compatibilidad de API

For email developers, Resend-compatible mail APIs implement the same request and response schemas as the provider they replace. If you use a Resend-compatible API, you can change your base URL and API key in your environment variables and your POST /emails calls will still work. It covers the syntax of the payload, the HTTP status codes, and the structure of the JSON response. It does not cover your sender reputation, your DNS configuration, your IP warm up, or your billing structure.

Como ingeniero que gestiona la cola de incidentes, he visto equipos que suponen que la "compatibilidad" es una migración con un clic. No lo es. Está migrando la interfaz, no la infraestructura.

La interfaz: lo que sí se cubre

Cuando un proveedor afirma ser compatible con Resend, normalmente replica el endpoint principal de envío. Eso le permite enviar un payload como este:

{ "from": "onboarding@example.com", "to": "user@gmail.com", "subject": "Welcome to the App", "html": "<strong>Hello!</strong>" }

Si la API es compatible, el servidor devolverá un 200 OK o un 201 Created con un ID de mensaje. Esta es la parte "fácil". Le evita reescribir su lógica de integración o cambiar de SDK. Para los equipos que crean agentes de IA, esta coherencia es vital. Cuando los agentes envían correos a través de un servidor MCP o una tarjeta A2A, dependen de esquemas predecibles para verificar que el efecto secundario (el envío del correo) realmente se produjo.

La infraestructura: lo que NO se cubre

La compatibilidad termina en la capa HTTP. Todo lo que ocurre después de que la API acepta la solicitud es específico de cada proveedor.

1. DNS y verificación de dominios

Su clave de API no lleva consigo la autorización de su dominio. No basta con cambiar las URL y esperar que sus correos estén autenticados. Debe volver a verificar su dominio con el nuevo proveedor, lo que implica agregar nuevos registros SPF, DKIM y DMARC a su DNS.

Si olvida actualizarlos, lo más probable es que sus correos se rechacen o se marquen como spam, porque el nuevo proveedor no está autorizado a enviar en su nombre. Puede usar el Verificador de DNS de correo de SendHQ para comprobar que sus registros se han propagado correctamente antes de hacer el cambio.

2. Reputación del remitente y calentamiento de IP

La reputación está ligada a la IP de envío y al dominio. Si pasa de un proveedor a otro, a menudo pasa a un nuevo conjunto de IP compartidas. Aunque su dominio tenga una reputación excelente, la nueva IP puede estar "fría" o, peor aún, compartida con alguien que actúa de mala fe.

La aceptación por el proveedor (la API responde "OK") es distinta de la entrega (el servidor receptor acepta el correo), que a su vez es distinta de la llegada a la bandeja de entrada (el correo aterriza en la carpeta principal). La compatibilidad cubre la aceptación por el proveedor. No hace nada por la entrega ni por la llegada a la bandeja de entrada.

3. Webhooks y esquemas de eventos

Aunque la API de envío sea compatible, los eventos de webhook (delivered, bounced, complained) a menudo no lo son. Si su sistema depende del seguimiento de eventos de entrega para activar lógica posterior, debe auditar los payloads de webhook del nuevo proveedor. Un evento bounce en un sistema puede ser un hard_bounce en otro.

El costo de la compatibilidad: la realidad de los precios

La compatibilidad le permite buscar mejores precios sin el costo de una reescritura completa. Sin embargo, los modelos de precios varían enormemente. Según datos de septiembre de 2026:

• Amazon SES: los precios más agresivos. La modalidad a la carta cuesta 0.10 USD por cada 1.000 correos (precios de Amazon SES). Los nuevos planes escalonados introducidos el 21 de julio de 2026 incluyen Essentials (0.16 USD por cada 1.000), Pro (0.22 USD por cada 1.000 más 105 USD al mes por región) y Enterprise (0.23 USD por cada 1.000 más 500 USD al mes).
• Resend: ofrece un plan gratuito de 3.000 correos al mes (con un máximo de 100 al día). El plan Pro cuesta 20 USD al mes por 50.000 correos, con excedentes a 0.90 USD por cada 1.000 (precios de Resend).
• Postmark: 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.20 USD por cada 1.000 (precios de Postmark).
• Mailgun: 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.10 USD por cada 1.000 (precios de Mailgun).
• SendGrid: el plan gratuito es ahora una prueba de 60 días, y Essentials empieza en 19.95 USD al mes (precios de SendGrid).

Para ponerlo en perspectiva: enviar 50.000 correos cuesta unos 5 USD con SES a la carta, pero unos 66 USD con los planes de Postmark. La compatibilidad de API hace posible esta optimización de costos sin un mes de trabajo de ingeniería.

Ingeniería para la confiabilidad y los agentes

Cuando trata el correo como un efecto secundario externo, sobre todo si usa agentes de IA, debe tener en cuenta los fallos. Que una API devuelva 200 OK no significa que el correo haya llegado al usuario.

Idempotencia

Si un agente reintenta una solicitud por un tiempo de espera agotado, corre el riesgo de enviar el mismo correo dos veces. Es una mala experiencia para el usuario. Debería usar una clave de idempotencia en sus encabezados. Así, si la misma solicitud se envía dos veces, el proveedor solo envía un correo.

Flujos de aprobación

Los agentes no deberían tener acceso ilimitado a su cuota de envío. Implemente una capa de aprobación para los envíos de alto volumen. Una lista sencilla para el correo gestionado por agentes:

1. Validación del esquema: ¿Coincide el payload con la especificación de la API compatible?
2. Límite de frecuencia: ¿Supera el agente el tope diario (por ejemplo, el límite gratuito de 100 al día de Resend)?
3. Idempotencia: ¿Existe una clave única para esta transacción concreta?
4. Intervención humana: ¿Requiere este correo una aprobación manual antes de la llamada a la API?

Lista de comprobación para la migración

Si va a pasar a un proveedor compatible con Resend, siga esta secuencia para evitar un colapso de la entrega:

• Configuración de DNS: Configure SPF, DKIM y DMARC. Lea nuestra guía sobre autenticación de correo para asegurarse de que no falte ningún registro.
• Verificación: Use una herramienta para confirmar la propagación de DNS.
• Calentamiento: Si envía volúmenes altos, traslade gradualmente el tráfico del proveedor anterior al nuevo. No mueva el 100 % del tráfico en una hora.
• Auditoría de webhooks: Asigne los tipos de eventos del nuevo proveedor a los esquemas de su base de datos interna.
• Manejo de errores: Pruebe cómo el nuevo proveedor maneja los correos no válidos. ¿Devuelve un 400 o un 202 con un evento de rebote posterior?

Resumen de las concesiones

Aspecto | ¿Lo cubre la compatibilidad? | Acción necesaria

Payload de la solicitud | Sí | Ninguna (si la especificación coincide)

Formato de la respuesta | Sí | Ninguna (si la especificación coincide)

Autenticación del dominio | No | Actualizar los registros DNS

Reputación de la IP | No | Periodo de calentamiento

Precios/cuotas | No | Revisar las páginas de precios del proveedor

Eventos de webhook | No | Actualizar los listeners de eventos

La compatibilidad es una herramienta de agilidad, no una varita mágica para la entregabilidad. Al separar la interfaz de la infraestructura, puede optimizar costos y rendimiento sin quedar atado al ecosistema de un único proveedor.

Si busca una API de correo con privacidad minimizada y preparada para agentes que simplifique esta infraestructura, conozca SendHQ.