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/hubspotTeamwork CRM:
https://api.locoia.com/v1/oauth2/callback/teamwork%20crm
OAuth2 Header
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_urlURL for user authorization page (GET request)step3_access_urlURL for exchanging the code for an access token (POST by default with content-typeapplication/x-www-form-urlencoded)token_refresh_urlUsed for token refresh if different from the regularstep3_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_idinstead ofclient_id, thusalternative_client_id_keyneeds to be set accordinglyThe client id key is
secretinstead ofclient_secret, thusalternative_client_secret_keyneeds to be set accordinglyThe access token is returned inside a dictionary called
data, instead of in the 'root' dictionary, thusaccess_token_pathneeds to be set accordinglyThe 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?