Abilities
The 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.view |
game-servers.manage | the power and command endpoints | game-servers.manage |
game-servers.files.read | browsing, reading and download URLs under files | game-servers.view |
game-servers.files.manage | everything under files that writes | 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.
Files are not part of managing a server
game-servers.manage does not grant game-servers.files.read, and neither
file ability is implied by the power ones. A key that restarts servers cannot read
their configs — which is where the RCON password and the database credentials live.
If a pipeline both writes a config and restarts the server, that is a case for two keys rather than one broader one. See Files.
Read the permission column
The organisation permission is not always the one the ability name suggests —
attacks.read requires network.view, not an attacks permission of any kind.
Take the column above literally rather than inferring one from the other.
A key issued with an ability your organisation does not grant is refused on those calls. See Authentication.