> ## 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

The Tight API is a RESTful API that follows the standard OAuth 2.0 protocol, accepting JSON payloads and returning JSON responses. Tight supports the use of user-level authorization (the primary use case for most implementations) as well as partner-level authorization (for special use cases, described below).

## User-level Authorization

You can use the Bearer OAuth 2.0 protocol that your development team is likely already familiar with to make API requests on behalf of users. Once you have [registered your user](/v5.0/getting-started/quickstart/user-creation#1-registering-a-user) with the Tight API, you will receive an OAuth 2.0 `access_token`, which you should store in your own database and associate with your user.

Per OAuth 2.0 protocols, all subsequent API requests on behalf of your user should include the user's `access_token` in the request headers.

```curl theme={null}
curl \
  --request GET \
  --url https://sandbox.hurdlr.com/rest/v5/taxes/estimates \
  --header 'Authorization: Bearer ${access_token}' \
  --header 'Content-Type: application/json' \
```

## Partner-level Authorization

This Basic Authentication protocol allows partners to access and edit user data as the partner instead of as the user, which impacts how the Tight API displays the [Audit Trail](/v5.0/getting-started/api-patterns/webhooks) for these revisions. Instead of providing an `access_token`, you can use your `client_id` and `client_secret` in the request, along with the `userId` of the user from your DB.

Per the OAuth 2.0 standard, you will need to encode your `client_id` and `client_secret` using [base64](https://en.wikipedia.org/wiki/Base64). Combine the two values separated by a colon to create a string like this: `client_id:client_secret`. Then, pass this string into your preferred base64 encoder to produce an encoded string. Per OAuth 2.0 protocols, all subsequent partner-level API requests to manipulate a specific user should include this encoded string in the request headers.

```curl theme={null}
curl \
  --request GET \
  --url https://sandbox.hurdlr.com/rest/v5/taxes/estimates \
  --header 'Authorization: Basic ${base64_encoded_string}' \
  --header 'userId: ${user_id}'\
  --header 'Content-Type: application/json' \
```