Orca Security User Management API Guide

Auth method: API Key (Bearer token passed in Authorization header)

Setup steps

1. Log in to the Orca Security platform as an admin.
2. Navigate to Settings > API Tokens.
3. Generate a new API token and copy the value.
4. Include the token in all API requests as: Authorization: Token

List Users

• Method: GET
• URL: https://app.us.orcasecurity.io/api/rbac/users
• Watch out for: Exact endpoint path and response schema are not fully documented publicly; verify against your tenant's API reference.

Request example

GET /api/rbac/users
Authorization: Token <api_token>

Response example

{
  "data": [
    {"id": "usr_123", "email": "user@example.com", "role": "Viewer"}
  ]
}

Get User

• Method: GET
• URL: https://app.us.orcasecurity.io/api/rbac/users/{user_id}
• Watch out for: Path parameters and field names are inferred from SCIM and general API docs; confirm with official Swagger/OpenAPI spec.

Request example

GET /api/rbac/users/usr_123
Authorization: Token <api_token>

Response example

{
  "id": "usr_123",
  "email": "user@example.com",
  "role": "Viewer",
  "status": "active"
}

Invite/Create User

• Method: POST
• URL: https://app.us.orcasecurity.io/api/rbac/users
• Watch out for: User creation via REST API may trigger an email invitation rather than immediately activating the account.

Request example

POST /api/rbac/users
Authorization: Token <api_token>

{"email": "newuser@example.com", "role": "Viewer"}

Response example

{
  "id": "usr_456",
  "email": "newuser@example.com",
  "status": "invited"
}

Update User Role

• Method: PATCH
• URL: https://app.us.orcasecurity.io/api/rbac/users/{user_id}
• Watch out for: Not all user fields may be patchable; role changes may require specific admin privileges.

Request example

PATCH /api/rbac/users/usr_456
Authorization: Token <api_token>

{"role": "Admin"}

Response example

{
  "id": "usr_456",
  "role": "Admin"
}

Delete User

• Method: DELETE
• URL: https://app.us.orcasecurity.io/api/rbac/users/{user_id}
• Watch out for: Deletion is likely permanent; no soft-delete or deactivation-only option confirmed via public docs.

Request example

DELETE /api/rbac/users/usr_456
Authorization: Token <api_token>

Response example

HTTP 204 No Content

• Rate limits: Orca Security does not publicly document specific rate limit values or tiers in their official docs as of the research date.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate limit documentation found. Contact Orca support for enterprise rate limit details.

• Pagination method: offset

• Default page size: Not documented

• Max page size: Not documented

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: No official webhook support for user-management events is documented in Orca Security's public developer docs.

• Alternative event strategy: Use SCIM provisioning via an IdP (e.g., Okta, Azure AD) for automated user lifecycle events, or poll the REST API.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Custom (Enterprise)

• Endpoint: https://app.us.orcasecurity.io/scim/v2

• Supported operations: Create User (POST /Users), Read User (GET /Users/{id}), List Users (GET /Users), Update User (PUT /Users/{id}), Deactivate User (PATCH /Users/{id}), Delete User (DELETE /Users/{id}), List Groups (GET /Groups), Create Group (POST /Groups), Update Group (PUT /Groups/{id}), Delete Group (DELETE /Groups/{id})

Limitations:

• Requires SSO to be configured and active before SCIM can be enabled.
• Available only on Custom/Enterprise pricing tier.
• SCIM token is generated within the Orca platform SSO settings; it is separate from the REST API token.
• Exact IdP connector support (Okta, Azure AD, etc.) should be confirmed with Orca support as public IdP-specific docs are limited.

Three primary automation scenarios are supported.

For IdP-driven provisioning, configure a SCIM 2.0 app in Okta or Azure AD pointing to the Orca SCIM endpoint with the SCIM bearer token;

the IdP will push create, update, and deactivate events automatically-but SSO must be fully operational first, and disabling SSO breaks SCIM.

For access audits, GET /api/rbac/users returns email, role, and status fields suitable for cross-referencing against an identity graph to surface orphaned or over-privileged accounts;

pagination behavior is undocumented, so large tenants should validate whether responses are truncated.

For offboarding, prefer SCIM PATCH (active=false) over REST DELETE when SCIM is active-it is reversible and preserves an audit trail.

If using the REST API directly, DELETE /api/rbac/users/{user_id} is likely permanent with no soft-delete option confirmed in public docs.

Changes made via SCIM may not be immediately reflected in REST API responses;

treat the two systems as eventually consistent rather than synchronous.

Provision users via SCIM from an IdP

1. Ensure SSO is configured and active in Orca Security Settings.
2. Navigate to Settings > SSO > SCIM and generate a SCIM bearer token.
3. In your IdP (e.g., Okta or Azure AD), configure a SCIM 2.0 app with the Orca SCIM endpoint and bearer token.
4. Assign users/groups in the IdP to the Orca SCIM application.
5. The IdP will push user create/update/deactivate events to Orca automatically.

Watch out for: SSO must be fully operational before SCIM activation. Disabling SSO will also break SCIM provisioning.

List and audit all platform users via REST API

1. Generate an API token in Orca Settings > API Tokens.
2. Send GET https://app.us.orcasecurity.io/api/rbac/users with Authorization: Token .
3. Parse the returned user list for email, role, and status fields.
4. Cross-reference with your identity directory for access review.

Watch out for: Pagination behavior is not publicly documented; large tenants may receive truncated results without clear next-page indicators.

Remove a departed employee's access

1. If using SCIM: deactivate or remove the user in the IdP; the IdP will send a SCIM PATCH (active=false) or DELETE to Orca.
2. If using REST API directly: identify the user's ID via GET /api/rbac/users, then send DELETE /api/rbac/users/{user_id}.
3. Verify removal by re-querying GET /api/rbac/users and confirming the user is absent or inactive.

Watch out for: REST API deletion may be immediate and irreversible. SCIM deactivation (active=false) is preferred for auditability.

The most significant operational trap is the dual-token architecture: teams that generate a REST API token and assume it covers SCIM will find provisioning silently failing. Rate limits are entirely undocumented-no headers, no retry-after signals, no published thresholds-so aggressive polling or bulk operations risk throttling without warning.

Custom role assignments via the API are not confirmed as fully patchable; role changes may require specific admin privileges and should be tested against your tenant before being embedded in automation.

Finally, the identity graph built from Orca's user objects (id, email, role, status) is only as reliable as the sync state between SCIM and REST; always re-query after write operations to confirm the intended state is reflected.