> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tight.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Obtain and use bearer tokens with the Tight API

## Get Started

The Tight API uses access tokens to authenticate requests. To get started, simply exchange your client credentials and a `userId` for an access token:

```bash theme={null}
curl -X POST https://sandbox.tight.com/v6/auth/token \
-u client_id:client_secret \
-d userId=your_userId
```

The Tight API will respond with your granted access token:

```json theme={null}
{
    "access_token": "<access_token>",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

This token can be used anywhere in the Tight API to access this user's data.

## Partner-level Authentication

The `userId` in the above request is optional. You can omit it to request a token that can access data across *all* of your users:

```bash theme={null}
curl -X POST https://sandbox.tight.com/v6/auth/token \
-u client_id:client_secret
```

See the [POST /token reference](/api-reference/oauth/token) for more information.

## Token Scopes

You can pass an optional `scope` field when requesting a token from `POST /v6/auth/token` to limit what the token can do:

* `read` gives read-only access
* `write` gives read and write access
* If omitted, `scope` defaults to `write`

For example, to request a read-only token:

```bash theme={null}
curl -X POST https://sandbox.tight.com/v6/auth/token \
-u client_id:client_secret \
-d userId=your_userId \
-d scope=read
```

## Using the Access Token

Include the returned token in the `Authorization` header of any request to the Tight API:

```bash theme={null}
curl --location --request POST 'https://sandbox.tight.com/v6/banks/transactions' \
-H 'Authorization: Bearer <access_token>'
```

The above request retrieves bank transactions available to the provided `access_token`.

## Authentication Scenarios

How the token was generated impacts what data the above request will return. For example, when using a token generated for a specific business owner (via their `userId`), the request will return bank transactions belonging to that user's company.

The following table outlines what data is accessible based on the `userId` provided:

| Authentication Type  | Data Accessible                         |
| -------------------- | --------------------------------------- |
| Business owner       | Only that company                       |
| Bookkeeper           | All companies the bookkeeper can access |
| None (Partner-level) | All companies                           |

<Note>How the token was generated impacts how the Tight API audits changes to entities modified using that token. See the [Audit Trail docs](/api-reference/audit-trail#editors) for more info.</Note>

## Token Renewal

Instead of tracking token expiration, generate a new token for each user session.
<Check>Tight Embedded Components automatically refresh tokens for you.</Check>