ObjectOSConfigurez les fournisseurs et les modèles de livraison d'e-mails transactionnels.
ObjectOS envoie des e-mails transactionnels via le plugin email du framework lorsque l'application le requiert (réinitialisation de mot de passe, invitations, notifications d'approbation, rapports planifiés). Le plugin est fourni avec trois transports.
Transports
| Fournisseur | À utiliser quand | Variables d'env requises |
|---|---|---|
log | Développement local ; consigne l'e-mail dans stdout au lieu de l'envoyer | aucune |
resend | Délivrabilité SaaS via Resend | OS_EMAIL_API_KEY |
postmark | Délivrabilité SaaS via Postmark | OS_EMAIL_API_KEY |
La valeur par défaut est log. ObjectOS bascule vers le transport log
lorsqu'un véritable fournisseur est configuré mais qu'aucune clé API
n'est fournie — utile pour empêcher les environnements non productifs
d'envoyer accidentellement des e-mails.
Qu'en est-il de SMTP ?
Le transport SMTP natif n'est pas intégré au runtime aujourd'hui. Si votre environnement requiert SMTP (relais d'entreprise, messagerie on-prem, déploiement isolé du réseau), vous disposez de deux options de qualité production :
- Exécutez un relais SMTP-vers-API devant ObjectOS. Resend, Postmark et les alternatives auto-hébergées (Postal, Cuttlefish) acceptent tous l'entrée SMTP et la réémettent via leur API HTTP — ObjectOS communique avec eux en HTTPS comme d'habitude.
- Exécutez le runtime avec un plugin email personnalisé. L'API du
plugin email est réduite (une seule fonction
send(message)) ; un plugin de projet qui encapsulenodemailers'intègre via la listerequires. Consultez le guide de création de plugins dans le dépôt spec.
Le transport SMTP natif figure sur la feuille de route ; suivez l'avancement sur github.com/objectstack-ai/objectos/issues.
Variables d'environnement
| Variable | Rôle |
|---|---|
OS_EMAIL_PROVIDER | log, resend ou postmark |
OS_EMAIL_API_KEY | Clé API du fournisseur (Resend ou Postmark) |
OS_EMAIL_FROM | Adresse d'expéditeur par défaut. Prend en charge les formats addr@x et Name <addr@x> |
OS_EMAIL_RETRIES | Nombre de tentatives de réessai du transport en cas d'échec d'envoi (par défaut 0) |
Les variables d'environnement remplacent les valeurs correspondantes du
bloc de configuration email de l'artefact, ce qui permet aux opérateurs
de rediriger la livraison sans reconstruire l'artefact.
Modèles
Les modèles réutilisables résident dans sys_email_template. Les modèles
prennent en charge l'interpolation de variables évaluée par le moteur de
modèles du framework. Le code de l'application (ou un flow) appelle le
service email avec un identifiant de modèle et un ensemble de variables ;
le service matérialise le sujet/corps et le transmet au transport
configuré.
Vérifier la livraison
Pour Resend / Postmark, vérifiez que le domaine d'envoi est configuré dans le tableau de bord du fournisseur (SPF, DKIM, et éventuellement DMARC). La vérification de bout en bout la plus rapide est l'action Send test email de la Console sur la page des paramètres email — elle utilise le transport en direct et fait remonter les erreurs de transport de manière intégrée.
Conseils opérationnels
- Traitez la clé API comme un secret. Stockez-la dans le gestionnaire de secrets du client, jamais dans l'artefact.
- Surveillez les journaux d'erreurs de transport : les limites de débit des fournisseurs, les suppressions et les rebonds y apparaissent tous.
- Les e-mails transactionnels sensibles aux audits (réinitialisation de mot de passe, défi MFA) doivent être conservés conformément à la politique du client — définissez la rétention sur le journal d'audit, pas sur le transport.
- Les e-mails sortants ne bloquent pas les transactions métier : les échecs d'envoi sont signalés comme des erreurs mais n'annulent pas la modification de l'enregistrement à l'origine.