Set App Limit
PUT /apps/{app_id}/limit
PREVIEW. This endpoint is deployed but gated: it returns 404 unless the hosted app platform is enabled for your organization. It is published here so the contract describes the whole surface, not so it can be called today.
Set this app’s hard credit cap for a window.
set_limit and clear_limit shipped with the repository layer
(repositories/usage.py:198,229), with a Protocol (contracts.py:957) and
tests, and NO route ever called them. So a builder could read their cap and
could never set one, and the only way a limit row came into existence was by
hand.
That matters more than a missing endpoint usually would: in a builder-pays model the cap is the entire spend-safety story. Enforcement was complete and unreachable.
Same shape as the #16816 bug, where store_credential and revoke_credential
shipped without callers so no service token could ever be minted.
SINGULAR /limit, not /limits. The read half is singular and is frozen
that way in openapi_operation_ids.json and the published bundle; adding a
plural verb would put two spellings of one resource in the public contract
forever.
Authorizations
Parameters
Path Parameters
Header Parameters
Request Body required
Set an app’s hard credit cap for a window.
window is optional and defaults to the only value the enum has today
(calendar_month, D5: fixed monthly allowance, monthly reset, no rollover).
Accepting it explicitly now means adding a second window later does not
change this DTO’s shape.
object
Hard cap in credits for the window. 0 means ‘cap at zero’, NOT ‘uncapped’ — to remove a cap, DELETE the limit instead.
Cap window. calendar_month is the only value today.
Responses
200
Successful Response
object
An app’s hard credit cap. Mirrors AppLimitDto.
The endpoint returns null for no cap. There is no “unlimited” sentinel, so
an accidental zero can never read as no limit.
422
Validation Error