# Authentication (/standards/authentication)



The Vizit Public API uses machine-to-machine authentication. Vizit provisions credentials for your organization, you exchange those credentials for a short-lived access token, and you send that token as a Bearer token on protected `/v1/**` requests.

## Overview [#overview]

Authentication follows the OAuth 2.0 client credentials pattern:

1. Vizit provides a `client_id` and `client_secret` for your organization and environment.
2. Your backend exchanges those credentials at `POST /auth/token`.
3. The API returns a Bearer access token.
4. Your integration sends `Authorization: Bearer <access_token>` on subsequent API requests.

The token endpoint does not require a Bearer token. Protected resource endpoints do.

The token request body must include `organization`, the Auth0 organization ID Vizit issues during onboarding, alongside `client_id`, `client_secret`, `grant_type`, and `audience`. The `audience` is always `https://ext.vizit.com`.

```json
{
  "client_id": "<your_client_id>",
  "client_secret": "<your_client_secret>",
  "audience": "https://ext.vizit.com",
  "grant_type": "client_credentials",
  "organization": "<your_organization_id>"
}
```

## Environments [#environments]

Use the base URL for the environment Vizit assigned to your integration:

| Environment          | Base URL                     |
| -------------------- | ---------------------------- |
| Production           | `https://ext.vizit.com`      |
| Development (`dev1`) | `https://dev1.ext.vizit.com` |
| Development (`dev2`) | `https://dev2.ext.vizit.com` |
| Development (`dev3`) | `https://dev3.ext.vizit.com` |
| Development (`dev4`) | `https://dev4.ext.vizit.com` |
| Development (`dev5`) | `https://dev5.ext.vizit.com` |

Credentials are environment-specific: use production credentials only against production and dev1 credentials only against dev1.

The API audience remains `https://ext.vizit.com` across environments.

## Token Lifetime [#token-lifetime]

Access tokens are valid for the number of seconds returned in the token response's expires\_in value (for example, 86400 seconds, or 24 hours).

* Cache the token until it expires instead of requesting a new one for every API call.
* If a cached token expires or you receive a `401 Unauthorized`, request a fresh token and retry once.

## Security Notes [#security-notes]

* Store `client_secret` only in secure server-side systems such as your backend or a secrets manager.
* Do not embed machine-to-machine credentials in browser apps, mobile apps, or any distributed client.
* Treat the `client_secret` as a long-lived secret and the access token as a short-lived credential.

## API Reference [#api-reference]

The exact `POST /auth/token` request body, response schema, and examples live in the API reference:

* [Obtain an access token](/api/authentication/createToken)