Email confirmation links failing?

[HighDesertDigitalDesign]

Email confirmation links (/auth/v1/verify with token_hash + type=signup) consistently fail with "Email link is invalid or has expired" (403), on 100% of attempts, including:

A fresh link clicked ~4 minutes after /resend, well within the 86400-second OTP expiry configured on the project
Confirmed via auth.users.confirmation_sent_at that the resend genuinely rotates the token server-side each time
No custom Auth Hooks configured
Client is calling supabase.auth.verifyOtp({ token_hash, type: 'signup' }) directly via supabase-js v2, confirmed pointed at the correct project (qqivaoanrobyxvrvlyka)
Email template correctly uses {{ .TokenHash }} unmodified in the link (no encoding issues — token contains only hex characters, 56 chars, matches expected SHA-224 hash length)
Auth logs show every /verify attempt for this identity returning WARNING/403, with no successful attempt ever recorded — ruling out a race condition or scanner consuming it first

Project ref: qqivaoanrobyxvrvlyka
Affected user: braden@highdesertdigitaldesign.com

[Sweta0519]

Your elimination list is thorough, and the one thing it does not cover is the flow prefix.

In GoTrue, a signup confirmation started under the PKCE flow is stored as pkce_<sha224> rather than the bare hash (addFlowPrefixToToken in internal/api/mail.go, called from sendConfirmation, which /resend also goes through). The email template is given that prefixed value as {{ .TokenHash }}. On verify, verifyTokenHash does an exact match on the stored one-time token, and a miss is exactly your error: ErrorCodeOTPExpired, "Email link is invalid or has expired", 403.

Your token is 56 hex characters, so it is the bare hash. If the row is prefixed, it can never match. Two checks settle it:

1. Right after a resend: select confirmation_token, confirmation_sent_at from auth.users where email = '<the user>'; If it starts with pkce_, this is the cause.
2. Look at the raw email source, not the rendered link. If {{ .TokenHash }} arrives as pkce_... and your app receives 56 hex characters, something between the template and verifyOtp is stripping it, often a URL builder or a hex-only validator.

If it is prefixed, any of these resolves it: pass the full pkce_... value straight through to verifyOtp; create the client with flowType: 'implicit' for signups you intend to confirm via token_hash; or let the emailed link hit /auth/v1/verify and exchange the returned code with exchangeCodeForSession, which is what PKCE expects.

Two smaller things while you are in there: type: 'signup' still works, but type: 'email' is what the current template docs use, and GoTrue normalises it to signup for an unconfirmed user. And the Auth logs will record the failed lookup as otp_expired even when nothing has expired, which is why the wording misleads.