El correo que envía tu producto
de la llamada al resultado
Tu app publica un mensaje y OpenEmail lo envía desde tu propio dominio. Cada llamada queda junto a la clave que la hizo, y cada envío tiene un resultado que leer.
La llamada responde con un id de mensaje. Cada evento que recibe tu endpoint lleva ese mismo id.
De dónde parte
Cómo es esto hoy.
El correo sale de tu código
Recibos, códigos de registro y restablecimientos los manda tu backend, no los escribe una persona.
Tras el envío no vuelve nada
Un cliente dice que el código nunca llegó, y no hay registro de entrega con el que comprobarlo.
Una clave común, sin registro
Todos los servicios envían con el mismo secreto, y nada muestra qué llamada falló ni cuándo.
Cómo funciona
En marcha en cuatro pasos.
- 01
Verifica tu dominio
Publica los registros que aparecen en ajustes, y el dominio se pone en verde cuando encajan.
- 02
Crea una clave acotada
Limita la clave a las direcciones y dominios desde los que puede enviar, y acota con un rol lo que alcanza.
- 03
Envía el mensaje
Una llamada nombra la plantilla, sus valores y el destinatario, y un reintento no puede enviarlo dos veces.
- 04
Recibe el webhook, lee el registro
Tu endpoint recibe cada evento con el id del mensaje, y el registro muestra entregado, rebotado o fallido.
En qué se apoya
Las piezas que hacen el trabajo.
Se apoya en una API documentada con claves que se acotan, un SDK tipado, webhooks a tu endpoint, plantillas con versiones y los registros que respaldan tu dominio de envío.
Una API HTTP documentada con claves que se emiten, se acotan y se revocan.
Primero un cliente de TypeScript, después el resto.
Avisa a tu endpoint cuando llega el correo, en vez de obligarte a consultar.
Un cuerpo escrito una vez, versionado y enviado muchas veces: desde el redactor, desde tu propio código o por un agente.
Una marca junto al remitente cuando los registros publicados del dominio remitente coinciden.
Un registro inicial p=none, impreso para copiar o escrito por una sincronización, que nunca se endurece por ti.
v=DMARC1; p=none; rua=…
En la práctica
Cada pieza, paso a paso.
Cuatro páginas más breves recorren el camino: enviar desde tu código, leer el registro de llamadas, qué pasó tras el envío y el correo dentro de una prueba, que aún está por llegar.
Envía recibos, códigos y enlaces de restablecimiento desde tu código, y entérate de cuándo llegan.
Cada llamada de una clave y cada webhook enviado, con el código y el tiempo.
Da a cada ejecución de prueba su propia dirección y lee el correo que recibe.
Preguntas
Las de antes de registrarse.
¿Qué impide que un reintento envíe el correo dos veces?
Una llamada nombra la plantilla, sus valores y el destinatario, y su reintento no puede enviar dos veces. La llamada responde con un id de mensaje, y cada evento que recibe tu endpoint lleva ese mismo id.
¿Puedo ver qué pasó después del envío?
Sí. Cada envío se lee como entregado, rebotado, queja o fallo, por día, origen y dirección de envío, y el registro de peticiones guarda el método, la ruta, el código de estado y la duración de cada llamada de una clave.
¿Hay un SDK para mi lenguaje?
Todavía no, en la mayoría de los casos. El cliente tipado es primero TypeScript y los demás vienen después, así que por ahora los otros lenguajes llaman directamente a la API HTTP documentada.
Cerca
Otras tareas para el mismo buzón.
Cada ticket, registro o cliente puede tener su propia dirección. El correo que va ahí llega a tu endpoint como un evento firmado, y tu código responde como esa dirección.
Da a un agente su propia dirección y una clave acotada a lo que puede hacer. Lee, etiqueta, redacta y envía, y cada llamada que hace queda registrada.
Escríbelo una vez como plantilla. Envíalo desde el editor, desde tu código o el día que elijas, y luego lee qué pasó después.
