Skip to main content
Argus decides what a caller may do from a flat list of permission keys. There are 32, and this page lists all of them. Each endpoint in the API reference states the key it checks on its Permission line.

How permissions work

  • Checked on the server, on every request. The web application hides what you cannot use, but that is a convenience. GET /api/me returns the permissions in effect for you.
  • Exact. A check names one key, and no key implies another. Holding admin.manage alone does not let you dispatch, and cad.dispatch is no use without cad.view.
  • From roles. An administrator gives a staff member one or more roles. Each role is a set of keys, and a person holds the union of their roles.
  • Only while the staff profile is active. Deactivating a profile removes every role permission at once. The session stays signed in.
  • Read again on every request. A change to a role or to someone’s membership applies to their very next request.
A missing permission returns 403 FORBIDDEN, and the message names the key.

Held by everyone

Every active signed-in account holds two permissions, with or without a staff role:
  • civilians.create
  • civilians.manage_own
That is what lets any member use the civilian portal. Everything else comes from roles.

Service credentials

A service credential’s scopes are permission keys from the same catalogue. It can hold any of them except admin.manage and staff.manage. Holding a scope is not always enough: endpoints that need a signed-in person refuse credentials whatever their scopes. See Authentication.

Developer Access

While temporary Developer Access is on, the session holds every permission in the catalogue. It is internal tooling, described under Authentication.

The catalogue

CAD: Control

Held by dispatchers. Every Control endpoint checks cad.view first; each kind of change checks one more.

MDT: unit self-service

Held by people who crew units. These endpoints also need an active staff profile.

Civilians

The first two are held by every signed-in account.

PNC

Reading and each kind of official change are separate.

Staff, shifts and sessions

Moderation

Oversight and administration

ER:LC

Rules that are not a single key

Some endpoints decide by ownership or membership instead of, or as well as, a permission.

Endpoints with no permission key

These need a signed-in user and check no permission. Sign-in itself is public: GET /auth/discord and its callback need no session.

Default roles

Seeding a deployment creates these roles. Administrators can add others through the API.
  • Administrator is fixed. The API refuses to rename it or change its permissions, and every seed brings it up to the full catalogue.
  • Other roles are created once. Seeding leaves a role that already exists exactly as it is. When a release adds a key to a default role, a deployment seeded earlier does not gain it; an administrator has to add it to that role.
  • Dispatcher and Police officer are separate. A dispatcher cannot use the PNC and an officer cannot open Control unless they hold both roles.