Pour une application Supabase, Resend convient aux emails transactionnels déclenchés par Auth ou une fonction Edge ; Postmark est une autre option si vous voulez séparer clairement ces messages du marketing. Le choix dépend surtout de la façon dont vos événements PostgreSQL arrivent jusqu’au fournisseur, du volume envoyé et des données que vous synchronisez. Le serveur d’envoi par défaut de Supabase Auth sert au démarrage, mais ses limites ne conviennent pas à une production durable. Configurez un SMTP personnalisé, authentifiez votre domaine et gardez les messages d’authentification distincts des campagnes consenties.
Resend est un choix cohérent pour relier Supabase Auth à un fournisseur transactionnel : une fonction Edge peut appeler son API lors d’une confirmation, d’un lien magique ou d’une réinitialisation, sans confondre ces messages avec une newsletter. Son offre Free comprend 3 000 emails par mois, avec une limite de 100 par jour ; Pro coûte 20 $ par mois pour 50 000 emails. Cette facturation par envoi est à surveiller si votre application déclenche beaucoup d’événements.
Postmark
Postmark convient aux confirmations et changements de mot de passe confiés à une infrastructure distincte. Basic est affiché à 15 $ par mois pour 10 000 emails ; les dépassements sont facturés par tranche, ce qui demande de suivre les pointes d’inscription et les renvois de liens.
SendGrid
SendGrid peut recevoir les demandes de vos fonctions serveur pour les reçus et alertes liés aux lignes Supabase. Vérifiez la formule nécessaire aux volumes transactionnels et la séparation avec les envois marketing : la présence d’une API ne configure ni les déclencheurs PostgreSQL ni le consentement à votre place.
Customer.io
Customer.io peut recevoir les attributs et événements que votre backend choisit d’exposer pour les parcours de cycle de vie. Cartographiez les changements de statut utiles avant la synchronisation ; envoyer toute la table des utilisateurs crée du bruit, des doublons et des risques de divulgation.
Loops
Loops est à examiner pour des séquences produit déclenchées après l’inscription ou l’usage d’une fonctionnalité. Votre application doit toutefois transmettre les événements et l’état d’abonnement de façon fiable ; prévoyez une file de reprise si l’API distante échoue.
Mailgun
Mailgun s’intègre côté serveur pour les messages générés par votre application. Le coût dépend du volume et des options retenues : estimez confirmations, alertes et reprises à partir de vos propres événements, puis contrôlez les limites de la formule choisie.
Brevo
Brevo peut recevoir une liste d’utilisateurs autorisés pour les annonces produit et les lettres d’information. Importez seulement les champs nécessaires et synchronisez le retrait du consentement ; les emails Auth et les alertes opérationnelles doivent rester dans un flux transactionnel séparé.
Votre backend doit pouvoir créer ou mettre à jour un contact, transmettre un événement utile et recevoir une erreur exploitable si le fournisseur refuse l’appel. Examinez les limites de débit, les réponses en cas de doublon et la possibilité de retenter sans envoyer deux fois le même message. Une file d’attente avec identifiant d’idempotence évite qu’une panne brève transforme un changement de ligne en série d’emails répétés.
Confirmation d’adresse, lien magique et réinitialisation de mot de passe sont des messages nécessaires à l’accès au compte. Le serveur d’envoi par défaut est destiné aux essais et comporte des limites de débit et de personnalisation ; ne le traitez pas comme un relais de production. Configurez un SMTP personnalisé dans les paramètres Auth, puis vérifiez que chaque modèle pointe vers la bonne URL de retour et n’expose aucun jeton dans les journaux.
Pour un email de bienvenue après validation, partez d’un événement Auth ; pour une alerte après changement d’abonnement, partez de la table métier concernée. Un webhook de base ou un trigger peut alimenter une fonction Edge, qui vérifie les règles puis appelle l’API du fournisseur. Évitez d’appeler directement un service externe dans une transaction SQL : consignez l’événement et traitez les échecs hors de la transaction.
Un email qui permet de se connecter n’a pas la même finalité qu’une annonce de fonctionnalité. Gardez les messages Auth et reçus dans un flux transactionnel ; envoyez les campagnes et parcours promotionnels depuis un outil marketing distinct. Cette séparation facilite les règles de désinscription et limite l’impact d’une campagne mal ciblée sur les messages attendus. Pour la prospection B2C, gérez le consentement préalable et l’opposition selon le contexte.
Définissez une liste blanche de champs : adresse, langue et éventuellement état d’abonnement suffisent souvent à personnaliser un parcours. Stockez dans votre base la date, la source et la finalité du consentement, ainsi que la date de retrait. La synchronisation doit propager l’opposition vers l’outil d’envoi et empêcher toute réinscription automatique. Ne copiez pas les profils complets, secrets, données sensibles ou événements détaillés dans une plateforme marketing.
Conservez les clés API dans les secrets de l’environnement serveur ou des fonctions Edge, jamais dans le client web ni dans une table lisible par les utilisateurs. Créez une clé dédiée avec les droits nécessaires et prévoyez sa rotation. Authentifiez le domaine d’envoi avec les enregistrements SPF et DKIM demandés, publiez une politique DMARC adaptée et surveillez les rebonds. Une adresse d’expéditeur alignée avec votre domaine aide les destinataires à reconnaître vos messages.
Attendez que l’adresse soit confirmée si votre parcours utilise la confirmation, puis transmettez un événement minimal à une fonction Edge ou à votre serveur. Celui-ci peut créer le contact dans l’outil marketing et démarrer le parcours d’accueil seulement si la personne a accepté ces communications. Gardez le message qui contient le lien de confirmation dans le flux Auth ; un email de bienvenue promotionnel ne doit pas servir de substitut à cette étape.
Oui, si le déclencheur transmet un événement métier choisi plutôt que le contenu complet d’une ligne. Faites appeler une fonction serveur qui vérifie l’état actuel de l’utilisateur, son consentement et l’absence d’un envoi identique avant de demander le message. Enregistrez l’identifiant de l’événement traité : les webhooks peuvent être rejoués après une erreur. Cette précaution évite qu’un même changement de statut déclenche plusieurs relances.
Comparez d’abord le plafond mensuel avec le nombre de confirmations, liens magiques et réinitialisations réellement générés, en tenant compte des renvois. Resend Free inclut 3 000 emails par mois et 100 par jour ; son offre Pro coûte 20 $ par mois pour 50 000. Postmark Basic coûte 15 $ par mois à partir de 10 000 emails mensuels. Dans les deux cas, configurez SMTP côté Supabase et gardez les campagnes marketing dans un circuit séparé.
Dans le tableau de bord du projet, ouvrez les paramètres Authentication puis la section SMTP. Renseignez l’hôte, le port, l’identifiant et le secret fournis par votre service transactionnel, ainsi que l’adresse d’expédition autorisée. Utilisez un secret distinct réservé à cette fonction et appliquez les modèles de confirmation, lien magique et réinitialisation. Vérifiez aussi l’URL de redirection autorisée : une configuration SMTP correcte ne rend pas sûr un lien de retour ouvert.
Commencez par définir les personnes que vous pouvez légalement contacter : un compte créé ne signifie pas forcément un accord marketing. Exportez uniquement les adresses éligibles et les champs indispensables, puis importez-les avec leur statut de consentement sans les transformer en abonnés par défaut. Pour la suite, propagez les changements par événements serveur et traitez aussi les désinscriptions dans le sens inverse. Comparez périodiquement les deux systèmes pour repérer les suppressions et les erreurs de synchronisation.
Choisissez un événement qui indique une étape utile, par exemple la création du premier projet, et définissez ce que le message doit aider à accomplir ensuite. Une fonction serveur peut transmettre cet événement au parcours concerné, puis arrêter les conseils quand l’utilisateur a terminé l’action. Évitez de collecter des clics détaillés sans nécessité ; une propriété d’état suffit souvent. Prévoyez également un moyen de corriger un événement erroné avant qu’il ne déclenche une relance.
Distinguez la personne destinataire de l’organisation à laquelle elle appartient. Une annonce de facturation peut viser un administrateur, tandis qu’un conseil d’utilisation peut concerner chaque membre ; ne déduisez pas la cible du seul identifiant d’organisation. Synchronisez un identifiant non sensible et le rôle utile, puis vérifiez les règles d’accès avant tout envoi. Les changements d’équipe et suppressions de membres doivent retirer ou actualiser leurs attributs dans l’outil externe.
Non. Une clé d’envoi intégrée au JavaScript livré au navigateur peut être extraite et utilisée par des tiers. Placez-la dans les secrets du projet ou dans l’environnement de la fonction Edge, puis faites transiter la demande par le serveur après contrôle de l’utilisateur et du type de message. Séparez les clés de développement et de production, limitez leurs permissions si le fournisseur le permet et révoquez immédiatement une clé exposée.
Utilisez un sous-domaine dédié aux emails de l’application afin de distinguer sa réputation de celle du domaine principal. Publiez les enregistrements SPF et DKIM demandés par le fournisseur et choisissez une politique DMARC cohérente avec vos autres services d’envoi. Commencez avec des messages attendus et des adresses valides ; surveillez les rebonds et plaintes avant d’élargir le volume. L’authentification DNS ne compense pas une liste marketing sans consentement.
Gardez-la dans votre base, à côté du profil concerné, avec la finalité acceptée, la date et le contexte de collecte ainsi que la version du formulaire lorsque c’est utile. Un simple champ booléen ne permet pas toujours de comprendre quand ni pourquoi la personne s’est inscrite. La désinscription doit mettre à jour ce statut et être propagée au fournisseur d’emailing. Faites valider les durées de conservation et les preuves attendues par votre DPO ou conseil.