Un API de correo entrante recibe el correo enviado a una dirección o dominio que controlas, lo parsea y lo entrega a tu aplicación como un POST HTTP estructurado. En lugar de ejecutar un servidor de correo y consultar un buzón por IMAP, apuntas los registros MX de tu dominio al proveedor, y cada mensaje entrante llega a tu endpoint con las cabeceras, el cuerpo y los adjuntos ya parseados en JSON.
¿Cómo funciona el correo entrante?
El enrutamiento comienza con DNS. Configuras los registros MX de un dominio o subdominio (por ejemplo reply.yourapp.com) para que apunten a los servidores de correo del proveedor de inbound. Cuando alguien envía un mensaje a cualquier dirección de ese dominio, llega a la infraestructura del proveedor en lugar de a la tuya. El proveedor acepta el mensaje, lo parsea y hace una solicitud POST a la URL que registraste, con el contenido ya parseado.
Un payload parseado normalmente incluye el remitente y el destinatario, el asunto, el cuerpo en texto plano y HTML, el conjunto completo de cabeceras y cualquier adjunto (a menudo codificado en base64 o referenciado por URL). Tu aplicación lee ese JSON y actúa en consecuencia, sin código SMTP ni IMAP que mantener. El mecanismo de entrega es un webhook, así que aplican las mismas reglas: responde con un 2xx rápido y luego procesa el mensaje de forma asíncrona.
¿Para qué se usa?
El correo entrante convierte los mensajes recibidos en eventos de aplicación. Los patrones más comunes incluyen:
- Gestión de respuestas. Envía una notificación desde
notifications@yourapp.com, y cuando un usuario responde, la respuesta llega como un POST para que puedas vincularla de vuelta a una conversación. - Tickets de soporte. El correo enviado a
support@yourapp.comse convierte en un nuevo ticket, con el remitente y el cuerpo mapeados directamente a tu mesa de ayuda. - Parseo a base de datos. Los recibos reenviados o correos estructurados se parsean y se escriben en una tabla, sin entrada manual.
- Correo a acción. Un mensaje a una dirección especial dispara un flujo de trabajo: crear un registro, lanzar un trabajo o publicar en un canal.
¿En qué se diferencia de enviar correo?
El correo saliente y el entrante son tareas separadas. El saliente es tu aplicación entregando correo a destinatarios a través de SMTP o una HTTP de envío API. El entrante es lo contrario: remitentes externos entregan correo a tu aplicación. Una integración de correo completa suele hacer ambas cosas, enviar notificaciones y recibir las respuestas, pero se configuran de forma independiente y el lado entrante es el que depende de tus registros MX.
¿Por qué no consultar un buzón por IMAP?
Puedes ejecutar un poller IMAP contra un buzón real, pero tiene un coste continuo. Gestionas credenciales, decides con qué frecuencia consultar (lo que añade latencia y conexiones inactivas), parseas MIME en crudo y controlas qué mensajes ya procesaste. Un API entrante elimina la mayor parte de eso: el proveedor parsea el MIME, envía cada mensaje una vez como JSON limpio y tú reaccionas casi en tiempo real. Para una comparación de los protocolos subyacentes, consulta SMTP vs. IMAP.
Preguntas frecuentes
¿Qué cambios de DNS necesito?
Configuras los registros MX del dominio o subdominio en el que quieres recibir correo para que apunten a tu proveedor de inbound. Tras la propagación, el correo a cualquier dirección de ese dominio fluye hacia el proveedor, que lo parsea y lo envía a tu endpoint. Usar un subdominio dedicado mantiene el enrutamiento entrante separado del correo de tu dominio principal.
¿Cómo se gestionan los adjuntos?
El payload parseado incluye los adjuntos, normalmente codificados en base64 en línea o como URLs que descargas por separado. Tu handler los decodifica o descarga y los almacena donde guardes tus archivos. Los adjuntos más grandes suelen referenciarse por URL para mantener el payload pequeño.
¿Es lo mismo el correo entrante que un webhook?
La entrega usa un webhook: el proveedor envía a tu aplicación un POST HTTP por cada mensaje. La diferencia es que el payload es un correo completamente parseado en lugar de un evento genérico. Trátalo como cualquier webhook: verifícalo, responde rápido y procesa de forma asíncrona.
Para ver cómo Bird gestiona ambas direcciones del correo, comienza con la descripción general del producto de email y la guía de eventos de email, que cubre el modelo de entrega de eventos sobre el que construirás tu handler de correo entrante.