Sinch User Management API Guide

Auth method: OAuth 2.0 (client_credentials grant using Access Key ID and Access Key Secret) or HTTP Basic Auth with Access Key ID and Secret

Setup steps

1. Log in to the Sinch Customer Dashboard (dashboard.sinch.com).
2. Navigate to Settings > Access Keys and create a new Access Key.
3. Note the Key ID and Key Secret (secret shown only once).
4. For OAuth 2.0: POST to https://auth.sinch.com/oauth2/token with grant_type=client_credentials, client_id=, client_secret= to obtain a Bearer token.
5. Include the Bearer token in the Authorization header for subsequent API calls.

Required scopes

List members of a project

• Method: GET
• URL: https://us.api.sinch.com/projects/{projectId}/members
• Watch out for: Endpoint path and exact response schema not fully published; verify against current developer portal.

Request example

GET /projects/{projectId}/members
Authorization: Bearer <token>

Response example

{
  "members": [
    {"email":"user@example.com","role":"ADMIN","status":"ACTIVE"}
  ],
  "next_page_token": "abc123"
}

Invite a user to a project

• Method: POST
• URL: https://us.api.sinch.com/projects/{projectId}/members
• Watch out for: Invited users receive an email and must accept before status changes from PENDING to ACTIVE.

Request example

POST /projects/{projectId}/members
Authorization: Bearer <token>
{
  "email": "newuser@example.com",
  "role": "MEMBER"
}

Response example

{
  "email": "newuser@example.com",
  "role": "MEMBER",
  "status": "PENDING"
}

Update a project member's role

• Method: PATCH
• URL: https://us.api.sinch.com/projects/{projectId}/members/{userId}
• Watch out for: Only account OWNER or ADMIN roles can modify member roles.

Request example

PATCH /projects/{projectId}/members/{userId}
Authorization: Bearer <token>
{
  "role": "READONLY"
}

Response example

{
  "user_id": "usr_abc123",
  "role": "READONLY",
  "status": "ACTIVE"
}

Remove a member from a project

• Method: DELETE
• URL: https://us.api.sinch.com/projects/{projectId}/members/{userId}
• Watch out for: Removing a member does not delete the Sinch account; it only revokes project access.

Request example

DELETE /projects/{projectId}/members/{userId}
Authorization: Bearer <token>

Response example

HTTP 204 No Content

List Access Keys for a project

• Method: GET
• URL: https://us.api.sinch.com/projects/{projectId}/access-keys
• Watch out for: Key secrets are only returned at creation time and cannot be retrieved afterward.

Request example

GET /projects/{projectId}/access-keys
Authorization: Bearer <token>

Response example

{
  "access_keys": [
    {"key_id":"key_abc","display_name":"CI Key","created_at":"2024-01-01T00:00:00Z"}
  ]
}

Create an Access Key

• Method: POST
• URL: https://us.api.sinch.com/projects/{projectId}/access-keys
• Watch out for: Store key_secret immediately; it is not retrievable after this response.

Request example

POST /projects/{projectId}/access-keys
Authorization: Bearer <token>
{
  "display_name": "My Service Key"
}

Response example

{
  "key_id": "key_xyz",
  "key_secret": "s3cr3t",
  "display_name": "My Service Key"
}

Delete an Access Key

• Method: DELETE
• URL: https://us.api.sinch.com/projects/{projectId}/access-keys/{keyId}
• Watch out for: Deleting an active key immediately revokes all API calls using that key.

Request example

DELETE /projects/{projectId}/access-keys/{keyId}
Authorization: Bearer <token>

Response example

HTTP 204 No Content

Get OAuth 2.0 token

• Method: POST
• URL: https://auth.sinch.com/oauth2/token
• Watch out for: Token expiry is 3600 seconds; implement token refresh logic to avoid 401 errors mid-session.

Request example

POST /oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=<key_id>&client_secret=<key_secret>

Response example

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600
}

• Rate limits: Sinch does not publicly document specific rate limit values per endpoint in its developer docs. Rate limits are enforced but thresholds are not published.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate-limit headers or Retry-After behavior documented in official sources. Contact Sinch support for enterprise rate-limit details.

• Pagination method: token

• Default page size: 20

• Max page size: 100

• Pagination pointer: page_token

• Webhooks available: No

• Webhook notes: Sinch does not document account/user-management webhooks (e.g., user invited, role changed) in its official developer docs. Webhooks exist for communications events (SMS delivery, voice call status) but not for IAM events.

• Alternative event strategy: Poll the members list endpoint or use SCIM provisioning (Enterprise) with an IdP that supports push events.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (SSO prerequisite required)

• Endpoint: Connector-specific endpoint provided by Sinch upon Enterprise SSO setup; not a generic public URL

• Supported operations: Create user, Update user, Deactivate user, List users

Limitations:

• Requires SSO (Okta or Microsoft Entra ID) to be configured first
• SCIM endpoint URL is provisioned per-customer and not publicly documented
• Group push support not confirmed in official docs
• Only available on Enterprise plan; not available on pay-as-you-go or self-serve tiers

Three primary automation scenarios are supported by the documented API surface.

Onboard a team member: POST to /projects/{projectId}/members with email and role.

The invited user receives an email and must accept before status transitions from PENDING to ACTIVE.

There is no documented API to resend invitations;

use the dashboard for that edge case.

Rotate an Access Key: POST to /projects/{projectId}/access-keys to create a new key, capture key_secret immediately (it is never retrievable again), migrate all consumers, then DELETE the old key.

Deleting before migration causes immediate 401 failures across all dependent services.

Deprovision via SCIM (Enterprise only): Deactivate the user in Okta or Entra ID;

the IdP sends a SCIM PATCH (active=false) or DELETE to the Sinch SCIM endpoint.

The SCIM endpoint URL is customer-specific and provisioned by Sinch support - it cannot be self-configured via the dashboard.

Onboard a new team member to a Sinch project

1. Authenticate: POST to https://auth.sinch.com/oauth2/token with client_credentials to obtain Bearer token.
2. Invite user: POST to /projects/{projectId}/members with email and desired role.
3. User receives invitation email and accepts; status transitions from PENDING to ACTIVE.
4. Verify: GET /projects/{projectId}/members and confirm the user appears with ACTIVE status.

Watch out for: If the user does not accept the invitation, they remain PENDING and cannot access the project. There is no documented API to resend invitations; use the dashboard.

Rotate an API Access Key for a service account

1. Authenticate with an existing ADMIN-level Bearer token.
2. Create a new key: POST to /projects/{projectId}/access-keys with a display_name; store the returned key_secret immediately.
3. Update all services to use the new key_id and key_secret.
4. Delete the old key: DELETE /projects/{projectId}/access-keys/{oldKeyId}.
5. Confirm deletion: GET /projects/{projectId}/access-keys and verify old key is absent.

Watch out for: Deleting the old key before updating services will cause immediate 401 failures. Ensure all consumers are migrated first.

Deprovision a user via SCIM (Enterprise)

1. Ensure SSO and SCIM are configured in the Sinch Enterprise account with Okta or Entra ID.
2. In the IdP, deactivate or remove the user from the Sinch application assignment.
3. The IdP sends a SCIM PATCH (active=false) or DELETE to the Sinch SCIM endpoint.
4. Sinch deactivates the user, revoking project access.
5. Verify via the Sinch dashboard or GET /projects/{projectId}/members that the user status is SUSPENDED or removed.

Watch out for: SCIM endpoint URL is customer-specific and provided by Sinch support; it cannot be self-configured. SSO must be active or SCIM provisioning will not function.

Several non-obvious constraints create integration risk at scale. Pagination uses a page_token cursor with a default page size of 20 and a maximum of 100; callers must handle multi-page traversal to get a complete member list.

Rate limits are enforced but thresholds are not published in official documentation, and no Retry-After or rate-limit headers are returned - meaning backoff logic must be implemented defensively without guidance on safe retry intervals.

Exact endpoint paths for member management are not fully published in the public developer portal as of the research date; verify all paths against the latest API reference before shipping.

Additionally, removing a member from a project via DELETE does not delete the underlying Sinch account - the user retains their Sinch identity and may hold access to other projects, a gap that matters for thorough offboarding in an identity graph context.

SCIM group push support is not confirmed in official documentation, limiting IdP-driven role management to individual user operations only.