A valid request URL is required to generate request examples{
"url": "<string>"
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "billing_not_started",
"message": "<string>"
}
}{
"error": {
"code": "payload_too_large",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "admission_unavailable",
"message": "<string>"
}
}Open the billing portal
Returns a link into the payment provider’s hosted billing page for your organisation. Changing the card, reading invoices and downloading receipts all happen there; this service draws none of them itself.
ADMIN, AND A SIGNED-IN PRINCIPAL ONLY, the same rule the purchase route applies. An API key and a member both get 403.
The link is SINGLE USE AND SHORT LIVED. Navigate to it straight away; ask again for a fresh one next time. Its Return link comes back to the console’s Billing page, decided by this service rather than by the request.
An organisation with NO BILLING ACCOUNT at the provider gets 409 billing_not_started rather than a link to a page that cannot load. An organisation whose phones were all returned still has its account, and opens it to read invoices and receipts.
ONE BILLING ACCOUNT PER LINK. Each purchase has so far opened its own account at the provider, so an organisation that bought more than once has several, and this opens the one behind its most recent purchase that is still running (the newest of any state when none is). A card changed there pays that purchase’s subscription; earlier subscriptions keep their card.
Hosted deployments only. A local checkout does not mount this route, so calling it there is a 404.
A valid request URL is required to generate request examples{
"url": "<string>"
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "billing_not_started",
"message": "<string>"
}
}{
"error": {
"code": "payload_too_large",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "admission_unavailable",
"message": "<string>"
}
}Authorizations
The control surface credential. Send Authorization: Bearer <token>.
Two kinds of token are accepted and they are told apart by shape, not by a separate header. A token beginning pbk_ is an org scoped API key, whose public half and secret half are generated together and of which only a hash of the secret is ever stored; anything else is treated as an OAuth 2.1 access token and verified against the authorization server's keys.
Both resolve to the same context: an org, a principal and a set of scopes. Nothing downstream branches on which channel you used, with one deliberate exception, key management, which requires a signed-in person so that a key can never mint another key.
Scopes are enforced when MCP tools are REGISTERED rather than when they are called, so a tool your credential cannot use is absent from tools/list rather than refused mid gesture.
Response
Where to send the browser.
Somewhere to send the browser to change the card and read invoices and receipts.
The payment provider's hosted billing page for this organisation. Single use and short lived: send the browser there now, and ask again for a new one next time.