> ## Documentation Index > Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # 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. ## OpenAPI ````yaml https://api.getfloo.com/openapi.json get /v1/apps/{app_id}/doctor/accounts openapi: 3.1.0 info: title: floo API version: 0.1.0 servers: - url: https://api.getfloo.com security: [] paths: /v1/apps/{app_id}/doctor/accounts: get: tags: - doctor summary: Diagnose Accounts description: |- 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. operationId: doctor_diagnose_accounts parameters: - name: app_id in: path required: true schema: type: string format: uuid title: App Id - $ref: '#/components/parameters/X-Floo-Org-Id' responses: '200': description: Successful Response content: application/json: schema: $ref: '#/components/schemas/AccountsDoctorResponse' default: description: Error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: parameters: X-Floo-Org-Id: name: X-Floo-Org-Id in: header required: false schema: type: string format: uuid description: Organization to act in; defaults to the one joined most recently. schemas: AccountsDoctorResponse: properties: app_id: type: string format: uuid title: App Id app_name: type: string title: App Name requested: $ref: '#/components/schemas/AccountsDoctorRequested' serving: items: $ref: '#/components/schemas/AccountsDoctorRoute' type: array title: Serving latest_deploy: anyOf: - $ref: '#/components/schemas/AccountsDoctorLatestDeploy' - type: 'null' drift_detected: type: boolean title: Drift Detected drift: items: $ref: '#/components/schemas/AccountsDoctorDrift' type: array title: Drift status: type: string enum: - checked - not_applicable title: Status checked_routes: type: integer title: Checked Routes type: object required: - app_id - app_name - requested - serving - latest_deploy - drift_detected - drift - status - checked_routes title: AccountsDoctorResponse description: >- 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. ErrorResponse: properties: detail: $ref: '#/components/schemas/ErrorDetail' type: object required: - detail title: ErrorResponse description: Body of every error response except request validation (422). AccountsDoctorRequested: properties: access_mode: type: string title: Access Mode access_policy: type: string title: Access Policy type: object required: - access_mode - access_policy title: AccountsDoctorRequested description: App-level accounts policy seed. AccountsDoctorRoute: properties: host: type: string title: Host path_prefix: type: string title: Path Prefix backend_url: type: string title: Backend Url serving_access_mode: type: string title: Serving Access Mode expected_access_mode: type: string title: Expected Access Mode floo_endpoints_wired: type: boolean title: Floo Endpoints Wired identity_headers_injected: type: boolean title: Identity Headers Injected type: object required: - host - path_prefix - backend_url - serving_access_mode - expected_access_mode - floo_endpoints_wired - identity_headers_injected title: AccountsDoctorRoute description: >- One gateway_routes row's view of an app's accounts-mode posture. Apps frequently have multiple routes (per service / per environment), and they can drift independently — that's the failure mode this surface exists to expose. Per-route fields are derived (not stored), so the JSON contract answers the user's question without making them join tables themselves. `expected_access_mode` is the environment's non-null applied mode. Comparing `serving_access_mode` against `apps.access_mode` would false-positive on legitimate mixed-mode environments and miss real environment drift. AccountsDoctorLatestDeploy: properties: id: type: string format: uuid title: Id status: type: string title: Status requested_app_access_mode: anyOf: - type: string - type: 'null' title: Requested App Access Mode requested_env_access_modes: anyOf: - additionalProperties: type: string type: object - type: 'null' title: Requested Env Access Modes propagated: type: boolean title: Propagated created_at: type: string format: date-time title: Created At type: object required: - id - status - requested_app_access_mode - propagated - created_at title: AccountsDoctorLatestDeploy description: >- 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. AccountsDoctorDrift: properties: kind: type: string enum: - no_gateway_routes - access_mode_drift - identity_headers_unreachable - deploy_not_live title: Kind summary: type: string title: Summary likely_fix: anyOf: - type: string - type: 'null' title: Likely Fix type: object required: - kind - summary title: AccountsDoctorDrift description: |- A single mismatch between requested config and observed serving state. Drifts are computed inside the doctor route — agents and humans should read this list first and treat the per-route detail above as evidence. ErrorDetail: properties: code: type: string title: Code message: type: string title: Message additionalProperties: true type: object required: - code - message title: ErrorDetail description: Standard error envelope with operation-specific JSON context. securitySchemes: bearerAuth: type: http scheme: bearer description: A `floo_` API key. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.