Allow {{ .Token }} (OTP) in the password reset template on free tier for mobile apps

[adamsmaka]

Problem

Since the change on 3 June 2026, free-tier projects using the default email provider can no longer edit their auth email templates. The password reset template is locked to {{ .ConfirmationURL }} (a link), and there's no way to switch it to {{ .Token }} (the 6-digit OTP) without setting up a custom SMTP provider — which in turn requires a verified domain.

Why this matters for mobile

For mobile apps, a confirmation link is a poor UX. The user has to leave their email client, open a link, and rely on deep linking to get back into the app — which is fragile and frequently breaks across email clients and OS versions.

A 6-digit code is far better: the user just reads it and types it into the app. It's faster, more reliable, and it's the pattern users already expect from mobile authentication. The locked link-only default is essentially a web-first flow that doesn't serve mobile developers well.

Request

Would you consider allowing the {{ .Token }} variable in the password reset template on the free tier, even with editing otherwise locked? I'm not asking to reopen full template customization — just this one variable for this one flow.

Possible ways to do this without reopening free-text editing:

• A toggle on the password reset template to switch between link and token, with no free-text editing.
• A second locked default template variant that uses {{ .Token }} instead of {{ .ConfirmationURL }}.
• Allowing token-only password reset templates on the free tier, while keeping arbitrary HTML editing gated behind a paid plan or custom SMTP.

This would keep the anti-abuse protection you're aiming for while unblocking a large, legitimate mobile use case.

Context

I teach an online course on building mobile apps with Supabase as the backend. This change means students now have to set up custom SMTP and a domain just to get a sensible mobile password reset experience, which is a significant hurdle for beginners. Enabling token-based reset on the free tier would make a real difference for mobile developers building on Supabase.

Thanks for considering it 🙏

[Rameshwar-18]

+1 for this this change has real impact on mobile developers.
I've built full-stack apps using Supabase Auth and the link based flow is genuinely painful on mobile. Deep linking is fragile it breaks differently across Android and iOS versions, email clients, and when users have browsers that intercept links. A 6-digit OTP that users just type in is a far smoother experience.
The request here is very reasonable not asking for free text template editing, just a toggle or a second locked template variant that uses {{ .Token }}. That's a minimal change with a big UX improvement for mobile developers.
The custom SMTP + verified domain requirement is a significant barrier, especially for students and indie developers just getting started. Many of them choose Supabase specifically because it lowers the barrier to building this change raises it again for a common use case.
Hope this makes it onto the roadmap soon.

[harrysun2006]

This is a fair request, and the mobile reasoning is sound — a 6-digit code really is the better UX than a deep-linked confirmation URL, which is fragile across email clients and OS versions.

The constraint you've hit is the 3 June 2026 change: on the free tier with the built-in email service, the templates are locked to their defaults, and the password-reset default is the {{ .ConfirmationURL }} link. Today the only way to switch that flow to {{ .Token }} is to set up custom SMTP (Authentication → SMTP Settings), which as you say needs a verified sending domain. So there's a real workaround, just not a free one.

Your framing of the ask is the smart way to pitch it, too — not "reopen free-text template editing", but "allow this one variable for this one flow", e.g. a locked toggle between link and token on the reset template, or a second locked default variant. That's a much smaller surface for the team to consider than reopening full customization, and it keeps the anti-abuse reasoning behind the June change intact.

Worth leaving this as a Feature Request and getting other mobile devs to upvote — the OTP-vs-link toggle for recovery/magic-link on free tier is a common pain point, and a scoped, no-free-text version is the kind of thing that has a real chance of landing.