Tines User Management API Guide

Auth method: API token (Bearer token in Authorization header)

Setup steps

1. Log in to your Tines tenant as an admin.
2. Navigate to your user profile and select 'API Tokens'.
3. Generate a new API token and copy the value.
4. Include the token in all API requests as: Authorization: Bearer

List users

• Method: GET
• URL: https://<tenant>.tines.com/api/v1/users
• Watch out for: Pagination uses page/per_page query params; max per_page is 500.

Request example

GET /api/v1/users?page=1&per_page=20
Authorization: Bearer <token>

Response example

{
  "users": [{"id": 1, "email": "user@example.com", "first_name": "Jane", "last_name": "Doe"}],
  "meta": {"current_page": 1, "total_pages": 3}
}

Get user

• Method: GET
• URL: https://<tenant>.tines.com/api/v1/users/{user_id}
• Watch out for: Returns 404 if user_id does not exist in the tenant.

Request example

GET /api/v1/users/42
Authorization: Bearer <token>

Response example

{
  "id": 42,
  "email": "user@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "member"
}

Create user

• Method: POST
• URL: https://<tenant>.tines.com/api/v1/users
• Watch out for: An invitation email is sent to the new user upon creation.

Request example

POST /api/v1/users
Authorization: Bearer <token>
Content-Type: application/json
{"email":"new@example.com","first_name":"John","last_name":"Smith","role":"member"}

Response example

{
  "id": 99,
  "email": "new@example.com",
  "first_name": "John",
  "last_name": "Smith",
  "role": "member"
}

Update user

• Method: PUT
• URL: https://<tenant>.tines.com/api/v1/users/{user_id}
• Watch out for: Only fields included in the request body are updated.

Request example

PUT /api/v1/users/99
Authorization: Bearer <token>
Content-Type: application/json
{"role":"admin"}

Response example

{
  "id": 99,
  "email": "new@example.com",
  "role": "admin"
}

Delete user

• Method: DELETE
• URL: https://<tenant>.tines.com/api/v1/users/{user_id}
• Watch out for: Deletion is permanent; consider deactivating via SCIM for reversible deprovisioning.

Request example

DELETE /api/v1/users/99
Authorization: Bearer <token>

Response example

HTTP 204 No Content

List teams

• Method: GET
• URL: https://<tenant>.tines.com/api/v1/teams
• Watch out for: Team membership is managed separately via team-specific endpoints.

Request example

GET /api/v1/teams
Authorization: Bearer <token>

Response example

{
  "teams": [{"id": 5, "name": "Security Ops"}]
}

Add user to team

• Method: POST
• URL: https://<tenant>.tines.com/api/v1/teams/{team_id}/memberships
• Watch out for: User must already exist in the tenant before being added to a team.

Request example

POST /api/v1/teams/5/memberships
Authorization: Bearer <token>
Content-Type: application/json
{"user_id": 99}

Response example

{
  "team_id": 5,
  "user_id": 99
}

Remove user from team

• Method: DELETE
• URL: https://<tenant>.tines.com/api/v1/teams/{team_id}/memberships/{user_id}
• Watch out for: Does not delete the user from the tenant, only removes team membership.

Request example

DELETE /api/v1/teams/5/memberships/99
Authorization: Bearer <token>

Response example

HTTP 204 No Content

• Rate limits: Tines does not publicly document specific rate limit thresholds or per-plan tiers in its official docs as of the research date.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented in official sources.

• Pagination method: offset

• Default page size: 20

• Max page size: 500

• Pagination pointer: per_page / page

• Webhooks available: No

• Webhook notes: Tines does not expose outbound webhook events for user-management lifecycle events (create, update, delete) via its API. Tines itself is a workflow automation platform that receives webhooks as triggers for stories.

• Alternative event strategy: Use Tines stories (workflows) with scheduled or event-driven triggers to poll the Users API and react to changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://.tines.com/scim/v2

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

Limitations:

• Requires Enterprise plan.
• SSO must be configured and enabled before SCIM provisioning can be activated.
• SCIM token is generated separately from standard API tokens within the admin SSO settings.
• IdP-specific connector setup (e.g., Okta, Azure AD) is required on the IdP side; Tines does not publish pre-built IdP app catalog entries in its docs.

Three integration patterns cover the majority of use cases.

For bulk onboarding, POST to /api/v1/users per user with email, first_name, last_name, and role, capture the returned id, then POST to /api/v1/teams/{team_id}/memberships

note that each user creation triggers an invitation email, so time bulk runs accordingly.

For deprovisioning on Enterprise, the preferred path is SCIM PATCH with active=false via the IdP rather than a REST DELETE, which is irreversible and does not support rollback.

For tenant audits, paginate GET /api/v1/users?page=1&per_page=500, iterate until meta.total_pages is exhausted, and extract id, email, role, and created_at for downstream logging.

Bulk onboard new team members via REST API

1. Authenticate with an admin-scoped Bearer token.
2. POST /api/v1/users for each new user with email, first_name, last_name, and role.
3. Capture the returned user id for each created user.
4. POST /api/v1/teams/{team_id}/memberships with each user_id to assign team membership.

Watch out for: Each POST /users triggers an invitation email; ensure users are ready to receive it before bulk creation.

Deprovision a user via SCIM (Enterprise)

1. Ensure SSO and SCIM are configured in Tines admin settings.
2. From the IdP (e.g., Okta), unassign the user from the Tines SCIM application.
3. The IdP sends a PATCH /scim/v2/Users/{id} with active=false to Tines.
4. Tines deactivates the user account without permanently deleting it.

Watch out for: SCIM deprovisioning only deactivates the account; a separate DELETE may be needed for full removal depending on compliance requirements.

Audit all users in a tenant

1. GET /api/v1/users?page=1&per_page=500 with admin Bearer token.
2. Check meta.total_pages in the response to determine if additional pages exist.
3. Iterate through all pages by incrementing the page parameter until all users are retrieved.
4. Process the users array to extract id, email, role, and created_at fields for audit logging.

Watch out for: per_page maximum is 500; large tenants will require multiple paginated requests.

The primary API trap is conflating deprovisioning methods. A REST DELETE on /api/v1/users/{user_id} is permanent with no soft-disable state; if reversibility matters for compliance, use SCIM PATCH (active=false) instead - but that path requires Enterprise and a fully configured SSO setup as a hard prerequisite.

A second trap: rate limits are not publicly documented, so any integration that does not implement exponential backoff is operating without a safety net.

A third: the base URL is tenant-specific (.tines.com), and there are no outbound webhook events for user lifecycle changes - polling the Users API via scheduled calls is the only supported pattern for change detection.

Teams integrating Tines into a broader identity graph via an MCP server with 60+ deep IT/identity integrations should account for the SSO-first SCIM dependency when modeling provisioning state.