Abilities
The five scopes a key can carry, and what each one reaches.
An API key is issued with a set of abilities. They are a separate vocabulary from the organisation roles you assign to people: a role says what a person can do in the portal, an ability says what a key can reach over HTTP.
| Ability | Reaches | Organisation permission required |
|---|---|---|
attacks.read | GET /attacks | network.view |
firewall.read | the two firewall GET endpoints | firewall.view |
firewall.manage | the firewall POST and DELETE endpoints | firewall.manage |
game-servers.read | GET /game-servers and GET /game-servers/{id} | game-servers.manage |
game-servers.manage | the power and command endpoints | game-servers.manage |
Grant the narrowest set
Read and manage are separate on purpose. A key that graphs your attack history, or one a dashboard uses to show firewall state, has no reason to be a key that can delete rules.
The practical shape: one read-only key per thing that observes, and a separate managing key for the one pipeline that actually changes something.
Read the permission column
The organisation permission is not always the one the ability name suggests —
game-servers.read requires game-servers.manage. Take the column above
literally rather than inferring a view permission from a read ability.
A key issued with an ability your organisation does not grant is refused on those calls. See Authentication.