InVision User Management API Guide

Auth method: Not documented

User object field mapping is not yet verified for this app.

Endpoint coverage is not yet verified for this app.

• Rate limits: Not documented

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Not documented

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: InVision's developer portal references webhook-like integrations for prototype events, but no officially documented user-management webhook events (user created, deactivated, etc.) are publicly available.

• Alternative event strategy: Use SCIM 2.0 provisioning (Enterprise plan) for automated user lifecycle management via your IdP (Okta, Entra ID, OneLogin).

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://scim.invisionapp.com/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} active=false), Delete user (DELETE /Users/{id}), List groups (GET /Groups), Create group (POST /Groups), Update group membership (PATCH /Groups/{id})

Limitations:

• Requires Enterprise plan; not available on Free or paid non-Enterprise tiers.
• SSO must be configured and active before SCIM provisioning can be enabled.
• SCIM token is generated from the InVision admin console; no OAuth flow for SCIM.
• Supported IdPs with documented connectors: Okta, Microsoft Entra ID (Azure AD), OneLogin. Google Workspace is not officially listed.
• InVision has announced end-of-life transitions for some product lines; verify SCIM availability for your specific InVision product (V7 vs. Enterprise).
• Exact SCIM base URL and token generation steps must be confirmed in the admin console; the endpoint above is based on available support documentation and may vary.

Three primary automation scenarios are supported via SCIM.

First, provisioning a new employee through Okta: configure the InVision app in the Okta Integration Network, supply the SCIM base URL and bearer token, enable Create/Update/Deactivate operations, then assign users or groups - Okta sends POST /Users on assignment.

Second, offboarding: removing or deactivating the user in the IdP triggers PATCH /Users/{id} with active=false, suspending InVision access without deleting content. Third, group/team sync: IdP group mappings drive POST /Groups or PATCH /Groups/{id} calls; audit sync state periodically via GET /Groups.

Documented IdP connectors exist for Okta, Microsoft Entra ID, and OneLogin. Google Workspace is not officially listed. Confirm supported SCIM Group operations in your specific IdP's InVision app documentation before relying on group sync in production.

Provision new employee via Okta SCIM

1. Ensure Enterprise plan is active and SSO (SAML) is configured in InVision admin.
2. Navigate to InVision Admin > Security > SCIM Provisioning and generate a SCIM bearer token.
3. In Okta, add the InVision application from the Okta Integration Network.
4. Enter the SCIM base URL and bearer token in the Okta provisioning settings.
5. Enable 'Create Users', 'Update User Attributes', and 'Deactivate Users' in Okta.
6. Assign the Okta user or group to the InVision app; Okta sends POST /Users to InVision SCIM endpoint.
7. Verify user appears in InVision Admin > People.

Watch out for: If SSO is not fully active, SCIM provisioning will not function even if the token is generated.

Deprovision user on offboarding

1. Remove or deactivate the user in your IdP (Okta/Entra/OneLogin).
2. IdP sends PATCH /Users/{id} with active=false to InVision SCIM endpoint.
3. InVision deactivates the user, revoking access without deleting their content.
4. Confirm deactivation in InVision Admin > People (user status shows inactive).

Watch out for: Deactivation via SCIM suspends access but may not immediately free a paid seat depending on billing cycle; verify seat release behavior with InVision support.

Sync team/group membership via SCIM Groups

1. Map IdP groups to InVision teams in the IdP SCIM connector settings.
2. IdP sends POST /Groups or PATCH /Groups/{id} to create or update group membership.
3. InVision reflects group membership changes for access control to projects.
4. Periodically audit via GET /Groups to confirm sync state.

Watch out for: Group/team mapping capabilities depend on the IdP connector version; confirm supported SCIM Group operations in the specific IdP's InVision app documentation.

Several hard constraints make InVision's SCIM implementation higher-risk than a standard SCIM 2.0 integration. The bearer token is a static long-lived credential with no rotation mechanism; treat it as a high-value secret and store it in a secrets manager, not in plain config.

SSO must be fully active before SCIM will function - generating a SCIM token without a working SSO configuration will result in silent provisioning failures.

No public rate limit figures are documented for the SCIM endpoints. Implement standard exponential back-off and respect any Retry-After header on 429 responses. Critically, InVision is mid-product-transition with announced end-of-life for some product lines; SCIM availability is not guaranteed to be stable across account versions (V7 vs.

Enterprise). Verify SCIM is active and functional for your specific account before building any production automation against it. Deactivation via SCIM suspends access but does not transfer project ownership and may not immediately release a paid seat - confirm seat release behavior directly with InVision support.