Showpad User Management API Guide

Auth method: OAuth 2.0

Setup steps

1. Register an API application in the Showpad Admin portal under Settings > API.
2. Obtain a client_id and client_secret for your registered application.
3. Use the OAuth 2.0 authorization code flow (for user-delegated access) or client credentials flow (for server-to-server) to obtain an access token.
4. Request token from: https://{organization}.showpad.biz/oauth2/token
5. Include the access token as a Bearer token in the Authorization header of all API requests.

Required scopes

List users

• Method: GET
• URL: https://{organization}.showpad.biz/api/v3/users.json
• Watch out for: Pagination uses offset/limit query params. Total count is returned in the response envelope.

Request example

GET /api/v3/users.json?limit=10&offset=0
Authorization: Bearer {access_token}

Response example

{
  "response": {
    "status": 200,
    "data": {
      "items": [{"id":"abc123","email":"user@example.com","firstname":"Jane"}],
      "total": 50,
      "limit": 10,
      "offset": 0
    }
  }
}

Get user by ID

• Method: GET
• URL: https://{organization}.showpad.biz/api/v3/users/{id}.json
• Watch out for: Returns 404 if user does not exist or is not accessible with the current token's scope.

Request example

GET /api/v3/users/abc123.json
Authorization: Bearer {access_token}

Response example

{
  "response": {
    "status": 200,
    "data": {
      "id": "abc123",
      "email": "user@example.com",
      "firstname": "Jane",
      "lastname": "Doe",
      "status": "active"
    }
  }
}

Create user

• Method: POST
• URL: https://{organization}.showpad.biz/api/v3/users.json
• Watch out for: Username must be unique. Duplicate email/username returns a 409 conflict error.

Request example

POST /api/v3/users.json
Authorization: Bearer {access_token}
Content-Type: application/json

{"email":"new@example.com","firstname":"John","lastname":"Smith","username":"new@example.com"}

Response example

{
  "response": {
    "status": 201,
    "data": {
      "id": "xyz789",
      "email": "new@example.com",
      "status": "active"
    }
  }
}

Update user

• Method: PUT
• URL: https://{organization}.showpad.biz/api/v3/users/{id}.json
• Watch out for: Showpad v3 uses PUT (full or partial update behavior may vary); verify field behavior against current docs.

Request example

PUT /api/v3/users/abc123.json
Authorization: Bearer {access_token}
Content-Type: application/json

{"firstname":"Jane","status":"inactive"}

Response example

{
  "response": {
    "status": 200,
    "data": {
      "id": "abc123",
      "status": "inactive"
    }
  }
}

Delete user

• Method: DELETE
• URL: https://{organization}.showpad.biz/api/v3/users/{id}.json
• Watch out for: Deletion is permanent. Requires admin scope. Consider deactivating (status=inactive) instead of deleting to preserve audit history.

Request example

DELETE /api/v3/users/abc123.json
Authorization: Bearer {access_token}

Response example

{
  "response": {
    "status": 200,
    "data": {}
  }
}

List divisions

• Method: GET
• URL: https://{organization}.showpad.biz/api/v3/divisions.json
• Watch out for: Division IDs are required when assigning users to content groups. Fetch divisions before user creation if assigning.

Request example

GET /api/v3/divisions.json
Authorization: Bearer {access_token}

Response example

{
  "response": {
    "status": 200,
    "data": {
      "items": [{"id":"div1","name":"Sales EMEA"}]
    }
  }
}

Add user to division

• Method: POST
• URL: https://{organization}.showpad.biz/api/v3/divisions/{divisionId}/users.json
• Watch out for: Users must exist before being added to a division. Division membership controls content visibility.

Request example

POST /api/v3/divisions/div1/users.json
Authorization: Bearer {access_token}
Content-Type: application/json

{"userId":"abc123"}

Response example

{
  "response": {
    "status": 200,
    "data": {}
  }
}

Get SCIM Users (SCIM 2.0)

• Method: GET
• URL: https://{organization}.showpad.biz/scim/v2/Users
• Watch out for: SCIM endpoint requires a dedicated SCIM token generated in the Admin portal, separate from OAuth tokens. Requires Enterprise plan and SSO configured.

Request example

GET /scim/v2/Users?startIndex=1&count=10
Authorization: Bearer {scim_token}

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 50,
  "Resources": [{"id":"abc123","userName":"user@example.com"}]
}

• Rate limits: Showpad enforces API rate limits but does not publicly document specific numeric thresholds in official docs.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: Official documentation does not specify rate limit values, headers, or Retry-After behavior. Contact Showpad support for current limits.

• Pagination method: offset

• Default page size: 10

• Max page size: 100

• Pagination pointer: offset and limit

• Webhooks available: No

• Webhook notes: Showpad's official developer documentation does not describe a native outbound webhook system for user lifecycle events.

• Alternative event strategy: Use polling against the REST API (GET /users.json with updatedAt filtering) or rely on SCIM provisioning events from your IdP for user lifecycle automation.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Expert (Enterprise)

• Endpoint: https://{organization}.showpad.biz/scim/v2

• Supported operations: GET /Users – list users, GET /Users/{id} – get user by ID, POST /Users – create user, PUT /Users/{id} – replace user, PATCH /Users/{id} – update user attributes, DELETE /Users/{id} – deprovision user, GET /Groups – list groups/divisions, POST /Groups – create group, PATCH /Groups/{id} – update group membership

Limitations:

• Requires SSO (SAML) to be configured before SCIM provisioning can be enabled.
• SCIM token is generated separately from OAuth tokens in the Admin portal.
• Only available on the Expert (Enterprise) plan tier.
• Officially documented IdP integrations are Okta and Microsoft Entra ID (Azure AD); other IdPs may work but are not officially supported.
• Group provisioning maps to Showpad Divisions; not all Division attributes may be settable via SCIM.

Three automation scenarios are well-supported by the API.

First, provisioning a new sales rep requires a two-step sequence: POST /api/v3/users.json to create the account, then a separate POST /api/v3/divisions/{divisionId}/users.json to assign content access

skipping the second call leaves the user with no visible content.

Second, deprovisioning should use PUT /api/v3/users/{id}.json with {"status": "inactive"} rather than DELETE;

deletion is permanent, removes content sharing history, and requires admin scope.

Third, SCIM 2.0 auto-provisioning via Okta or Microsoft Entra ID is available on the Expert plan, using a dedicated SCIM bearer token generated separately from OAuth tokens in Admin > Integrations > SCIM

this token must be regenerated and re-entered in the IdP if rotated.

SSO (SAML) must remain active for SCIM to function;

disabling SSO breaks provisioning silently.

Provision a new sales rep and assign to a division

1. Authenticate via OAuth 2.0 client credentials to obtain an access token.
2. GET /api/v3/divisions.json to retrieve the target division ID (e.g., 'Sales EMEA').
3. POST /api/v3/users.json with email, firstname, lastname, username, and role='user'.
4. Extract the new user's id from the 201 response.
5. POST /api/v3/divisions/{divisionId}/users.json with the new userId to assign content access.

Watch out for: Division assignment is a separate API call after user creation. Skipping it leaves the user with no content access.

Deprovision a user when they leave the organization

1. Authenticate via OAuth 2.0 to obtain an access token with admin scope.
2. GET /api/v3/users.json?username={email} to look up the user's Showpad ID.
3. PUT /api/v3/users/{id}.json with {"status": "inactive"} to deactivate without data loss.
4. Optionally DELETE /api/v3/users/{id}.json for full removal if data retention is not required.

Watch out for: Deletion is irreversible and removes the user's content sharing history. Prefer deactivation for audit trail preservation.

Set up SCIM auto-provisioning via Okta

1. Confirm the Showpad account is on the Expert (Enterprise) plan.
2. Configure SAML SSO in Showpad Admin > Integrations > SSO and verify it is active.
3. In Showpad Admin > Integrations > SCIM, generate a SCIM bearer token and copy the SCIM base URL.
4. In Okta, add the Showpad application from the Okta Integration Network.
5. In the Okta app's Provisioning tab, enter the Showpad SCIM base URL and bearer token.
6. Enable Create Users, Update User Attributes, and Deactivate Users in Okta provisioning settings.
7. Assign users or groups in Okta to trigger initial provisioning to Showpad.

Watch out for: The SCIM token is separate from OAuth tokens and must be regenerated in Showpad if rotated. SSO must remain active; disabling SSO will break SCIM provisioning.

The primary integration trap in Showpad's API is the assumption that user creation completes provisioning. Division assignment is a fully separate API call with its own endpoint and failure mode - a user created without a subsequent division assignment is active but content-blind, and the API returns no warning.

A second trap: the v3 API uses PUT for user updates (PUT /api/v3/users/{id}.json), but full versus partial update behavior is not explicitly guaranteed in public documentation; validate field-level behavior against your specific plan's API version before building update logic.

A third caveat applies to teams using Stitchflow or any MCP server with 60+ deep IT/identity integrations: the absence of native webhooks means any real-time identity graph sync must be driven by the IdP's SCIM events (Expert plan only) or by scheduled polling

there is no push-based notification path for user lifecycle changes on lower tiers.