Skip to main content

​
Overview

The Risk Cloud API enforces the same permission model as the Risk Cloud web application. Every API call is evaluated against the access of the user behind the token — if that user can perform an action in the UI, they can perform it through the API, and if they can’t, the API call is rejected the same way.

​
Authorization categories

API endpoints fall into four broad categories of authorization requirement:
  • Any authenticated user — a valid token is sufficient.
  • Specific module permission required — e.g. the RECORDS or BUILD module entitlement.
  • Access to a specific entity required — e.g. Read access to the Application or Step the record belongs to.
  • Combined requirements — e.g. the BUILD module entitlement plus Build Access on the specific Application.

​
Permission components

A user’s effective access is determined by five components:

​
List endpoints filter rather than reject

List endpoints don’t return a 403 for objects the caller can’t see — they simply omit them. For example, a call to GET /api/v2/records returns only the Records the requesting user has Read access to, rather than erroring or returning every record in the environment.

​
Troubleshooting

​
User types

Both regular users (who authenticate via password or SSO) and service accounts must have the API access permission enabled before they can generate a token. See Service Accounts for setting up dedicated, non-personal credentials for integrations.

​
Next steps

See Risk Cloud API: Viewing Users to look up user records via the API, and Authentication for how tokens and Access Keys are issued.