Verbinde Supabase, um markenkonforme E-Mails auszulösen, wenn sich jemand registriert, die E-Mail-Adresse bestätigt, das Passwort ändert oder gesperrt wird. Ein Setup-Skript legt einen Datenbank-Trigger auf deiner Tabelle auth.users an, und Brew macht aus jeder Änderung einen von 12 Triggern für Automatisierungen.
Für Anmeldung, Bestätigungslinks, Magic Links und Passwort-Resets bleibt Supabase Auth zuständig. Brew erstellt und versendet die E-Mails, die auf diese Änderungen folgen.
Das Event auth.user.signed_in wird ausgelöst, wenn sich last_sign_in_at ändert. Auch Token-Aktualisierungen in Supabase ändern diese Spalte, das Event kann also wiederholt ausgelöst werden, während ein Nutzer angemeldet bleibt. Es zeigt nicht, dass jemand nach langer Abwesenheit zurückgekommen ist.
Außerdem ist es das abgeleitete Event mit der niedrigsten Priorität. Bestätigt dasselbe Update eine E-Mail-Adresse oder macht aus einem anonymen Nutzer ein dauerhaftes Konto, erzeugt Brew dieses Event statt auth.user.signed_in.
Für eine Nachfass-E-Mail an inaktive Nutzer entscheidest du in deiner Anwendung anhand ihrer eigenen Aktivitätsdaten, wer als inaktiv gilt. Löse nur für Nutzer, auf die das zutrifft, ein separates eigenes Event in Brew aus, und lass eine Live-Automatisierung auf dieses Event hin die Nachfass-E-Mail versenden.
Teste beide Pfade: Ein inaktiver Nutzer bekommt die Nachfass-E-Mail; ein Nutzer, der vor der Prüfung aktiv war, bekommt sie nicht.
Die Events auth.user.created, auth.user.updated und auth.user.deleted stammen aus Inserts, Updates und Deletes auf auth.users. Die übrigen Events leitet Brew aus einem Update ab, indem die alte mit der neuen Zeile verglichen wird.
Ein Update erzeugt genau ein Event. Ändern sich mehrere Spalten gleichzeitig, gewinnt der erste Treffer in dieser Reihenfolge: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Ein Update, auf das nichts davon zutrifft, kommt als auth.user.updated an.
Brew unterstützt diese 12 Event-Typen:
Jedes verifizierte Event mit einer echten E-Mail-Adresse legt einen Brew-Kontakt an oder aktualisiert ihn – zugeordnet über die E-Mail-Adresse und unabhängig davon, ob eine Automatisierung das Event nutzt. Wenn die Daten vorhanden sind, setzt Brew Vor- und Nachname, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url und supabase_provider.
Manche Events setzen zusätzlich Lifecycle-Felder. Das Feld supabase_account_status wird zu active, invited, banned oder deleted. Die Felder supabase_email_verified_at, supabase_phone_verified_at und supabase_last_sign_in_at stammen aus den passenden Bestätigungs- und Anmelde-Events.
Richte dich bei Merge-Tags nach dem deklarierten Payload-Schema des gewählten Events. Jedes Event enthält email und, sofern vorhanden, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt und emailConfirmedAt. Namen und Avatare stammen aus raw_user_meta_data, mit Fallbacks für Registrierungen per OAuth. Die drei Zeitstempel sind in Unix-Sekunden angegeben.
Abgeleitete Events ergänzen previousValue, newValue oder beides, mit dem alten und dem neuen Wert der Spalte als Text. Das Event auth.user.password_changed hat keines von beiden. Das Feld provider enthält die Registrierungsmethode, etwa email, google oder github, sodass du Willkommens-Flows danach steuern kannst, wie sich jemand registriert hat.
Die Supabase-Nutzer-ID ist kein Merge-Tag. Brew speichert sie als supabase_user_id am Kontakt, zum Filtern und Segmentieren.
Ein Supabase-Konto begründet keine Einwilligung in Marketing-E-Mails. Halte die Einwilligung bei der Registrierung fest und prüfe sie vor Werbeversänden.
Nein. Bestätigungslinks, Magic Links, Einladungen und Passwort-Resets verschickt Supabase Auth weiterhin über sein eigenes E-Mail-Setup, etwa einen eigenen SMTP-Dienst. Brew startet Automatisierungen, nachdem diese Änderungen in auth.users angekommen sind. Supabase empfiehlt getrennte Versanddomains für Auth- und Marketing-E-Mails.
Ein Event zu empfangen und eine E-Mail zu senden, sind getrennte Schritte. Prüfe, ob eine passende Automatisierung live ist, sieh dir dann ihre Filter und ihren Ausführungsverlauf an und prüfe, ob der Empfänger erreichbar und die Versanddomain bereit ist. Ein Event zu einem Nutzer ohne E-Mail-Adresse, etwa zu einem anonymen Nutzer, der noch keine hinterlegt hat, legt keinen Kontakt an und startet keine Automatisierung.
