# Callback URL rules
## The exact-match rule
Allowed Callback URLs is a strict allowlist. The `redirect_uri` in the authorize request must match an entry character for character: scheme, host, port, path. Common killers:
- `https://app.example.com/callback` vs `https://app.example.com/callback/` (trailing slash)
- the service URL for that host and port vs the service URL for that host and port (port drift in dev)
- `https://App.example.com/x` vs `https://app.example.com/x` (host casing)
- query strings on the redirect_uri (register without them; Auth0 strips and re-adds its own params)
Comma-separate multiple URLs for dev/staging/prod. Never leave YOUR_HOST entries on a production app.
## Wildcards
`https://*.example.com` is allowed at the subdomain level. Path wildcards are not a thing. Auth0's own guidance: avoid wildcards in production callbacks; they widen the redirect surface. For multi-tenant B2B, prefer the `{organization_name}` placeholder (`https://{organization_name}.example.com`) on domains you fully control.
## The three URL fields
- Allowed Callback URLs: where Auth0 sends users after login (with the code).
- Allowed Logout URLs: where Auth0 may send users after /v2/logout via returnTo.
- Allowed Web Origins: origins allowed to make CORS/iframe calls to Auth0 (silent auth, passwordless). Query strings and hashes are ignored here.
## Native apps
Custom schemes like `[your scheme]://callback` are registered the same way, but prefer claimed HTTPS URIs (App Links / Universal Links) where the platform allows; custom schemes are subject to client impersonation.
## Checklist
- Copy the redirect_uri from the failing authorize request (browser devtools) and diff it against the dashboard entry.
- One entry per environment; delete stale ones.