Taskade User Management API Guide

Auth method: OAuth 2.0 (Authorization Code flow) or Personal Access Token (Bearer)

Setup steps

1. Navigate to Taskade Settings → Integrations → API to create a Personal Access Token, or register an OAuth 2.0 application at https://developers.taskade.com/.
2. For OAuth 2.0: set redirect_uri, request authorization at https://www.taskade.com/oauth/authorize with desired scopes.
3. Exchange the authorization code for an access token at https://www.taskade.com/oauth/token.
4. Include the token in all API requests as: Authorization: Bearer .

Required scopes

List workspace members

• Method: GET
• URL: https://www.taskade.com/api/v1/workspaces/{workspaceId}/members
• Watch out for: Requires read:workspace scope. Paginated via cursor; iterate until cursor is null.

Request example

GET /api/v1/workspaces/ws_abc123/members
Authorization: Bearer <token>

Response example

{
  "items": [
    {"id":"usr_1","email":"alice@example.com","role":"admin"}
  ],
  "cursor": "next_cursor_token"
}

Get workspace member

• Method: GET
• URL: https://www.taskade.com/api/v1/workspaces/{workspaceId}/members/{memberId}
• Watch out for: Returns 404 if the user is not a member of the specified workspace.

Request example

GET /api/v1/workspaces/ws_abc123/members/usr_1
Authorization: Bearer <token>

Response example

{
  "id": "usr_1",
  "email": "alice@example.com",
  "displayName": "Alice",
  "role": "admin"
}

Invite member to workspace

• Method: POST
• URL: https://www.taskade.com/api/v1/workspaces/{workspaceId}/members
• Watch out for: Requires write:workspace scope. Sends an email invitation; user is not active until they accept.

Request example

POST /api/v1/workspaces/ws_abc123/members
Authorization: Bearer <token>
Content-Type: application/json

{"email":"bob@example.com","role":"member"}

Response example

{
  "id": "usr_2",
  "email": "bob@example.com",
  "role": "member",
  "status": "invited"
}

Remove member from workspace

• Method: DELETE
• URL: https://www.taskade.com/api/v1/workspaces/{workspaceId}/members/{memberId}
• Watch out for: Cannot remove the workspace owner. Requires write:workspace scope.

Request example

DELETE /api/v1/workspaces/ws_abc123/members/usr_2
Authorization: Bearer <token>

Response example

{
  "success": true
}

Update member role

• Method: PATCH
• URL: https://www.taskade.com/api/v1/workspaces/{workspaceId}/members/{memberId}
• Watch out for: Only role updates are supported via this endpoint; email and ID are immutable.

Request example

PATCH /api/v1/workspaces/ws_abc123/members/usr_1
Authorization: Bearer <token>
Content-Type: application/json

{"role":"member"}

Response example

{
  "id": "usr_1",
  "role": "member"
}

List project members

• Method: GET
• URL: https://www.taskade.com/api/v1/projects/{projectId}/members
• Watch out for: Requires read:project scope. Project membership is separate from workspace membership.

Request example

GET /api/v1/projects/proj_xyz/members
Authorization: Bearer <token>

Response example

{
  "items": [
    {"id":"usr_1","email":"alice@example.com","role":"editor"}
  ]
}

Get current authenticated user (me)

• Method: GET
• URL: https://www.taskade.com/api/v1/me
• Watch out for: Returns the identity of the token owner, not an arbitrary user.

Request example

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

Response example

{
  "id": "usr_1",
  "email": "alice@example.com",
  "displayName": "Alice",
  "avatarUrl": "https://..."
}

List workspaces

• Method: GET
• URL: https://www.taskade.com/api/v1/workspaces
• Watch out for: Returns only workspaces accessible to the authenticated token owner.

Request example

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

Response example

{
  "items": [
    {"id":"ws_abc123","name":"Acme Corp"}
  ]
}

• Rate limits: Rate limits are not explicitly documented in publicly available official sources as of the research date.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No specific rate-limit tiers, headers, or Retry-After behavior are documented in official sources. Contact Taskade support for enterprise-level rate limit details.

• Pagination method: cursor

• Default page size: 20

• Max page size: 100

• Pagination pointer: cursor

• Webhooks available: No

• Webhook notes: Taskade's official developer documentation does not document outbound webhooks for user-management events as of the research date.

• Alternative event strategy: Poll the /workspaces/{workspaceId}/members endpoint periodically to detect membership changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://www.taskade.com/scim/v2

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PUT /Users/{id}, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, POST /Groups, PATCH /Groups/{id}, DELETE /Groups/{id}

Limitations:

• Requires Enterprise plan.
• SSO (SAML 2.0) must be configured before enabling SCIM provisioning.
• Supported IdPs documented: Okta, Microsoft Entra ID (Azure AD).
• Google Workspace and OneLogin are not listed as supported IdPs in official docs.
• SCIM bearer token is generated within Taskade's SSO/SCIM settings; it is not the same as the REST API OAuth token.

Three primary automation scenarios are supported by the API surface.

First, SCIM-based provisioning (Enterprise only): configure Okta or Entra ID with the SCIM base URL and a dedicated bearer token generated in Taskade's SSO/SCIM settings;

SCIM will silently fail if SAML 2.0 SSO is not fully active first.

Second, REST-based workspace invitation: POST to /workspaces/{workspaceId}/members with write:workspace scope;

the invited user's status remains invited until they accept the email, so automations must not assume immediate active status.

Third, REST-based deprovisioning: DELETE must be called per-workspace;

there is no global user-deactivation endpoint in the REST API, making SCIM the only scalable offboarding path for Enterprise accounts.

Workspace membership and project membership are distinct objects - adding a user to a workspace does not grant access to individual projects.

Provision a new employee via SCIM (Enterprise)

1. Ensure SSO (SAML 2.0) is configured in Taskade Settings → Security.
2. Generate a SCIM bearer token in Taskade Settings → Security → SCIM.
3. Configure your IdP (Okta or Entra ID) with the SCIM base URL https://www.taskade.com/scim/v2 and the bearer token.
4. Assign the user to the Taskade application in your IdP; the IdP sends a POST /Users request to Taskade.
5. Taskade creates the user account and sends an activation email if required.

Watch out for: SCIM provisioning will silently fail if SSO is not active. Verify SSO login works before enabling SCIM.

Invite a member to a workspace via REST API

1. Obtain an OAuth 2.0 access token with write:workspace scope.
2. Call GET /api/v1/workspaces to retrieve the target workspaceId.
3. POST /api/v1/workspaces/{workspaceId}/members with body {"email":"user@example.com","role":"member"}.
4. The user receives an email invitation; their status is 'invited' until accepted.
5. Poll GET /api/v1/workspaces/{workspaceId}/members to confirm active status.

Watch out for: The invited user must accept the email invitation before they appear as an active member. Automations depending on immediate active status will need to account for this delay.

Deprovision a departing employee

1. Via SCIM (Enterprise): Unassign the user from the Taskade app in your IdP; the IdP sends DELETE /Users/{id} or PATCH to set active=false.
2. Via REST API: Call DELETE /api/v1/workspaces/{workspaceId}/members/{memberId} for each workspace the user belongs to.
3. Verify removal by calling GET /api/v1/workspaces/{workspaceId}/members and confirming the user is absent.

Watch out for: REST API removal must be performed per-workspace; there is no single global user-deactivation endpoint in the REST API. SCIM handles this globally when configured.

The most significant integration trap is the SCIM-SSO dependency: enabling SCIM without a fully configured and tested SAML 2.0 SSO connection will cause provisioning to fail without a clear error surfaced to the IdP.

A second trap is token confusion: the SCIM bearer token is generated separately from OAuth 2.0 REST tokens and cannot be substituted. For identity graph construction, the user object exposes id, email, displayName, role, avatarUrl, and createdAt - there is no lastActiveAt or equivalent field documented, which limits inactive-user detection to manual member-list audits.

Google Workspace and OneLogin are not listed as supported SCIM IdPs in official documentation; only Okta and Microsoft Entra ID are confirmed.