Authorization
What a key can read, and the one rule that decides it.
A key is scoped to the workspace that created it. Every list it reads and every record it can open belongs to that workspace; a record in another workspace does not exist as far as the key is concerned, whether it is asked for by list, by id or by search. That scoping is a property of every endpoint, not something an endpoint opts into.
What a key may do
A key may do only what it was given when it was made. When you create a key you choose a starting point:
- Read only — read what WP Octo already knows about your sites;
- Read and ask — also ask a site read-only questions;
- Read, ask and act — also start safe operations, such as a backup;
- Full access — everything the API offers at the moment the key is made.
Underneath, the same choice is a grid of areas (sites, backups, updates and so on) and actions (read, ask, run, change, delete). You can tick exactly what the key needs; a dash marks something the platform does not offer yet. Something the API offers later is never added to an existing key: give it to a new key when you need it.
A request for something the key was not given is answered with 403, naming what is missing.
Keys made before keys had their own rights may do everything, including what is added later. Replace them with a key that has only what the integration needs.
Requests are made in the context of the key's workspace, so nothing in the request names a workspace: there is no workspace id to pass and none is accepted.