Configura proveedores de entrega de correo transaccional y plantillas.
ObjectOS envía correo transaccional a través del plugin de email del framework cuando la aplicación lo requiere (restablecimiento de contraseña, invitaciones, notificaciones de aprobación, informes programados). El plugin incluye tres transportes.
Transportes
| Proveedor | Cuándo usarlo | Variables de entorno requeridas |
|---|---|---|
log | Desarrollo local; registra el correo en stdout en lugar de enviarlo | ninguna |
resend | Capacidad de entrega SaaS mediante Resend | OS_EMAIL_API_KEY |
postmark | Capacidad de entrega SaaS mediante Postmark | OS_EMAIL_API_KEY |
El valor por defecto es log. ObjectOS recurre al transporte log cuando se
configura un proveedor real pero no se suministra una clave de API — útil para
evitar que los entornos no productivos envíen correo de forma accidental.
¿Qué pasa con SMTP?
El transporte SMTP nativo no está integrado en el runtime actualmente. Si tu entorno requiere SMTP (relay corporativo, correo on-premise, despliegue aislado) tienes dos opciones de nivel producción:
- Ejecuta un relay de SMTP a API delante de ObjectOS. Resend, Postmark y las alternativas autoalojadas (Postal, Cuttlefish) aceptan ingreso por SMTP y reenvían a través de su API HTTP — ObjectOS se comunica con ellas sobre HTTPS de forma normal.
- Ejecuta el runtime con un plugin de email personalizado. La API del
plugin de email es pequeña (una sola función
send(message)); un plugin del proyecto que envuelvanodemailerse conecta a través de la listarequires. Consulta la guía de creación de plugins en el repositorio de la especificación.
El transporte SMTP nativo está en la hoja de ruta; sigue el progreso en github.com/objectstack-ai/objectos/issues.
Variables de entorno
| Variable | Propósito |
|---|---|
OS_EMAIL_PROVIDER | log, resend o postmark |
OS_EMAIL_API_KEY | Clave de API del proveedor (Resend o Postmark) |
OS_EMAIL_FROM | Dirección de remitente por defecto. Admite los formatos addr@x y Name <addr@x> |
OS_EMAIL_RETRIES | Número de reintentos del transporte ante un fallo de envío (por defecto 0) |
Las variables de entorno anulan los valores correspondientes del bloque de
configuración email del artefacto, de modo que los operadores pueden
redirigir la entrega sin reconstruir el artefacto.
Plantillas
Las plantillas reutilizables residen en sys_email_template. Las plantillas
admiten interpolación de variables evaluada por el motor de plantillas del
framework. El código de la aplicación (o un flujo) invoca el servicio de email
con un id de plantilla y un conjunto de variables; el servicio materializa el
asunto/cuerpo y lo entrega al transporte configurado.
Verificación de la entrega
Para Resend / Postmark, verifica que el dominio de envío esté configurado en el panel del proveedor (SPF, DKIM y, opcionalmente, DMARC). La comprobación extremo a extremo más rápida es la acción Send test email de la Console en la página de configuración de email — utiliza el transporte real y muestra los errores de transporte en línea.
Recomendaciones operativas
- Trata la clave de API como un secreto. Almacénala en el gestor de secretos del cliente, nunca en el artefacto.
- Vigila los registros de errores de transporte: los límites de tasa del proveedor, las supresiones y los rebotes aparecen todos ahí.
- El correo transaccional sensible para auditoría (restablecimiento de contraseña, desafío MFA) debe conservarse de acuerdo con la política del cliente — establece la retención en el registro de auditoría, no en el transporte.
- El correo saliente no bloquea las transacciones de negocio: los fallos de envío se muestran como errores pero no revierten el cambio del registro que los originó.