HYBRID-CHAINDEVELOPERS
DOCUMENTATIONv2
POST

Customer billing

Create portal session

/api/v2/billing/portal-sessions
AUTHENTICATIONBearer token · billing:writeAUTHORITATIVE OWNERbilling-serviceCONTRACT AUTHORITYCapability registry · plannedSTATUSPlanned · not executable
PLANNING CONTRACT · NOT CALLABLE

This page describes intended capability and integration boundaries so people and agents can prepare safely. Do not send this request or register it as an executable tool. Wait until the capability registry marks it implemented-contract, then re-fetch the deployed OpenAPI document and build the request from that machine contract.

PURPOSE + BUSINESS CONTEXT

Planned capability: create a short-lived customer billing portal session.

WHEN THIS CALL IS USEFUL

Do not call or register this operation as an executable agent tool yet. Use this page to plan the future portal session workflow; enable it only after the status becomes implemented-contract and the exact operation appears in deployed OpenAPI.

OUTCOME · Planned · Create or advance

What changes

None today: this route is not executable. Its intended behavior is: no executable Rust gateway behavior exists. A future promotion would read the workspace's private processor customer context and create one hosted portal session without exposing the customer identifier.

WHY IT MATTERS

  • Lets people and agents prepare for portal session without falsely presenting roadmap scope as a live capability.
  • Gives people and agents a contract-backed way to advance portal session.
  • Lets clients distinguish commercial catalog terms, available credits, metered events, pending reconciliation, subscription state, and financial settlement before presenting spend or availability.

ISOLATION + AUTHORITY

Workspace, product, price, currency, credit grant, allowance, credit pool, subscription, usage event, pending event, invoice, payment, and settlement authorities remain distinct. A displayed balance or product does not reserve credits, purchase service, move money, settle an invoice, or authorize another domain action. This planning record grants no runtime authority, and only deployed OpenAPI can define an executable public contract.

BEFORE YOU CALL

  • First confirm that this operation is marked implemented-contract and exists in the currently deployed OpenAPI document; until then, no production request is valid.
  • Its capability-registry profile is provisional integration guidance, not an executable request schema.
  • Authenticate at the documented boundary: bearer+scope.
  • Treat the capability-registry profile as design guidance only; deployed OpenAPI must define the executable request and response shapes.
  • Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
  • Resolve the authenticated workspace, active billing period, product or subscription context, currency precision, credit-pool order, and pending reconciliation posture.

WHAT TO DO NEXT

  • Keep this operation disabled in clients, agents, SDKs, and workflow automation while it remains planned-contract.
  • Use the stated owner, lifecycle, authority boundary, and provisional portal session profile to prepare requirements and conformance tests without sending a request.
  • Monitor the capability registry for implemented-contract, then re-fetch deployed OpenAPI and validate its exact security, parameters, schemas, responses, and agent metadata before enabling the integration.

AGENT GUIDANCE

  • Never call this planned contract, include it in an executable tool registry, or infer runtime availability from this readable page.
  • Its capability-registry profile is provisional integration guidance, not an executable request schema.
  • Use portal session only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
  • Treat the capability-registry profile as design guidance only; deployed OpenAPI must define the executable request and response shapes.
  • Preserve credit quantities and minor-unit prices exactly; distinguish granted, available, committed, consumed, pending, expired, reconciled, invoiced, paid, and settled states.
  • After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
  • When implementation lands, discard generated requests based on this planning record and rebuild them from the deployed OpenAPI operation.
MACHINE CONTRACT

This operation is a non-executable planning contract. Its capability-registry record defines the intended owner, parameters, responses, and integration boundary until an implemented Rust OpenAPI operation replaces it.

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

Examples describe the reviewed planning contract and remain non-executable until promoted into OpenAPI.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE
AuthorizationheaderRequired

Bearer tokenCredential containing the billing:write scope.EXAMPLEBearer hc_live_…

Idempotency-KeyheaderRequired

ASCII string · 1–128Caller-generated key reused for every retry of the same logical mutation.EXAMPLEportal-workspace-20260901-01

Content-TypeheaderRequired

application/jsonSigned mutations accept canonical JSON only.EXAMPLEapplication/json

Content-DigestheaderRequired

RFC 9530 SHA-256 digestDigest of the exact transmitted body bytes.EXAMPLEsha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:

Signature-InputheaderRequired

RFC 9421 signature parametersCovers @method, @path, content-digest, content-type, and idempotency-key; includes keyid, nonce, created, and expires.EXAMPLEsig1=("@method" "@path" "content-digest" "content-type" "idempotency-key");created=1786582800;expires=1786583100;nonce="01J…";keyid="machine-prod"

SignatureheaderRequired

Ed25519 HTTP Message SignatureSignature made by an active public key registered to the authenticated client.EXAMPLEsig1=:base64-signature:

REQUEST

JSON body example

{}

RESPONSES

Status and payload examples

501Profiled planning contract only; the Rust gateway has no authoritative hosted portal-session owner.Not executable · JSON RESPONSE+
{
  "code": "planned_contract",
  "message": "Hosted billing portal access is not available through V2."
}
INTEGRATION DECISIONplanned_contract
CALLER ACTION
Do not send this request or register it as an executable agent tool. Use the implemented alternatives linked by the module guide.
RETRY SAFETY
Do not retry on a timer. Re-fetch production OpenAPI and proceed only after this exact operation appears there.
STATE RECONCILIATION
No runtime state exists to reconcile for this planning contract. Continue from workspace billing account, subscription, entitlement, invoice summary, and usage projections through an implemented operation.
ESCALATE WHEN
Escalate when entitlement, subscription, invoice, usage, or provider evidence remains inconsistent after a fresh Core billing read.

OPERATIONAL NOTES

Security and lifecycle guarantees

  • The future request body is exactly empty. Workspace, processor customer, processor mode, portal configuration, locale, and return path must be owner-derived; processor IDs and caller-selected URLs are forbidden.
  • A promoted 201 would return only portal_url and expires_at under no-store. Treat portal_url as a short-lived bearer capability and keep it out of prompts, logs, analytics, referrers, browser persistence, and agent memory.
  • A 409 is expected when no processor customer profile exists, commonly before the first successful subscription checkout. Never fabricate a customer ID or switch workspace to bypass this state.
  • A portal return redirect is not canonical billing state. Actions become authoritative only after signed processor-event reconciliation; re-read GET /api/v2/billing/account.
  • Promotion requires a protected processor adapter, fixed allowlisted return path, strict customer and test/live isolation, short expiry, idempotency, webhook reconciliation, and conformance tests. Until then, agents must not call this planning route.
DOCUMENTATION STATUS

This planned contract now defines its public parameters, authorization boundary, replay behavior, responses, and authoritative owner. It remains non-executable until its owner adapter and conformance tests are promoted into the Rust gateway.

Return to the V2 directory ↗