Sana Labs User Management API Guide

Auth method: Bearer token for the tenant-specific SCIM endpoint

Setup steps

1. Log in to the Sana admin portal as an administrator.
2. Open the SCIM provisioning settings.
3. Generate or reveal the tenant-specific SCIM base URL and bearer token.
4. Use those values in your IdP SCIM connector configuration.

Create user via SCIM

• Method: POST
• URL: {tenant-scim-endpoint}/Users
• Watch out for: The SCIM base endpoint is tenant-specific and must be copied from the Sana admin portal.

Request example

POST /Users {"userName":"user@example.com","active":true}

Response example

{"id":"123","userName":"user@example.com","active":true}

Deactivate user via SCIM

• Method: PATCH
• URL: {tenant-scim-endpoint}/Users/{id}
• Watch out for: Validate supported attributes and PATCH behavior in a non-production tenant first.

Request example

PATCH /Users/123 {"Operations":[{"op":"Replace","path":"active","value":false}]}

Response example

{"id":"123","active":false}

• Rate limits: No public rate-limit policy is documented for Sana's SCIM endpoint.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Treat rate limits as undocumented and validate behavior in a test tenant before large syncs.

• Pagination method: offset

• Default page size: Not documented

• Max page size: Not documented

• Pagination pointer: startIndex / count

• Webhooks available: No

• Webhook notes: No webhook documentation found in publicly available Sana Labs resources.

• Alternative event strategy: Not documented

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: Not documented

• Supported operations: Create user, Update user, Deactivate user, List users

Limitations:

• SCIM endpoint URL is provisioned per-tenant; it is not a publicly documented static base URL.
• Requires Enterprise plan.
• Detailed field mappings and supported schema extensions are not publicly documented.

The primary integration pattern is IdP-driven SCIM provisioning via Okta, Azure AD, or equivalent.

Setup requires confirming an active Enterprise plan, generating a SCIM bearer token and tenant base URL from the Sana admin portal, configuring a SCIM app in your IdP with standard attribute mappings (userName, name.givenName, name.familyName, emails), and enabling create/update/deactivate sync.

Deprovisioning works by pushing active=false via SCIM PATCH or PUT from the IdP.

Whether this triggers a soft-delete or hard-delete is not publicly documented - confirm deactivation semantics with Sana support before using this in compliance-sensitive offboarding workflows.

Attribute update flows follow the same SCIM PATCH pattern.

Which schema extensions or custom attributes Sana accepts beyond core fields is undocumented;

validate all attribute mappings in a staging environment before production rollout.

Provision users via SCIM from an IdP

1. Upgrade to or confirm active Enterprise plan with Sana.
2. Navigate to the Sana admin portal and locate the SCIM provisioning settings section.
3. Generate a SCIM bearer token and copy the tenant-specific SCIM base URL.
4. In your IdP (e.g., Okta, Azure AD), create a new SCIM application using the Sana SCIM base URL and bearer token.
5. Map IdP user attributes to SCIM standard attributes (userName, name.givenName, name.familyName, emails).
6. Enable provisioning (create, update, deactivate) in the IdP and run an initial sync.

Watch out for: The SCIM base URL and token are tenant-specific and only visible inside the Sana admin portal; they are not published in public documentation.

Deactivate a departed employee

1. Deprovision or deactivate the user in your IdP.
2. The IdP sends a SCIM PATCH or PUT request to Sana with active=false.
3. Sana deactivates the user account, revoking access.

Watch out for: Deactivation behavior (soft-delete vs. hard-delete) is not explicitly documented publicly; confirm with Sana support before relying on this for compliance workflows.

Update user profile attributes

1. Update the user's attributes in the IdP (e.g., change department or display name).
2. IdP pushes a SCIM PATCH request to the Sana SCIM endpoint for that user.
3. Sana reflects the updated attributes on the user profile.

Watch out for: Which SCIM attributes Sana accepts and stores is not publicly documented; test attribute mappings in a staging environment before production rollout.

The core integration risk is opacity: Sana's SCIM implementation is functional, but almost every operationally important detail - field mappings, rate limits, pagination, deactivation behavior, group and role provisioning scope - is absent from public documentation.

Teams building identity graph automation against Sana must treat the integration as partially undocumented and plan for discovery work during implementation. Attempting SCIM setup on a non-Enterprise account will silently fail - the provisioning UI does not appear in the admin portal below that tier, and there is no fallback API surface.

Any pipeline that assumes a static SCIM base URL will break across tenants; the URL must be fetched per-tenant from the admin UI and stored securely.