Setting Up Supabase Auth Emails

Supabase calls PostHog’s Send Email Hook for each auth email. The user does the Supabase steps by hand, so tell them exactly what to click, and keep the order below.

If the Supabase MCP server is connected, use it to read the project URL (step 4) and the logs (when a hook call fails). It has no tools for Auth settings. Leave the hook and the rate limit to the user even if you have other Supabase access, because those settings send every sign-up email.

The tools are behind a beta flag. If supabase-auth-emails-settings-get isn’t available, tell the user the feature isn’t enabled for their project yet and stop.

The setup

1. Read the current state. Call supabase-auth-emails-settings-get. Keep the hook_url, the email_types list and the current templates mapping. If the project is already set up, change only what the user asked for.
2. Ask the user’s choices in one go. Ask these together, before any change. Use the client’s multiple-choice question tool if it has one. Skip any question the state from step 1 already answers.
   • Project: with no Supabase MCP, ask for the Supabase dashboard link of the project (supabase.com/dashboard/project/<project-ref>).
   • Templates: create PostHog’s starter templates, or use templates they already have.
   • Hook secret: paste it into the chat, or enter it in PostHog themselves.
3. Check the email sender. The templates need an email channel with a verified sending domain. Follow the setup check in the building-workflows skill’s onboarding reference.
4. Save the project URL. With the Supabase MCP, call get_project_url. Otherwise it is https://<project-ref>.supabase.co. For a self-hosted project or a custom domain, ask the user for the URL their app uses to reach Supabase Auth. Save it with supabase-auth-emails-settings-update.
5. Have the user create the hook in Supabase, switched off. While the hook is on, any hook failure fails the user’s sign-up or password reset. Give them the hook_url and these steps:
   • Open Authentication > Hooks, add a Send Email hook, and choose HTTPS.
   • Paste the hook URL as the endpoint.
   • Click Generate secret and copy the whole value.
   • Leave Enable Send Email hook off, and save.
6. Save the hook secret. Never invent a hook secret. If a secret is already stored, leave hook_secret out to keep it, and ask before you replace it. Never send it blank, because a blank value clears it.
   • In the chat: save it with supabase-auth-emails-settings-update. Don’t repeat it back in your reply.
   • In PostHog: give the user a link to /workflows/channels?setup=supabase in their PostHog app. It opens the Supabase setup. They paste the secret and click Save connection. Then call supabase-auth-emails-settings-get and confirm has_hook_secret is true.
7. Map the templates, as the user chose in step 2:
   • Starter templates. Call supabase-auth-emails-starter-templates-create. It creates and maps a template for each email type with has_starter_template that has no usable one yet. If it fails for want of a verified sender, go back to step 3. To change a template’s copy or styling, use the designing-email-templates skill.
   • Existing templates. List them with workflows-list-email-templates, keep the ones that are transactional and marked sensitive, and ask the user which one sends each email. A template that is neither can’t be mapped yet. Ask before you make one transactional, because that can’t be undone. Send the mapping with supabase-auth-emails-settings-update. Build templates from the step 1 mapping with your changes merged in, because the field replaces the whole mapping. Ask before you unmap a template that already sends.
8. Check before the hook goes live. In the response of your last call, confirm supabase_url is set, has_hook_secret is true, and every core email type in the email_types list from step 1 has a template. The write responses leave that list out. Core types are the ones that don’t end in _notification. A core type with no template fails the user’s action. A notification with no template is skipped.
9. Have the user turn the hook on. In Supabase, edit the Send Email hook, switch on Enable Send Email hook, and save. PostHog can’t see whether the hook is on, so the Connected status on the Supabase card only means the connection is saved.
10. Have the user raise Supabase’s email rate limit. Supabase checks its own hourly email limit before it calls PostHog. The built-in mailer allows 2 per hour. Once the hook sends the emails, the user can raise the limit under Authentication > Rate Limits. Ask them to check the value there.
11. Test it. Ask the user to invite a user (Authentication > Users > Add user > Send invitation) or request a password reset, to an address they can read. The email should arrive from the mapped template.

Report done only after the user confirms a test email arrived. Name any email type you left without a template.

To disconnect, the user turns the hook off in Supabase first, then clicks Disconnect in the PostHog setup window. In the other order, every auth email fails in between.

When a hook call fails

The user sees these in Supabase, in the app’s error or under Logs > Auth. With the Supabase MCP, find the failed call yourself with its query_logs tool before you ask the user. That tool reads Supabase’s logs. PostHog’s query-logs tool can’t see them.