Productboard User Management API Guide

Auth method: API Key (Bearer token) – passed as Authorization: Bearer header. No OAuth 2.0 explicitly documented for the public REST API.

Setup steps

1. Log in to Productboard as an Admin.
2. Navigate to Settings → Integrations → API tokens.
3. Click 'Generate new token', name it, and copy the token value.
4. Include the token in all API requests as the Authorization header: 'Authorization: Bearer '.
5. For SCIM, generate a separate SCIM token under Settings → Security → SCIM provisioning after enabling SAML SSO.

List members (users)

• Method: GET
• URL: https://api.productboard.com/members
• Watch out for: Productboard's public REST API focuses on product data (features, notes, etc.). Direct user/member management endpoints are limited; SCIM is the recommended path for provisioning.

Request example

GET /members HTTP/1.1
Host: api.productboard.com
Authorization: Bearer <token>
X-Version: 1

Response example

{
  "data": [
    {"id": "uuid", "email": "user@example.com", "name": "Jane Doe", "role": "maker"}
  ],
  "pageCursor": "next_cursor_value"
}

SCIM – List Users

• Method: GET
• URL: https://api.productboard.com/scim/v2/Users
• Watch out for: Requires a SCIM-specific token, not the standard API token. SAML SSO must be configured first.

Request example

GET /scim/v2/Users?startIndex=1&count=100 HTTP/1.1
Host: api.productboard.com
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 5,
  "Resources": [
    {"id": "uuid", "userName": "user@example.com", "displayName": "Jane Doe", "active": true}
  ]
}

SCIM – Create User

• Method: POST
• URL: https://api.productboard.com/scim/v2/Users
• Watch out for: User is provisioned but may still need to accept an invitation depending on workspace settings.

Request example

POST /scim/v2/Users HTTP/1.1
Authorization: Bearer <scim_token>
Content-Type: application/json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"user@example.com","displayName":"Jane Doe","active":true}

Response example

{
  "id": "uuid",
  "userName": "user@example.com",
  "displayName": "Jane Doe",
  "active": true
}

SCIM – Update User (replace)

• Method: PUT
• URL: https://api.productboard.com/scim/v2/Users/{id}
• Watch out for: Full replacement semantics; omitting fields may clear them.

Request example

PUT /scim/v2/Users/uuid HTTP/1.1
Authorization: Bearer <scim_token>
Content-Type: application/json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"user@example.com","displayName":"Jane Updated","active":true}

Response example

{
  "id": "uuid",
  "userName": "user@example.com",
  "displayName": "Jane Updated",
  "active": true
}

SCIM – Deactivate/Deprovision User

• Method: PATCH
• URL: https://api.productboard.com/scim/v2/Users/{id}
• Watch out for: Sets active=false (soft deactivation). Hard deletion via DELETE may not be supported; verify with Productboard docs.

Request example

PATCH /scim/v2/Users/uuid HTTP/1.1
Authorization: Bearer <scim_token>
Content-Type: application/json

{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}

Response example

{
  "id": "uuid",
  "userName": "user@example.com",
  "active": false
}

SCIM – List Groups

• Method: GET
• URL: https://api.productboard.com/scim/v2/Groups
• Watch out for: Group provisioning maps to Productboard teams/spaces. Enterprise plan required.

Request example

GET /scim/v2/Groups HTTP/1.1
Host: api.productboard.com
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 2,
  "Resources": [
    {"id": "group-uuid", "displayName": "Product Team"}
  ]
}

SCIM – Create Group

• Method: POST
• URL: https://api.productboard.com/scim/v2/Groups
• Watch out for: Group membership changes may not immediately reflect in all Productboard spaces.

Request example

POST /scim/v2/Groups HTTP/1.1
Authorization: Bearer <scim_token>
Content-Type: application/json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:Group"],"displayName":"Product Team","members":[{"value":"user-uuid"}]}

Response example

{
  "id": "group-uuid",
  "displayName": "Product Team",
  "members": [{"value": "user-uuid"}]
}

• Rate limits: Productboard enforces per-token rate limits on the public REST API. Limits vary by endpoint category. Responses include rate-limit headers.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: When the limit is exceeded, the API returns HTTP 429. Clients should inspect the Retry-After header and back off accordingly. SCIM endpoint rate limits may differ.
• Pagination method: cursor
• Default page size: 100
• Max page size: 100
• Pagination pointer: pageCursor

• Webhooks available: Yes
• Webhook notes: Productboard supports webhooks for product data events (features, notes, etc.) configured via the developer portal or API. User lifecycle events (provisioning, deprovisioning) are not explicitly documented as webhook triggers; SCIM push from the IdP is the recommended mechanism for user lifecycle automation.
• Alternative event strategy: Use IdP-driven SCIM push (Okta, Entra ID, OneLogin) for user lifecycle events.
• Webhook events: feature.created, feature.updated, feature.deleted, note.created, note.updated

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://api.productboard.com/scim/v2

• Supported operations: GET /Users (list users), POST /Users (create user), GET /Users/{id} (get user), PUT /Users/{id} (replace user), PATCH /Users/{id} (update user / deactivate), GET /Groups (list groups), POST /Groups (create group), PUT /Groups/{id} (replace group), PATCH /Groups/{id} (update group members), DELETE /Groups/{id} (delete group)

Limitations:

• SAML SSO must be configured and active before SCIM can be enabled.
• Enterprise plan required; not available on Starter or Pro.
• SCIM token is separate from the standard REST API token.
• Hard DELETE for users may result in deactivation rather than permanent removal.
• Role assignment via SCIM is limited; role management may require manual steps in the UI.
• Supported IdPs with documented integration: Okta, Microsoft Entra ID (Azure AD), OneLogin.

The primary provisioning path is IdP-driven SCIM push. To provision a new user via Okta: configure SAML SSO first, generate a SCIM token in Productboard, set the SCIM base URL in Okta to https://api.productboard.com/scim/v2, then assign the user to the Productboard app.

Okta sends POST /scim/v2/Users; verify the result in Settings → Members. Test with a single user before bulk assignment - SSO misconfiguration causes provisioning calls to fail silently from the Productboard side.

Deprovisioning follows the same IdP-driven path: unassign the user in the IdP, which sends PATCH /scim/v2/Users/{id} with active=false. This is a soft deactivation - the user's features, notes, and comments remain in the workspace. Confirm deactivation by calling GET /scim/v2/Users/{id} and checking the active field. Hard DELETE behavior for users should be verified against current Productboard documentation, as it may resolve to deactivation rather than permanent removal.

Group sync maps IdP groups to Productboard teams and spaces via POST /scim/v2/Groups and PATCH /scim/v2/Groups/{id} for membership updates. Group-to-space attribute mapping should be validated post-setup; not all IdP group attributes have documented equivalents in Productboard. Role assignment via SCIM is limited and may require supplementary manual steps in the UI - this is a known gap in the SCIM implementation.

Provision a new employee via Okta SCIM

1. Ensure SAML SSO is configured in Productboard (Settings → Security → SSO).
2. In Productboard, navigate to Settings → Security → SCIM provisioning and generate a SCIM token.
3. In Okta, add the Productboard SCIM app, set the SCIM base URL to https://api.productboard.com/scim/v2, and paste the SCIM token.
4. Assign the Okta user to the Productboard app; Okta sends POST /scim/v2/Users to create the user.
5. Verify the user appears in Productboard under Settings → Members.

Watch out for: If SSO is not fully configured before enabling SCIM, provisioning calls will return errors. Test with a single user before bulk assignment.

Deprovision a departing employee

1. In the IdP (Okta/Entra/OneLogin), unassign the user from the Productboard application.
2. The IdP sends PATCH /scim/v2/Users/{id} with active=false to Productboard.
3. Productboard deactivates the user, revoking access.
4. Confirm deactivation by calling GET /scim/v2/Users/{id} and checking active=false.

Watch out for: Deactivation is a soft operation. The user's data (features, notes) remains in Productboard. Hard deletion behavior should be verified against current Productboard documentation.

Sync a team/group from IdP to Productboard

1. Create a group in the IdP (e.g., 'Product Team' in Okta).
2. Assign the group to the Productboard SCIM app in the IdP.
3. The IdP sends POST /scim/v2/Groups with displayName and member list.
4. Productboard creates the corresponding team/space and adds members.
5. To add/remove members, update group membership in the IdP; the IdP sends PATCH /scim/v2/Groups/{id} with member operations.

Watch out for: Group-to-space mapping behavior in Productboard should be validated post-setup; not all IdP group attributes may map to Productboard team attributes.

The most common integration mistake is conflating the two token types. The standard REST API token does not authenticate SCIM requests; using it against /scim/v2 endpoints will return auth errors. Both tokens must be generated, stored, and rotated independently.

Building user lifecycle automation against the public REST API's /members endpoint is a trap: that surface is not designed for provisioning and lacks the full create/update/deactivate semantics that SCIM provides.

SCIM 2.0 is the only supported path for programmatic user lifecycle management, and it is gated to Enterprise plan with SAML SSO as a prerequisite - attempting to enable SCIM on Starter or Pro will fail at the configuration step.

For teams building an identity graph across their SaaS stack, Productboard's user object exposes id (UUID), email, name, role (enum), status (active/deactivated), createdAt, and updatedAt. There is no last-login field in the documented user object, which limits the signal available for access review automation.

Webhooks cover product data events (feature.created, note.created, etc.) but do not fire on user lifecycle events - IdP-driven SCIM push is the only supported mechanism for event-driven provisioning and deprovisioning.