Troubleshooting: signed in on Atlas but not my app

Most integration failures are silent and spread across layers. This runbook maps a symptom to the exact layer, the one-line check, and the fix. If you only do one thing, run the login-readiness probe — it checks all four layers at once.

"Signed in on Atlas, but not on my app"

The user completes sign-in on Atlas, but your app still treats them as logged out (or your API returns 401). Work down these four in order:

1. No email → can't provision

Symptom: sign-in "succeeds" on Atlas, your API 401s the first request. Check: decode the __session JWT — is there an email claim? Or call GET /v1/users/:id — is email_addresses populated? Fix: turn on auth_config.session.includeEmailClaim (default ON for new instances), or read email_addresses from the BAPI user object. Your provisioning needs an email and Atlas must supply one.

2. Cookie is third-party → never sent to your app

Symptom: login works only when the app is on the exact FAPI host; breaks on a sibling subdomain. Check: the domain wizard's cookie_domain — is it .yourdomain.com (parent-scoped) or host-only? Does the first-party check pass for your origin? Fix: enable auth_config.session.crossSubdomainCookies (default ON for custom domains) and keep the app + FAPI on the same registrable domain.

3. CORS blocked → the SDK can't read the response

Symptom: social/iframe buttons work but email/password (or any SDK fetch) fails; browser console shows No 'Access-Control-Allow-Origin'. Check: is your app origin in allowed origins, or on the same registrable domain as a verified custom FAPI host? Fix: add the origin in Customization → Paths & origins. Same-registrable subdomains auto-allow.

4. Token won't verify → issuer/JWKS mismatch

Symptom: your backend rejects a token that Atlas issued. Check: does your verifier use issuer https://<your-fapi-host> and JWKS https://<your-fapi-host>/.well-known/jwks.json, algorithm RS256? Fix: point the verifier at your custom FAPI host (not the default Atlas host) once the domain is live, and allow a few seconds of clock skew (the access token TTL is ~60s).

Other silent traps

• A BAPI field was ignored. The BAPI is snake_case (client_id, not clientId) while auth_config is camelCase. A camelCase field is dropped. Send snake_case.

• `500 INTERNAL` on create-user. email_address may be sent as a string or a Clerk-style array — both are accepted now; other types return a 422 naming the problem.

• An endpoint's method changed. If a call returns "this endpoint has changed to a POST request," check the changelog and update the method.

Fastest path

Run the probe first — it turns "looks configured, silently fails" into a labeled pass/fail per layer:

curl "https://auth.<your-domain>/v1/diagnostics/login_readiness?origin=https://<your-app-origin>" \
  -H "Authorization: Bearer sk_live_…"