User Creation
The first step to consuming any of the Hurdlr API products is to register your user with the Hurdlr 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 Hurdlr API's endpoint for registering a user contains a variety of input parameters for more personalized functionality:
| Field | Description | Format |
|---|---|---|
| Your user's business's email, if applicable. Useful if your integration will be utilizing Hurdlr's Customizable User Interface or Hurdlr's Invoicing API . | Any valid email string | |
| bizName | Your user's business's name, if applicable. Useful if your integration will be utilizing Hurdlr's Customizable User Interface or Hurdlr'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 Hurdlr API and the Hurdlr 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 .
URL-encoded Parameters
While the bulk of the Hurdlr API uses
Content-Type: application/json, the OAuth 2.0 spec generally favors using URL-encoding for/tokenimplementations; hence the usage ofContent-Type: application/x-www-form-urlencodedabove.
3. Removing a user
If your user deletes their account within your app, then you will want to remove their account from the Hurdlr 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, Hurdlr'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.
Updated about 1 month ago