Connect Supabase to start branded emails when someone signs up, confirms their email, changes their password, or is banned. A setup script adds a trigger to your auth.users table, and Brew turns each change into one of 12 automation triggers.
Supabase Auth remains responsible for sign-in, confirmation links, magic links, and password resets. Brew creates and sends the emails that follow those changes.
auth.user.signed_in fires when last_sign_in_at changes. Supabase token refreshes also change that column, so the event can fire repeatedly while a user stays signed in. It does not show that someone came back after a long absence.
It is also the lowest-priority derived event. When the same update confirms an email or upgrades an anonymous user, Brew emits that event instead of auth.user.signed_in.
For a check-in with inactive users, decide inactivity in your application from its own activity data. Fire a separate Brew custom event only for users who qualify, and let a Live automation send the check-in from that event.
Test both paths: an inactive user receives the check-in; a user who was active before the check does not.
auth.user.created, auth.user.updated, and auth.user.deleted come from inserts, updates, and deletes on auth.users. Brew derives the other events from an update by comparing the old and new row.
One update produces one event. When several columns change together, the first match wins in this order: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. An update that matches none of these arrives as auth.user.updated.
Brew supports these 12 event types:
Each verified event with a real email address creates or updates a Brew contact, matched by email, whether or not an automation uses the event. When the data is present, Brew sets first and last name, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url, and supabase_provider.
Some events also set lifecycle fields. supabase_account_status becomes active, invited, banned, or deleted. supabase_email_verified_at, supabase_phone_verified_at, and supabase_last_sign_in_at come from the matching confirmation and sign-in events.
Use the selected event's declared payload schema for merge tags. Every event includes email and, when present, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt, and emailConfirmedAt. Names and avatars come from raw_user_meta_data, with fallbacks for OAuth sign-ups. The three timestamps are Unix seconds.
Derived events add previousValue, newValue, or both, holding the old and new column value as text. auth.user.password_changed has neither. provider holds the sign-up method, such as email, google, or github, so you can route welcome flows by how someone signed up.
The Supabase user ID is not a merge tag. Brew stores it on the contact as supabase_user_id for filtering and segmentation.
A Supabase account does not establish consent for marketing email. Record consent at sign-up and check it before promotional sends.
No. Supabase Auth still sends confirmation links, magic links, invitations, and password resets through its own email setup, such as custom SMTP. Brew starts automations after those changes reach auth.users. Supabase recommends separate sending domains for auth and marketing email.
Receiving an event and sending an email are separate steps. Confirm a matching automation is Live, then check its filters, execution history, recipient eligibility, and sending domain. An event for a user with no email address, such as an anonymous user who has not added one, creates no contact and starts no automation.
