Login-readiness diagnostic

The login-readiness diagnostic answers one question in a single call: "will a browser sign-in from this origin actually complete?" — and every check reflects the effective runtime value, not a theoretical one. It's the fastest way to resolve the "signed in on Atlas, silently broken on my app" class of failure.

Call it

curl "https://<your-fapi-host>/v1/diagnostics/login_readiness?origin=https://<your-app-origin>" \
  -H "Authorization: Bearer sk_…"

Scope: diagnostics:read (a * key works). origin is the full web origin your app is served from.

Response

{
  "object": "login_readiness",
  "origin": "https://app.acme.com",
  "ready": true,
  "checks": [
    { "name": "cors",              "pass": true, "observed": { "exact_match": true, "same_site_custom_domain": true, "allowed_origins": ["https://app.acme.com"] }, "detail": "…" },
    { "name": "session_cookie",    "pass": true, "observed": { "effective_cookie_domain": ".acme.com", "host_only": false, "frontend_api_host": "auth.acme.com" }, "detail": "…" },
    { "name": "email_provisioning","pass": true, "observed": { "include_email_claim": true, "bapi_email_addresses": true }, "detail": "…" },
    { "name": "token_signing",     "pass": true, "observed": { "issuer": "https://auth.acme.com", "jwks_keys": 1 }, "detail": "…" }
  ]
}

The four checks

ready: true across all four means a real browser sign-in from that origin completes end to end. A red hop's detail names the exact fix. Run it after any custom-domain change.