# Authentication methods

For credentials specific to the SMS, Voice, or Verification APIs, see the [Product-specific credentials](#product-specific-credentials) section at the end of this page.

Note:
You create and manage all of these credentials yourself in the Sinch Build Dashboard.

### OAuth2 access tokens (SinchAPIs)

This is the modern, recommended path and the ones most Sinch APIs use.

1. Create an access key in your project. You get a Key ID and a Key Secret. See Access keys.
2. Exchange the key for a short-lived OAuth2 bearer token using the client credentials grant. See OAuth2 access tokens.
3. Send the token on every request:

```shell
curl https://numbers.api.sinch.com/v1/projects/YOUR_project_id/availableNumbers \
-H "Authorization: Bearer YOUR_access_token"
```


Tip:
Tokens are short-lived. Cache a token and reuse it until it expires rather than requesting a new one per call. Details in [OAuth2 access tokens](/docs/identity-access-management/authenticate/oauth2).

## Product-specific credentials

The following authentication methods apply to specific Sinch products.

### SMS: Service Plan ID + API token

The SMS API authenticates with a Service Plan ID and an API token, both created automatically when you set up SMS in the dashboard.

```shell
curl https://us.sms.api.sinch.com/xms/v1/YOUR_service_plan_id/batches \
  -H "Authorization: Bearer YOUR_api_token" \
  -H "Content-Type: application/json"
```

| Placeholder | Description |
|  --- | --- |
| `YOUR_service_plan_id` | Identifies your SMS service plan. Find it in the dashboard under SMS. |
| `YOUR_api_token` | The token used to authenticate SMS calls. Listed alongside your Service Plan ID. |


Note:
SMS uses regional hosts (for example `us.` or `eu.`). Use the host that matches the region where your service plan was created.

### Voice & Verification: application key + secret

The Voice API and the classic Verification API authenticate at the application level using an application key and application secret. They support HTTP Basic authentication and a signed-request scheme for higher security.

```shell
curl https://calling.api.sinch.com/calling/v1/callouts \
  -u "YOUR_application_key:YOUR_application_secret" \
  -H "Content-Type: application/json"
```

| Placeholder | Description |
|  --- | --- |
| `YOUR_application_key` | Your app's key, found in the dashboard under the app's settings. |
| `YOUR_application_secret` | Your app's secret. Treat it like a password. |


## Keep credentials safe

Whichever method you use, the same rules apply:

- Never commit secrets to source control or expose them in client-side code.
- Store secrets in a secrets manager or environment variables.
- Rotate credentials periodically and immediately if one may be exposed.
- Scope access keys to the narrowest project that needs them.


See [Access keys](/docs/identity-access-management/access/access-keys) for rotation and storage guidance.