# 7. Install email templates

> Install hosted Supabase Auth templates that match the configured OTP, link, recovery, invitation, and security flows.

# Install email templates

Hosted and local templates are configured separately. Edit hosted templates under **Supabase → Authentication → Email Templates**. Files under `supabase/templates/` affect only the local CLI stack.

Use the reusable [Supabase email-template examples](../../Marketing-and-Analytics/email-templates/free-supabase-email-templates.md) as a safe starting point, then apply the product's branding and support details.

## Match signup verification

The confirm-signup template must match `SIGN_UP_EMAIL_VERIFICATION`:

- `otp`: show `{{ .Token }}` and instruct the user to enter the configured-length code in the application.
- `link`: construct a token-hash link using `{{ .RedirectTo }}` and send it through `/auth/confirm`.
- `otp-and-link`: include both alternatives and explain that using either one consumes the verification.
- `disabled`: Supabase does not send a signup-confirmation message.

Passwordless login is different and always exclusive. Its hosted **Magic Link or OTP** template must contain only `{{ .Token }}` in `otp` mode or only the login link in `link` mode. Never include both for passwordless login.

## Install the authentication templates

Review every flow enabled by the application:

| Template | Required content |
| --- | --- |
| Confirm signup | OTP or token-hash link matching the chosen verification mode |
| Magic link | A sign-in link using the Supabase confirmation URL or the application's documented callback construction |
| Reset password | A recovery link that returns to `/auth/callback?flow=recovery`; Core verifies the recovery session before `/account/reset-password/new` |
| Invite user | Invitation purpose, expiry wording, and acceptance link |
| Change email address | Old/new-address context appropriate to secure email change |
| Reauthentication | The `{{ .Token }}` and the action it authorizes |

Use `{{ .RedirectTo }}` when the application supplies a per-request redirect. `{{ .SiteURL }}` is the project's fixed fallback and can silently return a user to the wrong route when substituted for `RedirectTo`.

## Enable security notifications

Where supported by the product, enable and brand the notifications for:

- password changed;
- email address changed;
- phone number changed;
- sign-in method linked or removed; and
- verification method added or removed.

Security messages should state what changed, when practical, and what the user should do if they did not perform the action. Do not place secrets, raw tokens, or sensitive user metadata in a notification.

## Template safety

- Keep the subject specific and recognizable.
- Include a plain explanation of why the message was sent.
- Use the configured product and support names consistently.
- Do not claim a hard-coded expiry that differs from Email OTP Expiration.
- Avoid externally hosted tracking pixels in security-sensitive messages.
- Disable provider click tracking that rewrites one-time links.
- Use `user_metadata` only for harmless presentation; never treat it as authorization data.
- Test both mobile and desktop rendering with real mail clients.

## Completion check

- The signup template matches `SIGN_UP_EMAIL_VERIFICATION`.
- The passwordless template contains only its configured OTP or link method.
- Every enabled Auth flow has a template with correct destinations.
- Expiry copy agrees with the hosted Email OTP Expiration setting.
- Security notifications are enabled and branded where appropriate.
- A real external mailbox renders each important template correctly.

Next: [Verify production](./08-production-verification.md).