OAuth2

Here are all details about configuring Connectors to authenticate with OAuth2

Introduction

Before diving into configuration details, it is useful to first understand at a high level how OAuth2 works. This helps with troubleshooting and understanding the process flow.

Redirect URI

The redirect URI is always https://api.locoia.com/v1/oauth2/callback/connectorname

  • For one-word Connectors, use the lowercase connector name

  • For multi-word Connectors, replace spaces with %20

Examples:

  • HubSpot:

    https://api.locoia.com/v1/oauth2/callback/hubspot

  • Teamwork CRM:

    https://api.locoia.com/v1/oauth2/callback/teamwork%20crm

The OAuth2 access token is typically sent in the header using this format:

{
  "encode": false,
  "token_in_header": true,
  "content_type": "application/json",
  "header_key": "Authorization",
  "token_format": "{{token}}",
  "token_prefix": "Bearer {{token_format}}"
}

Authentication Configuration (Standard)

For APIs following the standard OAuth2 flow, the configuration looks like:

OAuth2 URLs Explained

  • step1_authorize_url URL for user authorization page (GET request)

  • step3_access_url URL for exchanging the code for an access token (POST by default with content-type application/x-www-form-urlencoded)

  • token_refresh_url Used for token refresh if different from the regular step3_access_url (Deprecated for standard flows)

Additional Query/Body Parameters

  • extra_authorization_url: Add query parameters to the authorization request.

  • extra_access_url: Add body parameters to the token exchange request.

If scopes are required, add them in the extra_authorization_url:

Dynamic base domains

To handle dynamic subdomains or environments (like production/sandbox), use Jinja rendering inside URLs as needed.

Handling OAuth2 deviations

For APIs that deviate from the standard OAuth2 flow, additional config options are available:

client_id_and_secret_in_headers

Send client credentials as Basic Auth instead of body.

alternative_code_key

Rename the key for the authorization code.

alternative_client_id_key

Rename the key for client ID.

alternative_client_secret_key

Rename the key for client secret.

grant_type

Add custom grant_type (Deprecated).

accept_header

Set a custom Accept header.

content_type

Change Content-Type (e.g., to application/json).

request_method

Force GET instead of POST for token request.

access_token_path

Define a custom JSON path to find the access token in the response.

Deprecated auth_form Fields

Additional fields that can be exposed to users:

alternative_scope

User-defined scope input (overwrites default scopes).

client_id

Allows user to provide their own Client ID, overriding config.

client_secret

Allows user to provide their own Client Secret, overriding config.

Other custom fields can also be added manually if required.


Examples

HubSpot - Standard with Scopes

The Authentication Configuration is the standard one, with specific scopes:

The header is the standard header.

TikTok - Alternative client keys and access token path

TikTok has a few deviations from the OAuth2 standard:

  • The client id key is app_id instead of client_id, thus alternative_client_id_key needs to be set accordingly

  • The client id key is secret instead of client_secret, thus alternative_client_secret_key needs to be set accordingly

  • The access token is returned inside a dictionary called data, instead of in the 'root' dictionary, thus access_token_path needs to be set accordingly

  • The base domain for the access url, is always https://business-api.tiktok.com/, even though the base domain for the endpoints itself is based on the environment: https://{% if environment is defined and environment == 'Sandbox' %}sandbox{% else %}business{% endif %}-api.tiktok.com/open_api/v1.2/

The Authentication Configuration thus needs to be setup like this:

Last updated

Was this helpful?