Targetprocess User Management API Guide

Auth method: API Access Token (Bearer) or Basic Auth (username:password). Token-based auth is recommended.

Setup steps

1. Log in to your Targetprocess account.
2. Navigate to your user profile > Settings > Access Tokens.
3. Generate a new Access Token and copy it.
4. Pass the token as a query parameter: ?access_token={token}, or as an Authorization header: 'Authorization: Bearer {token}'.
5. Alternatively, use HTTP Basic Auth with username and password (less recommended for automation).

List Users

• Method: GET
• URL: https://{account}.tpondemand.com/api/v1/Users?format=json&take=25&skip=0
• Watch out for: Deleted users are excluded by default. Use ?where=(DeleteDate is null) or include IsActive filter explicitly.

Request example

GET /api/v1/Users?format=json&take=25&skip=0&access_token={token}

Response example

{
  "Items": [
    {"Id":1,"FirstName":"Jane","LastName":"Doe","Email":"jane@example.com","IsActive":true}
  ],
  "Next":"..."
}

Get User by ID

• Method: GET
• URL: https://{account}.tpondemand.com/api/v1/Users/{id}?format=json
• Watch out for: Use the ?include=[Fields] parameter to retrieve non-default fields such as Teams or Role.

Request example

GET /api/v1/Users/42?format=json&access_token={token}

Response example

{
  "Id":42,
  "FirstName":"Jane",
  "LastName":"Doe",
  "Email":"jane@example.com",
  "Login":"jane.doe",
  "IsActive":true,
  "Role":{"Id":3,"Name":"Developer"}
}

Create User

• Method: POST
• URL: https://{account}.tpondemand.com/api/v1/Users?format=json
• Watch out for: Password is required for non-SSO accounts. For SSO environments with JIT provisioning, users are created on first login and manual creation may conflict.

Request example

POST /api/v1/Users?format=json
Content-Type: application/json
{
  "FirstName":"John",
  "LastName":"Smith",
  "Email":"john@example.com",
  "Login":"john.smith",
  "Password":"SecurePass1!"
}

Response example

{
  "Id":99,
  "FirstName":"John",
  "LastName":"Smith",
  "Email":"john@example.com",
  "IsActive":true
}

Update User

• Method: POST
• URL: https://{account}.tpondemand.com/api/v1/Users/{id}?format=json
• Watch out for: Targetprocess REST API v1 uses POST (not PUT/PATCH) for updates to existing entities. Include only fields to be changed.

Request example

POST /api/v1/Users/99?format=json
Content-Type: application/json
{
  "FirstName":"Jonathan",
  "IsActive":false
}

Response example

{
  "Id":99,
  "FirstName":"Jonathan",
  "IsActive":false
}

Delete User

• Method: DELETE
• URL: https://{account}.tpondemand.com/api/v1/Users/{id}?format=json
• Watch out for: Deletion is a soft delete; the user record is retained with a DeleteDate set. Deleted users cannot log in but data is preserved.

Request example

DELETE /api/v1/Users/99?format=json&access_token={token}

Response example

HTTP 200 OK
{}

Filter Users by Email

• Method: GET
• URL: https://{account}.tpondemand.com/api/v1/Users?where=(Email eq 'jane@example.com')&format=json
• Watch out for: The where clause uses Targetprocess query language syntax, not OData. String values must be single-quoted.

Request example

GET /api/v1/Users?where=(Email+eq+'jane@example.com')&format=json&access_token={token}

Response example

{
  "Items": [
    {"Id":42,"Email":"jane@example.com","IsActive":true}
  ]
}

List Roles

• Method: GET
• URL: https://{account}.tpondemand.com/api/v1/Roles?format=json
• Watch out for: Role Ids are needed when assigning roles during user create/update. Fetch this list to map role names to Ids.

Request example

GET /api/v1/Roles?format=json&access_token={token}

Response example

{
  "Items": [
    {"Id":1,"Name":"Administrator"},
    {"Id":3,"Name":"Developer"}
  ]
}

List Teams

• Method: GET
• URL: https://{account}.tpondemand.com/api/v1/Teams?format=json
• Watch out for: Team membership is managed via TeamMembers entity, not directly on the User object.

Request example

GET /api/v1/Teams?format=json&access_token={token}

Response example

{
  "Items": [
    {"Id":10,"Name":"Alpha Team"},
    {"Id":11,"Name":"Beta Team"}
  ]
}

• Rate limits: Targetprocess does not publicly document specific rate limits or request quotas in its official API docs. No explicit rate-limit tiers are published.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate-limit documentation found. Practical limits may be enforced server-side without explicit header signaling.

• Pagination method: offset

• Default page size: 25

• Max page size: 1000

• Pagination pointer: take / skip

• Webhooks available: No

• Webhook notes: Targetprocess does not expose a native outbound webhook system for user lifecycle events in its official documentation. Event-driven integrations typically rely on polling the REST API.

• Alternative event strategy: Poll GET /api/v1/Users with a ModifyDate filter to detect changes. Targetprocess supports Zapier and other iPaaS connectors for event-driven workflows.

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• No native SCIM 2.0 support documented by Targetprocess/IBM Apptio.
• User provisioning via SSO uses SAML 2.0 with Just-In-Time (JIT) provisioning - users are created on first login.
• No SCIM connector endpoint is published; third-party SCIM bridges are not officially supported.
• Manual user management or REST API scripting is required for bulk provisioning outside of JIT.

Three automation scenarios are well-supported by the API.

First, bulk provisioning from an HR system: fetch Role IDs via GET /api/v1/Roles, then POST /api/v1/Users per user with FirstName, LastName, Email, Login, Password, and Role.Id;

follow up with POST /api/v1/TeamMembers for team assignments.

Caveat: if SAML JIT is active, API-created users may conflict with IdP-asserted records if Login or Email values diverge.

Second, offboarding: locate the user by email via the where filter, then POST /api/v1/Users/{id} with {"IsActive": false};

this revokes login without deleting data.

Third, role sync: poll GET /api/v1/Users?where=(ModifyDate gt '{timestamp}') to detect changes, then update roles via POST /api/v1/Users/{id} with the target Role.Id.

No webhooks exist;

polling interval directly determines sync latency.

Bulk-provision users from an HR system

1. Authenticate using an admin Access Token.
2. GET /api/v1/Roles to retrieve Role Id mappings.
3. For each user in the HR export, POST /api/v1/Users with FirstName, LastName, Email, Login, Password, and Role.Id.
4. Store the returned Id for each created user for future updates.
5. Optionally, POST to /api/v1/TeamMembers to assign users to teams using the stored User Id and target Team Id.

Watch out for: If the account uses SAML SSO with JIT, creating users via API before their first SSO login may cause duplicate or conflicting records if Login/Email values differ from IdP assertions.

Deactivate departed employees

1. GET /api/v1/Users?where=(Email eq '{email}')&format=json to locate the user by email.
2. Extract the user's Id from the response.
3. POST /api/v1/Users/{id} with body {"IsActive": false} to deactivate the account.
4. Verify by GET /api/v1/Users/{id} and confirm IsActive is false.

Watch out for: Setting IsActive=false prevents login but does not delete the user or their data. Use DELETE /api/v1/Users/{id} for a soft delete if full removal is needed.

Sync user role changes from an identity source

1. GET /api/v1/Roles to build a name-to-Id map.
2. GET /api/v1/Users?where=(ModifyDate gt '{last_sync_timestamp}') to find recently modified users.
3. For each user requiring a role change, POST /api/v1/Users/{id} with body {"Role": {"Id": {newRoleId}}}.
4. Update last_sync_timestamp to current time for the next polling cycle.

Watch out for: ModifyDate filtering requires ISO 8601 format and correct URL encoding. There are no webhooks, so polling frequency determines sync latency.

Several non-obvious behaviors create integration risk. The API uses POST for both create and update - there is no PUT or PATCH verb; sending a POST to /Users/{id} updates the existing record.

DELETE is a soft delete only: DeleteDate is set and the record is retained, so active-user queries must explicitly filter on IsActive eq true or DeleteDate is null to avoid stale results. Non-default fields including Teams and Role details require explicit ?include=[FieldName] parameters; omitting them returns a partial object silently.

The where clause uses Targetprocess's own query language - not OData or SQL - and syntax errors return a 400 with minimal diagnostic detail.

For teams building an identity graph across their SaaS stack, the absence of SCIM and webhooks means Targetprocess user state must be derived entirely from REST polling, with ModifyDate and IsActive as the primary signals for change detection. Pagination tops out at take=1000; large accounts require multiple offset pages with take/skip parameters.