Billing and commerce scopes, and the commerce API in the reference
Keys can now be limited to billing or commerce work, those routes check the scope, and every commerce operation is in the API reference.
You can now restrict an API key to billing: billing:read reads invoices, payments, credits and your marketplace earnings and payouts, and billing:write changes them. The commerce control plane gains commerce:configure for setting up connectors, pricing policies and data, beside the commerce scopes that already existed. Those routes now check the scope, where before any key of the workspace was accepted. A key or agent with explicit scopes now needs the matching billing:* or commerce:* scope for those routes, and without it gets a clear 403 naming the missing scope. Your dashboard session and keys created without scopes keep full access.
The key creation dialog now offers the real scope list, and creating a key with a name that is not a scope is refused with the list of valid ones. The read, write and admin choices the dialog used to offer were not scopes any route recognised; keys that already carry one are marked as legacy, and some of them lose access:
- A legacy read key is now read-only for billing and commerce. It can no longer create or change invoices, payments or credits, and it can no longer configure commerce, run a pipeline cycle or execute prices.
- No legacy key can approve or reject commerce proposals any more.
- Legacy write and admin keys keep the rest of their billing and commerce access, and no legacy key gains anything it was refused before.
To do any of those things, create a key with the specific scope, such as billing:write, commerce:proposal:approve or commerce:execute.
Every commerce operation, from connectors to executing approved prices, is now in the API reference, with the scope each one needs. The agent manifest lists where the billing records live and what credits mean here, and /payouts opens your marketplace payouts.