Alteryx User Management API Guide

Auth method: OAuth 2.0 (client credentials flow via API key/secret exchanged for bearer token)

Setup steps

1. Log in to Alteryx Server as an admin.
2. Navigate to Admin > API Access Keys and generate a Client ID and Client Secret.
3. POST to /oauth2/token with grant_type=client_credentials, client_id, and client_secret to obtain a bearer token.
4. Include the bearer token in the Authorization header as 'Bearer {token}' for all subsequent API requests.

Required scopes

List Users

• Method: GET
• URL: /api/v3/users
• Watch out for: Only Server Admins can call this endpoint. Results are paginated; iterate page parameter to retrieve all users.

Request example

GET /api/v3/users?page=1&pageSize=25
Authorization: Bearer {token}

Response example

{
  "users": [
    {"id": "abc-123", "firstName": "Jane", "lastName": "Doe",
     "email": "jane@example.com", "role": "Creator", "isActive": true}
  ],
  "count": 1
}

Get User by ID

• Method: GET
• URL: /api/v3/users/{id}
• Watch out for: Returns 404 if user ID does not exist or is deactivated and not found.

Request example

GET /api/v3/users/abc-123
Authorization: Bearer {token}

Response example

{
  "id": "abc-123",
  "firstName": "Jane",
  "lastName": "Doe",
  "email": "jane@example.com",
  "role": "Creator",
  "isActive": true
}

Create User

• Method: POST
• URL: /api/v3/users
• Watch out for: Email must be unique. Role must be a valid enum value. Server authentication mode (built-in vs. Windows/SAML) affects whether a password is set separately.

Request example

POST /api/v3/users
Authorization: Bearer {token}
Content-Type: application/json
{
  "firstName": "John", "lastName": "Smith",
  "email": "john@example.com", "role": "Member"
}

Response example

{
  "id": "def-456",
  "firstName": "John",
  "lastName": "Smith",
  "email": "john@example.com",
  "role": "Member",
  "isActive": true
}

Update User

• Method: PUT
• URL: /api/v3/users/{id}
• Watch out for: Alteryx Server API v3 uses PUT (full replacement) for user updates, not PATCH. All required fields must be included.

Request example

PUT /api/v3/users/def-456
Authorization: Bearer {token}
Content-Type: application/json
{
  "firstName": "John", "lastName": "Smith",
  "email": "john@example.com", "role": "Creator"
}

Response example

{
  "id": "def-456",
  "firstName": "John",
  "lastName": "Smith",
  "email": "john@example.com",
  "role": "Creator",
  "isActive": true
}

Deactivate User

• Method: DELETE
• URL: /api/v3/users/{id}
• Watch out for: This deactivates the user rather than permanently deleting them. Deactivated users remain in the system but cannot log in.

Request example

DELETE /api/v3/users/def-456
Authorization: Bearer {token}

Response example

HTTP 200 OK
{}

Search Users

• Method: GET
• URL: /api/v3/users?search={query}
• Watch out for: Search behavior (exact vs. partial match) is not fully documented; test against your server version.

Request example

GET /api/v3/users?search=jane&page=1&pageSize=25
Authorization: Bearer {token}

Response example

{
  "users": [
    {"id": "abc-123", "email": "jane@example.com", "role": "Creator"}
  ],
  "count": 1
}

Get User Groups

• Method: GET
• URL: /api/v3/usergroups
• Watch out for: User groups are separate from individual users. Group membership affects permissions and must be managed via separate /usergroups endpoints.

Request example

GET /api/v3/usergroups?page=1&pageSize=25
Authorization: Bearer {token}

Response example

{
  "userGroups": [
    {"id": "grp-789", "name": "Analysts", "role": "Creator"}
  ],
  "count": 1
}

Add User to Group

• Method: POST
• URL: /api/v3/usergroups/{groupId}/users
• Watch out for: Both the user and group must already exist. Group membership changes may affect workflow and collection access immediately.

Request example

POST /api/v3/usergroups/grp-789/users
Authorization: Bearer {token}
Content-Type: application/json
{"userId": "abc-123"}

Response example

HTTP 200 OK
{}

• Rate limits: Alteryx Server API v3 rate limits are not explicitly documented in official public docs. No specific request-per-minute or daily limits are published.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate limit documentation found. Limits may be governed by server infrastructure configuration.

• Pagination method: offset

• Default page size: 25

• Max page size: 100

• Pagination pointer: page and pageSize query parameters (e.g., ?page=1&pageSize=25)

• Webhooks available: No

• Webhook notes: Alteryx Server does not document native webhook support for user management events in official docs.

• Alternative event strategy: Poll the /api/v3/users endpoint periodically to detect changes, or use SCIM provisioning with an IdP that supports event-driven sync.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (requires SSO/SAML to be configured as a prerequisite)

• Endpoint: https://{your-alteryx-server}/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 (activate/deactivate), DELETE /Users/{id} – deactivate user, GET /Groups – list groups, POST /Groups – create group, PATCH /Groups/{id} – update group membership, DELETE /Groups/{id} – delete group

Limitations:

• SCIM provisioning requires SAML SSO to be enabled and configured first.
• Available on Enterprise plan only.
• SCIM bearer token is generated from the Alteryx Server admin UI under SAML/SCIM settings.
• IdP-side configuration (e.g., Okta, Azure AD) must use the Alteryx-provided SCIM endpoint and token.
• Group push support may vary by IdP connector; verify supported attributes with your IdP.

Provisioning a new user requires a POST to /api/v3/users with firstName, lastName, email, and role.

In SAML environments, the account is created but no password is set - the user must authenticate through the IdP on first login.

Capture the returned UUID for downstream group membership calls via POST /api/v3/usergroups/{groupId}/users.

Deactivation uses DELETE /api/v3/users/{id}, but this is a soft deactivation

the account remains in the system with isActive: false and may still consume a license seat until permanently removed through the admin UI.

Confirm state with a follow-up GET /api/v3/users/{id} and document the gap in any offboarding automation.

User updates require PUT /api/v3/users/{id} with a full object payload - this is not a PATCH endpoint.

Omitting fields risks resetting them to server defaults.

For IdP-driven sync at scale, SCIM 2.0 at https://{your-alteryx-server}/scim/v2 is the supported path, but it is gated behind both an Enterprise plan and an active SAML SSO configuration.

SCIM supports the full CRUD surface including group management, and integrates cleanly into an identity graph for continuous lifecycle sync.

Provision a new user via API

1. Obtain a bearer token via POST /oauth2/token with your Client ID and Client Secret.
2. POST /api/v3/users with firstName, lastName, email, and role in the request body.
3. Capture the returned user id for future reference.
4. Optionally POST /api/v3/usergroups/{groupId}/users to add the user to a relevant group.

Watch out for: If the server uses SAML authentication, the user account is created but the user must authenticate via the IdP on first login; no password is set via the API.

Deactivate a departed user

1. Obtain a bearer token.
2. GET /api/v3/users?search={email} to find the user's id.
3. DELETE /api/v3/users/{id} to deactivate the account.
4. Verify isActive is false by calling GET /api/v3/users/{id}.

Watch out for: DELETE deactivates, not permanently removes. The user still appears in the system and may still consume a license seat until an admin removes them from the Server UI.

Sync users from IdP using SCIM

1. Ensure SAML SSO is configured on Alteryx Server (Enterprise plan required).
2. In Alteryx Server admin UI, navigate to SAML/SCIM settings and generate a SCIM bearer token.
3. Configure your IdP (e.g., Okta, Azure AD) with the SCIM base URL (https://{server}/scim/v2) and the bearer token.
4. Map IdP user attributes to SCIM attributes (userName → email, givenName, familyName, active).
5. Enable provisioning features in the IdP: Create Users, Update User Attributes, Deactivate Users.
6. Test with a pilot user before enabling for all users.

Watch out for: SCIM provisioning will not work without SAML SSO active. If SSO is disabled or misconfigured, SCIM calls will fail. Group push behavior depends on IdP connector capabilities.

The DELETE-as-deactivation behavior is the most common integration trap: callers expecting hard deletion will find the user still present in GET /api/v3/users results and potentially still occupying a license seat. Any identity graph or HRIS sync that treats a 200 response from DELETE as confirmation of full removal will produce stale state.

A second trap is the PUT-only update model. Partial updates are not supported - a PATCH-style call pattern will either fail or silently overwrite fields with defaults depending on server version. Always retrieve the current user object first, mutate the required fields, and PUT the full payload back.

SCIM provisioning carries its own hard dependency: SAML SSO must be fully configured and active before the SCIM endpoint will accept any calls. Enabling SCIM before SSO is stable will produce authentication failures that are easy to misattribute to token or endpoint misconfiguration.

Verify SSO end-to-end with a test user before wiring up SCIM in any automated pipeline.