Mailer drops path component of API_EXTERNAL_URL when building confirmation URLs

[johnnyrw]

Summary

When API_EXTERNAL_URL contains a path component (e.g. http://127.0.0.1:54321/auth/v1), the mailer discards the path while building confirmation URLs, producing links that 404 when routed through an API gateway.

Versions

• Supabase CLI: 2.98.1
• Bundled auth image: public.ecr.aws/supabase/gotrue:v2.188.1

Reproduction

1. Run a local Supabase stack with default config; the auth container's env will contain API_EXTERNAL_URL=http://127.0.0.1:54321/auth/v1 and GOTRUE_MAILER_URLPATHS_CONFIRMATION=/verify.
2. Setting [auth] external_url = "http://127.0.0.1:54321/auth/v1" explicitly in supabase/config.toml does not change the behavior (also reproduces with the stock default).
3. POST http://127.0.0.1:54321/auth/v1/otp with { "email": "<seeded user>", "create_user": false }.
4. Inspect the resulting magic-link email in Mailpit (http://127.0.0.1:54324).

Expected

Link URL is http://127.0.0.1:54321/auth/v1/verify?token=...&type=magiclink&redirect_to=....

Actual

Link URL is http://127.0.0.1:54321/verify?token=...&type=magiclink&redirect_to=... — missing /auth/v1.

Clicking returns Kong's {"message":"no Route matched with those values"} 404, since Kong only has a route registered for /auth/v1/verify.

Verified end-to-end:

• GET /verify?... → 404 (no Kong route)
• GET /auth/v1/verify?... → 303 with a valid access_token JWT in the redirect Location

Apparent root cause

The mailer parses API_EXTERNAL_URL and uses only <scheme>://<host> when concatenating the GOTRUE_MAILER_URLPATHS_* suffix — discarding any path component. With URLPATHS_CONFIRMATION=/verify and API_EXTERNAL_URL=http://127.0.0.1:54321/auth/v1, the result is http://127.0.0.1:54321/verify instead of http://127.0.0.1:54321/auth/v1/verify.

This presumably also affects the recovery, invite, and email-change paths, all of which share the same URL-building code path.

Workaround

Override the magic_link email template via Supabase CLI config and hardcode the corrected URL using {{ .TokenHash }}, {{ .RedirectTo }}, and the literal /auth/v1/verify path.

Impact

Anyone running a recent Supabase CLI locally cannot use magic-link auth out of the box without a template override or manual URL surgery. Filed downstream as johnnyrw/book-keeper#66.

[Serm5902]

The Workaround worked to me.

Edit config.toml to override email template, create a HTML template with the corrected URL (following your instructions) and it works.

Thank u

[grschafer]

I just ran into this also. It looks like this issue originates in the CLI repo and was reported there (supabase/cli#5163) and has a fix committed in the latest pre-release: https://github.com/supabase/cli/releases/tag/v2.98.2

[aantti]

@jgoux, @avallete