Authentication

The Hurdlr API is a RESTful API that follows the standard OAuth 2.0 protocol, accepting JSON payloads and returning JSON responses. Hurdlr 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 with the Hurdlr 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 \
  --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 Hurdlr API displays the Audit Trail 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. 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 \
  --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' \