# OAuth broke after adding a custom domain

> Google, GitHub or Apple sign-in fails with redirect_uri_mismatch after a SupaHost custom domain goes active. Why the callback URL changes and what to update.

Source: https://supahost.app/kb/oauth-after-custom-domain · Updated 2026-11-11

## What you see

Social sign-in worked yesterday. Today, right after your custom domain went **Active**, the provider shows an error instead of the consent screen:

```
Error 400: redirect_uri_mismatch
```

or, on GitHub:

```
The redirect_uri is not associated with this application.
```

Other providers word it differently, but it's the same problem.

## Why it happens

When a custom domain becomes active, SupaHost makes it your project's public Auth address. From then on, Auth tells providers to send users back to:

```
https://api.bookings.example/auth/v1/callback
```

instead of:

```
https://app-one.acme.supahost.space/auth/v1/callback
```

Providers only redirect to callback URLs you've registered with them. The new one isn't on the list yet, so they refuse.

The same switch also changes the links in Auth emails, the URL Studio uses, and the `SUPABASE_URL` your Edge Functions see.

## How to fix it

1. Copy the callback URL from *Dashboard → your project → **Auth** tab*, in the OAuth provider settings. It now shows your custom domain.
2. Add it at each provider you use. Keep the old SupaHost callback too, at least until every client has switched over:

   | Provider | Where to add it |
   |---|---|
   | Google | Google Cloud console → your OAuth client → **Authorized redirect URIs** |
   | GitHub | Developer settings → your OAuth app → **Authorization callback URL** (one URL per app, so replace it) |
   | Apple | Your Services ID → **Return URLs**, and add the domain under **Domains and Subdomains** |
   | Microsoft (Azure) | App registration → **Authentication** → Redirect URIs |

3. Point your app at the custom domain:

   ```ts
   import { createClient } from "@supabase/supabase-js";

   export const supabase = createClient(
     "https://api.bookings.example",
     process.env.SUPABASE_ANON_KEY!,
   );
   ```

4. Try sign-in again in a private window, so an old session or cached redirect doesn't get in the way.

You don't need to change the **Site URL** or **Redirect URLs** on the Auth tab. Those are where users land in *your* app after sign-in, not the provider callback.

## On SupaHost

- With several active custom domains on one project, the oldest active one is used for Auth. Removing it moves Auth to the next one, or back to the SupaHost address, so the callback changes again.
- The JWT issuer stays `https://app-one.acme.supahost.space/auth/v1` and public Storage URLs keep using the SupaHost host. Tokens issued before the switch stay valid.
- The SupaHost address keeps working for API calls, so apps that haven't updated yet won't break, but their OAuth flows use the new callback.
- Saved Auth changes take effect within about a minute.
- Add the new callback at your providers before adding the domain if you can. A short window of failed sign-ins is the usual cost of doing it afterwards.

## Related

- [Custom domains](/docs/platform/custom-domains)
- [Social login (OAuth)](/docs/auth/social-login)
- [Sign in with Google](/docs/auth/google)
- [Redirected to the wrong URL after sign-in](/kb/redirect-to-wrong-url)