Authentication

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:

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:

{
    "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:

curl -X POST https://sandbox.tight.com/v6/auth/token \
-u client_id:client_secret

See the POST /token reference for more information.

Bookkeeper Authentication

Passing the userId of a bookkeeper returns a token that can access every company that bookkeeper is permitted to work on. To scope a bookkeeper’s token to a single company, add the apiCompanyId parameter alongside the bookkeeper’s userId:

curl -X POST https://sandbox.tight.com/v6/auth/token \
-u client_id:client_secret \
-d userId=bookkeeper_userId \
-d apiCompanyId=company_userId

The resulting token acts as that bookkeeper working on behalf of the specified company, so requests return only that company’s data and changes are audited to the bookkeeper. This is the recommended approach when a bookkeeper on your platform performs operations for one company at a time, rather than reusing a partner-level token.

apiCompanyId requires userId to be the ID of a bookkeeper who can access the given company.

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:

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:

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
Bookkeeper scoped to a company	Only that company
None (Partner-level)	All companies

How the token was generated impacts how the Tight API audits changes to entities modified using that token. See the Audit Trail docs for more info.

Token Renewal

Instead of tracking token expiration, generate a new token for each user session.

Tight Embedded Components automatically refresh tokens for you.

Patterns

Reference

Get Started

Partner-level Authentication

Bookkeeper Authentication

Token Scopes

Using the Access Token

Authentication Scenarios

Token Renewal

​Get Started

​Partner-level Authentication

​Bookkeeper Authentication

​Token Scopes

​Using the Access Token

​Authentication Scenarios

​Token Renewal

Get Started

Partner-level Authentication

Bookkeeper Authentication

Token Scopes

Using the Access Token

Authentication Scenarios

Token Renewal