User Creation

The first step to consuming any of the Tight API products is to register your user with the Tight API. Per OAuth 2.0 protocol, this request should contain your client_id and client_secret. Subsequently, this API call should be invoked from your server, to protect your API credentials from being exposed on the client-side. The response will contain an OAuth 2.0 access_token, which should be added to your request headers (per the OAuth 2.0 protocol) for all subsequent API requests on behalf of this user.

1. Registering a user

The Tight API’s endpoint for registering a user contains a variety of input parameters for more personalized functionality:

Field	Description	Format
email	Your user’s business’s email, if applicable. Useful if your integration will be utilizing Tight’s Customizable User Interface or Tight’s Invoicing API .	Any valid email string
bizName	Your user’s business’s name, if applicable. Useful if your integration will be utilizing Tight’s Customizable User Interface or Tight’s Invoicing API.	Any string
bizType	Your user’s business type, if applicable. Useful if your integration will be utilizing the Business-specific Deduction Finder or the Customizable User Interface.	Must be one of the following: “DRIVER”, “REAL_ESTATE_AGENT”, “INSURANCE_AGENT”, “FREELANCER”, “HOST”, “RETAIL”, “E_COMMERCE”, “SALES”, “CONSULTANT”, or “OTHER”
entityType	Your user’s entity/formation type	Must be one of the following: “SOLE_PROPRIETORSHIP”, “LLP”, “LLC”, “S_CORP”, or “C_CORP”
accountingMethod	Your user’s preferred accounting method	Must be one of the following: “CASH” or “ACCRUAL”
userRole	Your user’s role, i.e. what level of access they should have to their data. Useful if your integration will be utilizing the Customizable User Interface .	Must be one of the following: “OWNER” or “READ_ONLY”
availableFeatures	Your user’s features that they should have access to.	Bitmap of booleans
language	Your user’s 2-digit language code. Useful if your integration will be utilizing the Customizable User Interface.	Must be one of the following: “EN”, “ES”, “FR” or “ZH”

The response from POST /account contains the user’s access_token, which you should store in your database, and associate to your user. This access_token can be used to access the entirety of the Tight API and the Tight Embedded UI on behalf of your user.

2. Refreshing the user’s access_token

Per OAuth 2.0 spec, the above response from POST /account also contains a refresh_token and expires_in field. You can calculate the expiration date/time of the access_token by summing the created_at and expires_in fields, which will yield a specific date/time in UNIX Epoch time. Per OAuth 2.0 spec, when an access_token expires, you can refresh the token using the /token endpoint .

While the bulk of the Tight API uses Content-Type: application/json, the OAuth 2.0 spec generally favors using URL-encoding for /token implementations; hence the usage of Content-Type: application/x-www-form-urlencoded above.

3. Removing a user

If your user deletes their account within your app, then you will want to remove their account from the Tight API. Once the above DELETE call is made, the user’s data will be inaccessible. After 30 days, it will be permanently deleted. During the 30 day period, you may restore that user’s account if needed (e.g. if the user accidentally deleted their account). Since the user’s account was previously removed, Tight’s standard Authentication (with the access_token in the header) will not work; instead, the accessToken will need to be included in the POST data in the request to restore the user’s account.

Getting Started

Products

International Support

1. Registering a user

2. Refreshing the user’s access_token

3. Removing a user

​1. Registering a user

​2. Refreshing the user’s access_token

​3. Removing a user

1. Registering a user

2. Refreshing the user’s access_token

3. Removing a user