Approvals
Requires the Pro plan or higher; see Billing.
A request-and-decide workflow for changes that need a human, not a dead-end 403.
A developer submits a request, it routes to whoever is configured to decide it, and the decision (approve or reject, with an optional comment) is recorded against the request. Nothing about the underlying change happens until someone with the authority to decide it does.
The page is three tabs: My requests (what you've submitted), Needs my approval (what's waiting on you), and Routing — each carries a live count badge. A My queue panel keeps a running count of your own pending, approved and rejected requests alongside whichever tab is open.
What can be requested
| Request type | What it changes | Who can submit it |
|---|---|---|
api_key.budget_increase | Raises a daily and/or monthly cap on one of your own API keys. | Builder and above |
api_key.add_models | Adds models to a key's allowlist. | Builder and above |
api_key.rpm_increase | Raises a key's requests-per-minute limit. | Builder and above |
api_key.new_key | Mints a new API key with the requested name, caps, models and rate limit. The secret is revealed once, to the requester, only on approval. | Builder and above |
member.role_upgrade | Raises your own role. | Anyone |
other | Anything with no automated effect; the reason you type is the entire content of the request. | Anyone |
A viewer has no API key of their own to raise a budget on or add models to,
so those types are not offered to them — only other and a role-upgrade
request make sense for someone at that level.
New request shows exactly who it routes to (by name, not just a role label) before you submit, and takes the concrete fields for that request type directly — a budget increase asks for the new caps, a new key asks for its name, models and rate limit. An optional CC field lets you loop in other members without making them a decider.
Who decides
Each request type has a configured chain of one or two stages, set on the Routing tab (admin only) — its rules, stated right there on the page: every stage is a named person, never a bare role floor; stage 2, if set, must be someone other than stage 1; and a Default CC can be set per request type, copied on every request of that type but never an approver.
A multi-stage request must clear every stage in order: approving stage 1 of 2 moves it to stage 2, it does not apply the change yet. Only the final stage's approval actually mutates anything. Rejecting at any stage ends the request. Every change on the Routing tab applies immediately — there is no separate save step.
Needs my approval lists every request in the tenant, sorted with the ones you can decide right now first — so a request waiting on someone else stays visible for context rather than disappearing from view. Selecting a row opens its full detail: who raised it, when, the reason given, and the concrete fields (for a new key: its name, limits, allowed models, and rate limit) rather than a summary to take on trust.
Approve or Reject opens a second, explicit step before anything happens — with an optional comment recorded alongside the decision, and a note of whether this is the final stage (where approving applies the change immediately) or one of several. Both actions are disabled on your own request — a stage still routes to you as approver, but you can't clear your own submission.
How a request changes state
Submitted
A request starts in
pendingat stage 1. The requester sees who it routes to before submitting, not after.Decided per stage
An approver at the current stage approves or rejects, with an optional comment. Approving a non-final stage advances the request; it stays
pending.Applied on final approval
The change (the budget increase, the new key, the role bump) is applied only when the last stage approves. The request status becomes
approved.Or cancelled
The requester can cancel their own request while it is still
pending.
A rejection at any stage sets the request to rejected and nothing is
applied. Both outcomes are permanent — there is no re-opening a decided
request, only submitting a new one.