Billing state for any organization: the read-only twin of GET /v1/billing/status, for the staff Team view.

Same response model on purpose, for the same reason the invite/member routes above reuse org_api's — one React component renders both surfaces, so a shape divergence would only ever show up in the UI.

can_manage is hardcoded False, and that is the whole security posture of this route. Staff are not org admins of the organization they are looking at, and "Manage billing" opens a Stripe portal session against THAT organization's customer. The UI already refuses to render the button in staff mode; this is the second lock, on the side a browser cannot reach. Note also what is NOT returned: get_organization_billing hands back stripe_customer_id, stripe_subscription_id and billing_livemode, and the response model drops all three. Staff need to answer "why is this customer blocked", not to hold their Stripe identifiers.

Which is exactly why the CREDIT fields are returned. Omitting them left support looking at a customer whose every run is being refused and reading "Everything is up to date" — the one question this route exists to answer, unanswerable from its own response. Resolved the same way GET /v1/billing/status resolves them, through visible_credit_balance and credits_are_blocked, so staff see the customer's verdict rather than a second opinion computed from a raw column.

to_thread for the same reason as the routes above: get_organization_billing is blocking psycopg, and this process serves SSE streams.