# Supabase + Brew

Déclenchez des automatisations Brew à partir des webhooks de base de données sur la table auth.users de Supabase, y compris des événements dérivés pour la confirmation de l’e-mail, le changement de mot de passe, le passage d’un compte anonyme à un compte réel, et le bannissement ou sa levée.

URL canonique : https://brew.new/fr/browse/integrations/supabase

- Sens des données : Données entrantes
- Connexion : Secret de webhook
- Déclencheurs d’authentification

## Fonctionnalités disponibles

- **Déclencheurs par événement** : Déclenchez des automatisations Brew à partir des webhooks de base de données sur la table auth.users de Supabase, y compris des événements dérivés pour la confirmation de l’e-mail, le changement de mot de passe et la connexion.

## Transformez vos événements d’authentification en e-mails utiles

Connectez Supabase pour lancer des e-mails à l’image de votre marque quand quelqu’un s’inscrit, confirme son adresse e-mail, change de mot de passe ou est banni. Un script de configuration ajoute un trigger de base de données à votre table auth.users, et Brew transforme chaque changement en l’un de ses 12 déclencheurs d’automatisation.

Supabase Auth reste responsable de la connexion, des liens de confirmation, des liens magiques et des réinitialisations de mot de passe. Brew crée et envoie les e-mails qui font suite à ces changements.


## Ce que vous pouvez créer

- E-mails de bienvenue : partez de l’événement auth.user.email_confirmed, pour que le premier e-mail n’atteigne que des adresses vérifiées. Brew ne déduit cet événement que d’une mise à jour qui renseigne email_confirmed_at : un utilisateur dont la ligne est créée déjà confirmée ne produit donc que l’événement auth.user.created. Vérifiez le cas qui s’applique à votre projet, puis choisissez un seul déclencheur pour éviter les e-mails de bienvenue en double.
- Bienvenue aux utilisateurs anonymes qui créent un compte : l’événement auth.user.upgraded_from_anonymous est émis quand is_anonymous passe de true à false, c’est-à-dire quand un utilisateur anonyme devient un compte permanent.
- Avis de changement de mot de passe : l’événement auth.user.password_changed est émis à chaque modification de la colonne encrypted_password. Le payload ne contient aucune donnée de mot de passe. Ajoutez un lien vers votre propre page de récupération de compte, au cas où l’utilisateur ne serait pas à l’origine du changement.
- Avis de changement d’adresse e-mail : l’événement auth.user.email_changed contient l’ancienne adresse dans previousValue et la nouvelle dans newValue. Brew envoie l’e-mail à la nouvelle adresse.
- Relances d’invitation : l’événement auth.user.invited est émis quand une mise à jour renseigne invited_at. Supabase Auth envoie lui-même le lien d’invitation ; un e-mail Brew peut apporter en complément des informations de prise en main. Envoyez une vraie invitation de test depuis votre projet avant de vous fier à ce déclencheur.
- Avis de suspension : l’événement auth.user.banned est émis quand banned_until est renseigné, et il contient sa valeur dans newValue. L’événement auth.user.unbanned est émis quand banned_until est effacé.
- Confirmations de suppression : l’événement auth.user.deleted est émis quand la ligne est supprimée, et il inclut toujours l’adresse e-mail de cette ligne.

## Les événements de connexion ne signalent pas un retour

L’événement auth.user.signed_in est émis quand last_sign_in_at change. Les renouvellements de jeton de Supabase modifient aussi cette colonne : l’événement peut donc être émis à plusieurs reprises tant qu’un utilisateur reste connecté. Il ne prouve pas que quelqu’un est revenu après une longue absence.

C’est aussi l’événement dérivé le moins prioritaire. Quand une même mise à jour confirme une adresse e-mail ou convertit un utilisateur anonyme en compte permanent, Brew émet cet événement plutôt que auth.user.signed_in.

Pour prendre des nouvelles des utilisateurs inactifs, déterminez l’inactivité dans votre application, à partir de ses propres données d’activité. Ne déclenchez un événement personnalisé Brew distinct que pour les utilisateurs concernés, et laissez une automatisation active envoyer l’e-mail de prise de nouvelles à partir de cet événement.

Testez les deux chemins : un utilisateur inactif reçoit l’e-mail de prise de nouvelles ; un utilisateur qui était actif avant la vérification ne le reçoit pas.


## Configurer Supabase dans Brew

- Ouvrez Intégrations, choisissez Supabase, puis cliquez sur « Générer l’URL de webhook ». Brew préremplit le SQL de configuration avec cette URL.
- Créez un secret de signature avec openssl rand -hex 32. Ni Brew ni Supabase ne le fournissent, et Brew exige au moins 16 caractères.
- Dans Supabase, ouvrez SQL Editor et collez le SQL de configuration. Remplacez l’espace réservé du secret par votre secret, puis exécutez le SQL. Il active pgcrypto et pg_net, stocke le secret dans Supabase Vault et ajoute à auth.users un trigger pour les insertions, les mises à jour et les suppressions.
- Collez le même secret dans Brew, puis cliquez sur « Connecter ». La connexion crée un déclencheur pour chacun des 12 événements. Il n’existe pas d’interrupteur pour activer ou désactiver un événement.
- Une fois l’intégration connectée, créez un utilisateur de test dans Supabase, sous Authentication > Users. Dans Brew, le statut passe de « En attente d’un événement de test » à « Connecté », et le panneau « Événements récents » affiche l’envoi avec la mention « signature valide ».
- Créez une automatisation, sélectionnez son événement Supabase et envoyez un test tant qu’elle est encore en brouillon. Seules les automatisations actives s’exécutent quand un événement correspondant arrive.
- Vous devez avoir l’autorisation d’exécuter du SQL sur le schéma auth, d’installer des extensions et d’écrire dans Supabase Vault. Vous pouvez réexécuter le SQL sans risque après avoir renouvelé le secret.

## Événements Supabase pris en charge

Les événements auth.user.created, auth.user.updated et auth.user.deleted proviennent des insertions, mises à jour et suppressions dans auth.users. Brew déduit les autres événements d’une mise à jour, en comparant l’ancienne et la nouvelle ligne.

Une mise à jour produit un seul événement. Quand plusieurs colonnes changent en même temps, la première correspondance l’emporte, dans cet ordre : email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Une mise à jour qui ne correspond à aucun de ces cas arrive sous la forme d’un événement auth.user.updated.

Brew prend en charge les 12 types d’événements suivants :

- auth.user.created
- auth.user.updated
- auth.user.deleted
- auth.user.email_confirmed
- auth.user.phone_confirmed
- auth.user.email_changed
- auth.user.password_changed
- auth.user.signed_in
- auth.user.banned
- auth.user.unbanned
- auth.user.invited
- auth.user.upgraded_from_anonymous

## Synchronisation des contacts et personnalisation

Chaque événement vérifié qui contient une adresse e-mail réelle crée ou met à jour un contact Brew, identifié par son adresse e-mail, qu’une automatisation utilise l’événement ou non. Lorsque les données sont présentes, Brew renseigne le prénom, le nom, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url et supabase_provider.

Certains événements renseignent aussi des champs de cycle de vie. Le champ supabase_account_status prend la valeur active, invited, banned ou deleted. Les champs supabase_email_verified_at, supabase_phone_verified_at et supabase_last_sign_in_at proviennent des événements de confirmation et de connexion correspondants.

Pour les balises de fusion, utilisez le schéma de payload déclaré par l’événement sélectionné. Tous les événements incluent email et, lorsqu’ils sont présents, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt et emailConfirmedAt. Les noms et les avatars proviennent de raw_user_meta_data, avec des solutions de repli pour les inscriptions via OAuth. Les trois horodatages sont exprimés en secondes Unix.

Les événements dérivés ajoutent previousValue, newValue ou les deux, qui contiennent l’ancienne et la nouvelle valeur de la colonne sous forme de texte. L’événement auth.user.password_changed n’en contient aucun. Le champ provider contient la méthode d’inscription, comme email, google ou github : vous pouvez ainsi orienter vos séquences de bienvenue selon la façon dont la personne s’est inscrite.

L’ID utilisateur Supabase n’est pas une balise de fusion. Brew le stocke sur le contact dans supabase_user_id, pour le filtrage et la segmentation.

Un compte Supabase ne vaut pas consentement aux e-mails marketing. Enregistrez le consentement lors de l’inscription et vérifiez-le avant tout envoi promotionnel.


## Brew remplace-t-il les e-mails d’authentification de Supabase ?

Non. Supabase Auth envoie toujours les liens de confirmation, les liens magiques, les invitations et les réinitialisations de mot de passe via sa propre configuration e-mail, par exemple un SMTP personnalisé. Brew lance des automatisations une fois que ces changements ont atteint auth.users. Supabase recommande des domaines d’envoi distincts pour les e-mails d’authentification et les e-mails marketing.


## Pourquoi un événement apparaît-il sans qu’aucun e-mail ne soit envoyé ?

Recevoir un événement et envoyer un e-mail sont deux étapes distinctes. Vérifiez qu’une automatisation correspondante est active, puis contrôlez ses filtres, son historique d’exécution, l’éligibilité du destinataire et le domaine d’envoi. Un événement concernant un utilisateur sans adresse e-mail, comme un utilisateur anonyme qui n’en a pas encore ajouté, ne crée aucun contact et ne lance aucune automatisation.


## Limites et dépannage

- Brew ne lit que la table auth.users. Pour les événements provenant d’autres tables, créez un déclencheur personnalisé dans Brew et déclenchez-le via l’API Brew, depuis votre application ou une Edge Function Supabase.
- Brew ne peut ni créer, ni bannir, ni supprimer d’utilisateurs Supabase, et il n’envoie pas les e-mails de Supabase Auth.
- Si les envois échouent à la vérification de signature, le secret stocké dans Supabase Vault ne correspond pas à celui de Brew. Générez un nouveau secret, réexécutez le SQL de configuration avec celui-ci, puis reconnectez Supabase dans Brew avec la même valeur.
- Si aucun envoi n’arrive, réexécutez le SQL de configuration, puis vérifiez que pgcrypto est installé et que le secret du Vault correspond à celui de Brew.
- Après un événement auth.user.email_changed, Brew crée ou met à jour le contact associé à la nouvelle adresse. Le contact associé à l’ancienne adresse reste inchangé.
- L’événement auth.user.deleted donne à supabase_account_status la valeur deleted. Il ne supprime pas le contact de Brew.
- Vérifiez le consentement et la finalité de chaque e-mail. Synchroniser vos utilisateurs Supabase n’autorise pas les envois promotionnels.

## Sources et guides de configuration

- [Comparer les outils d’e-mail pour Supabase](/fr/blog/best-email-tools-for-supabase-auth-emails-product-events-and-lifecycle-campaigns)
- [Guide de configuration de Supabase](https://docs.brew.new/integrations/import/supabase)
- [Créer une automatisation](https://docs.brew.new/create-emails/build-an-automation)
- [Balises de fusion](https://docs.brew.new/create-emails/merge-tags)
- [Ce que vous pouvez envoyer avec Brew](https://docs.brew.new/get-started/what-you-can-send)
- [Webhooks de base de données Supabase](https://supabase.com/docs/guides/database/webhooks)
- [Champs des utilisateurs Supabase](https://supabase.com/docs/guides/auth/users)
- [SMTP personnalisé de Supabase](https://supabase.com/docs/guides/auth/auth-smtp)

## Voir aussi

- [Toutes les intégrations](https://brew.new/fr/browse/integrations.md)
- [Inscription](https://brew.new/fr/sign-up.md)
- Site web : https://brew.new