> ## 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. # 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](/v5.0/getting-started/quickstart/user-creation) 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](/v5.0/getting-started/quickstart/embedded-ui) or Tight's [Invoicing API](/v5.0/products/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](/v5.0/getting-started/quickstart/embedded-ui) or Tight's [Invoicing API](/v5.0/products/invoicing-api). | Any string | | bizType | Your user's business type, if applicable. Useful if your integration will be utilizing the Business-specific [Deduction Finder ](/v5.0/products/bank-transactions-1/expense-tracking/deduction-finder)or the [Customizable User Interface](/v5.0/getting-started/quickstart/embedded-ui). | 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](/v5.0/getting-started/quickstart/embedded-ui) . | 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](/v5.0/getting-started/quickstart/embedded-ui). | Must be one of the following: "EN", "ES", "FR" or "ZH" | The response from [POST /account](/v5.0/getting-started/quickstart/user-creation) 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](/v5.0/getting-started/quickstart/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](/v5.0/getting-started/quickstart/user-creation) 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](https://en.wikipedia.org/wiki/Unix_time). Per OAuth 2.0 spec, when an `access_token` expires, you can refresh the token using [the /token endpoint ](/v5.0/getting-started/api-patterns/authentication). 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](/v5.0/getting-started/quickstart/user-creation). 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](/v5.0/getting-started/api-patterns/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](/v5.0/getting-started/quickstart/user-creation).