GET /api/v2/billing/account
Returns one document that answers, for whoever is responsible for an
account’s money: which plan and terms the account is on, what has been used,
what is funded and what is owed, which agreements are in force, and the one
concrete step — if any — needed to become or remain paid. It reads the same
facts the org-settings Billing tab and the Plan & Billing page show; anything
shown on those surfaces that isn’t in this document is a bug.
Money always describes the organization: a child account’s request
resolves to its parent (billing lives at the org level), and the returned
organization.customerId reflects that. A human caller needs org-admin
standing (a child-account admin must also be an admin of the parent). An API
key (service token) bound to the organization gets the document with
payment-detail fields and contract-document download links redacted — marked
with "visibility": "redacted" and redactedFields so an agent can tell
“not allowed” from “empty”. Advertiser-scoped keys and keys bound to a child
account are denied. Credit-application reviewer notes are internal to Scope3
and always read as null here; your own justification text stays visible.
Request
curl
Parameters
This endpoint takes no parameters.From an agent (MCP)
Two read-only MCP tools cover the same document on both the buyer and storefront MCP servers — billing lives at the organization level regardless of role:get_billing_accountreturns this document as the tool’s structured content. An optionalsectionparameter (one oforganization,scope,standing,plan,pricing,usage,payment,contracts,accounts,nextAction,permissions) returns just that section to keep the response small;section: "accounts"also returnstotalAccounts, since theaccountsarray is capped at 50 entries.open_plan_and_billingopens the Plan & Billing view in chat — a read-only page showing standing, balance, the next action, and an intelligence-usage summary, with links to the full web page.
Response
Document sections
payment.deposits lists the organization’s recent prepay deposits (newest
first, at most 10): each row carries the deposited amount in minor units, its
currency, when it took effect, whether it was later reversed, and the payment
provider and reference recorded with it. Every row is projected read-only from
the platform ledger — the same source of truth as the balances above.
Some fields are typed but always empty today because the platform doesn’t yet
have a source for them: plan.subscriptions, pricing.publicList, and
payment.invoices. They will start populating as their owning features ship,
with no change to this response shape.
nextAction values
Only one
nextAction is ever returned — the single most important thing to
do, not a checklist. permissions tells you whether the authenticated caller
can act on it directly, or should route it to an account admin.
Errors
401 UNAUTHORIZED— missing or invalid bearer token.403 ACCESS_DENIED— the caller is not an account admin (or, for a child account, an admin of the parent organization), or the API key is advertiser-scoped or bound to a child account.
Related
Get billing info
The payer identity on its own, without the rest of the account
Billing overview
How invoicing and remittance work