Skip to main content
A scope is a permission attached to a key at creation. A key carries a fixed set of them for its whole life — see why they are not editable. A key created without an explicit choice gets catalog:read alone. radar:write spends nothing, which makes it easy to wave through — but it does put text on a page under our name once a reviewer approves it. Grant it to the integrations that should be able to list hardware, not to every key that reads Radar.

​
Endpoint by endpoint

GET /me needs no scope by design. It answers “does this key work and what may it do” — a question a key with no scopes at all still deserves an answer to, and one that reveals nothing to a holder who already has the key.
Quoting sits under rentals:read rather than catalog:read: a quote reads your account’s balance to fill in sufficient_balance, which is more than catalog data. It is not under rentals:write because it changes nothing and costs nothing.

​
Picking a set

catalog:readIt reads offers and prices; it never rents. If this key leaks, the worst outcome is that someone else learns our public prices — which they could have read from the marketplace page anyway.
catalog:read + rentals:readShows what is running, what it is costing, and what happened to it. Cannot start or stop anything, so a mistake in it is a wrong number on a screen rather than a stopped training run.
catalog:read + rentals:read + rentals:writeThe full set. Pair it with a daily spend limit — a scheduler is precisely the thing that can loop, and rentals:write without a cap is an unbounded bill.
A test key with whatever scopes the code path touches.Test keys read the real catalog, so your parsing and pagination get exercised properly, and every write is refused with test_mode_not_supported — which your CI can assert on.

​
When a scope is missing

403 with insufficient_scope, and the error names the scope you needed:
required_scope is there so your error handler can say “this key needs rentals:write” instead of “403”. It lives inside the error object like every other detail — nothing is added beside the envelope. This is not a retryable error. The key will never grow the scope; mint a new one.

​
Adding scopes later

You cannot. The migration is:
1

Mint a new key with the wider scopes

Name it so the two are distinguishable — prod-scheduler-v2, not prod-scheduler copy.
2

Deploy the new key

Both keys work at once, so there is no window where your integration is down.
3

Confirm the old key has gone quiet

Its usage panel should show nothing new. This is the step people skip and then get paged for.
4

Revoke the old key

Immediate, and final.
If you already know a key will eventually need to rent, grant rentals:read and rentals:write when you create it. Unused scopes cost nothing while the key sits in a config file doing catalog reads, and granting them up front saves the rotation above.That said, do not grant them to a key that will genuinely never rent. “Might need it one day” is how every over-privileged credential starts.