Skip to main content
Setting up Custom Actions authentication

Approaches you can use to authenticate your Custom Actions, and how to set up, view and manage tokens.

Stephen Forbes avatar
Written by Stephen Forbes
Updated this week

To set up new authentication methods for Custom Actions, go to Settings > Integrations > Authentication and click New token.

There are two authentication token types to choose from:

Text tokens

Text tokens are static tokens. You can set the token's name, description, value, token prefix, and the key for the request header containing the token, which will be inserted into the Custom Action request.

HTTP Request tokens

HTTP Request tokens are dynamic. You configure an HTTP request to your Authentication Endpoint that will refresh the token when needed. These tokens must be tested from the Authentication Token UI before saving them. You can set the token's name, description, and then the fields that affect the request itself. These are the HTTP request method, URL, HTTP headers, and any key-value pairs.

You should test the token by clicking Test request and then specify the token's location in the response, the token prefix and the key for the request header.

If an HTTP Request token is assigned to a Custom Action, the action will use the most recently fetched token in the Custom Action request. If the request fails with a “401 Unauthorized” response, the token will be refreshed by sending an HTTP Request to your Authentication Endpoint URL. The Custom Action request will then be retried with the newly fetched token.

If your server is returning a 200 for an access denied response, we won't refresh the token. You'll need to update your servers to return a 401 in this case.

If there is a problem refreshing a token, the issue will be logged in the Custom Actions "Logs" tab:

Known limitations

Currently neither the Text or HTTP Request authentication token types support different authentication request details per end user. Usually this is requested as a full OAuth flow.

Logic

Text based tokens are straightforward, the custom action will use the assigned token value whenever it tests or sends a live action request. Http request tokens have a more involved flow. For both testing and live actions, the custom action will first use the most recently retrieved token. If the request fails, it will then send a refresh request and try the action again. This will only occur once to avoid an infinite loop.

If the action keeps failing due to refresh requests failing, it will trigger the circuit breaker in the same way that all custom actions can for repeated failures of a single action.


💡Tip

Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts


Did this answer your question?