Sinch Agentic Tools
Sinch SDKs
Sinch CLI & Functions
An access key is the credential the Sinch APIs use to authenticate. Each key is a pair:
- The Key ID is a public identifier (also used as the
client_id). It's safe to log and share internally. - The Key Secret is the private half (the
client_secret). Treat it like a password.
You don't send the access key directly on API requests. Instead, you exchange it for a short-lived OAuth2 access token (see OAuth2 access tokens) and send that token as a Bearer credential.
Access keys are scoped to a single project. A key can only act on resources in the project it was created in, and a project can hold a maximum of 10 access keys.
This also applies to any of the project’s subprojects – a key created in a project can also act on resources within any of that project’s subprojects.
Once generated, the access token includes a lifetime field indicating its validity period (which is configured to expire after one hour).
- Sign in to the Sinch Build Dashboard.
- Use the project switcher to select the project the key should belong to.
- Open Settings → Access keys.
- Select Create access key.
- Enter a display name describing what the key is for (e.g.
numbers-prod-worker). A display name is required. - Click Confirm, then copy the Key ID and Key Secret.
Copy your Key Secret now! The Key Secret is only viewable at the time of initial creation. Copy it immediately and store it somewhere secure. If you lose it, you'll need to create a new key pair. The Key ID can always be looked up later.
Pass the Key ID and Key Secret to the OAuth2 token endpoint to get a bearer token:
curl https://auth.sinch.com/oauth2/token \
-X POST \
-d "grant_type=client_credentials" \
-u "YOUR_key_id:YOUR_key_secret"| Placeholder | Description |
|---|---|
| YOUR_key_id | The access key's public identifier. |
| YOUR_key_secret | The access key's secret half. |
The response contains an access_token you then send on API calls. Full walkthrough in OAuth2 access tokens.
Rotate keys on a schedule, and immediately if a secret may have leaked. To rotate without downtime:
- Create a second access key in the same project.
- Deploy the new Key ID / Key Secret to your applications.
- Verify traffic is authenticating with the new key.
- Delete the old key from the dashboard.
Deleting a key stops new tokens from being issued for it. An access token that was already issued may remain authenticated for a short period after the key is deleted, but it is no longer authorized to access the resource. As a result, requests using that token may receive 403 Forbidden rather than 401 Unauthorized. Revocation may therefore not take effect instantaneously.
It is possible to delete the very key your own application is using. If you delete a project's in-use key, you'll need to create a replacement in the dashboard before you can authenticate again. Always create the new key before deleting the old one.
You can also create, list, and delete access keys with the Access Keys Management API instead of the dashboard. In order to call the endpoint your first key must be created in the dashboard, and then used to create subsequent keys:
curl https://account.api.sinch.com/v1/projects/YOUR_project_id/accessKeys \
-X POST \
-H "Authorization: Bearer YOUR_access_token"| Placeholder | Description |
|---|---|
| YOUR_project_id | The project the new key should belong to. |
| YOUR_access_token | A bearer token from an existing key in that project (see OAuth2 access tokens). |
The response returns the new accessKeyId and secret. As in the dashboard, the secret is shown only this once.
- Never commit a Key Secret to source control or ship it in client-side or mobile code. These credentials belong on your backend only.
- Inject secrets through environment variables or a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, etc.).
- Create a separate key per project and per environment so you can revoke one without affecting the others.
- Apply least privilege: create keys in the narrowest project that needs them.
