Diagnose Accounts
Diagnose an app’s accounts-mode posture in one round trip.
Returns six things the user asked for in feedback 64268e05: (a) what config requests (apps.access_mode + access_policy) (b) what the gateway is actually serving (per gateway_routes row) (c) which /__floo/* endpoints are wired (derived: accounts-mode routes handle these intercepts; public-mode routes pass them through) (d) whether identity headers will reach the app (derived: same condition as floo-endpoints-wired — accounts-mode gateway routes inject X-Floo-User-* on every proxied request) (e) latest deploy’s per-environment request map and whether its target propagated
The drift list highlights mismatches the platform can detect without out-of-band probing — anything more involved (curling the runtime URL, inspecting WorkOS state) belongs in a separate runbook, not here.
Authorizations
A floo_ API key.
Headers
Organization to act in; defaults to the one joined most recently.
Path Parameters
Response
Successful Response
Top-level response for GET /v1/apps/{app_id}/doctor/accounts.
Six things the user asked for in feedback 64268e05 map directly: (a) requested.access_mode + access_policy (b) serving[].serving_access_mode (c) serving[].floo_endpoints_wired (d) serving[*].identity_headers_injected (e) latest_deploy.requested_app_access_mode + .propagated
drift_detected is the single health verdict (feedback #1156): True iff
drift is non-empty. It is the one bit a caller branches on, and it is
what the floo doctor accounts exit code mirrors (non-zero iff drift was
detected), so reading the body and branching on the exit code can never
disagree. The drift list is the supporting evidence behind the verdict.
App-level accounts policy seed.
The most recent deploy and whether its access_mode flip propagated.
requested_app_access_mode is non-null when the deploy carried an access-
mode flip from floo.app.toml. propagated is true iff the deploy reached
LIVE AND every downstream row (apps.access_mode and every gateway_route's
access_mode) lands at the requested value. The all-routes check is what
catches the canonical bug — apps row got flipped, gateway didn't —
instead of declaring success on the apps side alone.
The LIVE requirement is unconditional: a non-LIVE deploy (FAILED, still
deploying, awaiting approval, superseded) reports propagated:false even
when it carried no flip, because nothing it requested is in effect yet.
That keeps status and propagated from contradicting each other —
feedback #1156 saw status:failed + propagated:true on one object.
checked, not_applicable