Raptor Comply API keys carry api_user-level permissions. Understand what data you can access, how keys are scoped, and what operations are available.
Every API key in Raptor Comply carries api_user role-level access, scoped to a single organization. This role is purpose-built for integrations: it gives you broad read access to your infrastructure data and full CRUD access to cyber assets, while keeping administrative and user-management operations restricted to humans with elevated roles inside the application. Before you start building, understand exactly what your key can and cannot do.
Treat your API key like a password. Store it in an environment variable or a secrets manager. Never commit it to source code, configuration files checked into version control, or any other location where it could be inadvertently exposed. If a key is compromised, your organization admin must revoke it immediately.
What api_user can do
| Capability | Detail |
|---|
| Read all facilities | GET /facilities, GET /facilities/{id} |
| Read all control centers | GET /control-centers, GET /control-centers/{id} |
| Read all cyber systems | GET /cyber-systems, GET /cyber-systems/{id} |
| Full CRUD on cyber assets | GET, POST, PATCH, and DELETE on /cyber-assets and /cyber-assets/{id} |
| Access compliance data | Policy documents, evidence, tasks, and training endpoints are rolling out - see API Reference for current availability |
What api_user cannot do
The api_user role is intentionally scoped to data operations. It does not grant access to administrative functions, including:
- Modifying organization settings or configuration
- Managing users (creating, updating, or deleting user accounts)
- Sending or canceling invitations
- Assigning or revoking roles
- Viewing or managing activity logs
- Performing any other operation restricted to the Organization Admin role
If your integration requires these capabilities, contact Raptor Comply support to discuss your use case.
API key scope
Each API key is tied to exactly one organization at the time it is generated. The key:
- Cannot be used to access any other tenant, regardless of which headers you pass
- Does not expire on a set schedule - keys remain valid until explicitly revoked by an admin
- Does not share a session with the admin who generated it - the key’s permissions are fixed at the
api_user role and are not affected by changes to that admin’s own account
Because keys do not auto-expire, treat them like long-lived credentials and include key rotation in your security policy. Raptor Comply recommends rotating API keys at least annually and immediately after any suspected exposure.
Generating and revoking keys
Only users with the Organization Admin role can generate and revoke API keys inside Raptor Comply.
To get a key:
- Ask your Organization Admin to generate a new API key in the Raptor Comply application.
- Have them share it with you through your organization’s standard secrets-handling process. Raptor Comply does not email keys.
- Store the key in an environment variable or secrets manager before you use it.
To revoke a key:
- The Organization Admin must explicitly revoke the key inside Raptor Comply.
- Generating a new key does not automatically revoke the previous one - both keys remain valid until the old one is manually revoked.
- After generating a replacement, update your integration to use the new key, then confirm the old key is revoked.
This means you can rotate keys with zero downtime: generate the new key, deploy the updated credential, verify it works, then revoke the old key.
Coming soon: granular access control
Today, all API keys carry the same api_user permission set. The /access-control endpoints - currently in development - will introduce finer-grained access control, allowing admins to restrict specific keys or users to subsets of facilities, cyber systems, or operations. When this feature is available, you will be able to model least-privilege access patterns directly in Raptor Comply rather than enforcing them solely in your integration layer.
See the API Reference for the current status of access control endpoints.