We’re trying to build an Intercom Data Connector that retrieves customer-specific data from our backend.
Our backend API requires a user-specific access token. This token is generated only after the customer completes an OTP/authentication flow, and each customer receives a different token.
The flow we want to support is:
The customer completes OTP authentication.
The OTP/auth connector returns a response containing:
{ "data": { "access_token": "..." } }
A second connector should then call our recommendations API using that token in the Authorization header:
Authorization: Bearer <data.access_token>
The issue:
When we try to pass the token dynamically in the connector header, for example:
Authorization: Bearer {{accessToken}}
or by using a value returned from a previous connector/action, our backend does not receive the Authorization header/token.
The only setup that worked was using Intercom’s Authentication Token feature with a static Text token. However, this does not work for our production use case, because the token must be dynamic and customer-specific.
What we need to understand:
Do Intercom Data Connectors support dynamic per-user values in the Authorization header?
Can a Fin Procedure/Task take data.access_token from one connector response and pass it as Authorization: Bearer <token> in a later connector request?
If this is supported, what is the recommended setup or correct syntax?
If this is not supported, what is the recommended architecture for this use case?
In short:
OTP/auth connector returns: data.access_token
Recommendations connector needs to call our API with: Authorization: Bearer <data.access_token>
A static Authentication Token is not suitable because the token changes per user
Adding the token manually as a header input does not appear to pass it to our backend
Could you please confirm whether this flow is supported, and if so, how it should be configured?
Best answer by Rainshower
Hii @בן גטניו! Reina here from the TSE team!
So yes, this flow is supported, and the reason it hasn't been working is likely the variable name. Custom header values on Data Connectors go through the same {{ }} templating as the URL and body, but the variable has to match a data input defined on that connector. If {{accessToken}} isn't a data input on the recommendations connector, it renders as empty, so your backend receives "Bearer " with nothing after it. That's why it looked like the header never arrived.
But! You could instead try this in a Procedure:
So your OTP connector returns data.access_token as a step output. Store that value in a temporary attribute in the Procedure.
Then regarding the recommendations connector, add a data input called accessToken (or any name, as long as the header uses the same one). In the Procedure step for that connector, set the input's Source to that temporary attribute. That way the token is passed exactly as returned, without Fin re-interpreting it.
In the connector's HTTP headers, add a key-value pair: Authorization with value Bearer {{accessToken}}. Leave the Authentication Token dropdown empty for this connector.
On the Authentication Token feature: you're right that it can't do this. Text and HTTP Request tokens are workspace-wide, not per customer, so the static token working and the dynamic one not is expected.
One alternative if your customers are already logged in on your site, would perhaps be to skip the OTP connector entirely and use a User authentication token. Your server mints a per-user JWT after login, your frontend passes it with Intercom('setAuthTokens', { your_token_name: '<jwt>' }), and you attach that token to the recommendations connector. Intercom then sends it in the header on every call for that user, no Procedure plumbing needed. Setup is in https://www.intercom.com/help/en/articles/6615543-setting-up-data-connectors-authentication under User tokens.
Give the data input approach a go and post back here if the header still comes through empty, and I’ll do my best to take a better look as well! :)
So yes, this flow is supported, and the reason it hasn't been working is likely the variable name. Custom header values on Data Connectors go through the same {{ }} templating as the URL and body, but the variable has to match a data input defined on that connector. If {{accessToken}} isn't a data input on the recommendations connector, it renders as empty, so your backend receives "Bearer " with nothing after it. That's why it looked like the header never arrived.
But! You could instead try this in a Procedure:
So your OTP connector returns data.access_token as a step output. Store that value in a temporary attribute in the Procedure.
Then regarding the recommendations connector, add a data input called accessToken (or any name, as long as the header uses the same one). In the Procedure step for that connector, set the input's Source to that temporary attribute. That way the token is passed exactly as returned, without Fin re-interpreting it.
In the connector's HTTP headers, add a key-value pair: Authorization with value Bearer {{accessToken}}. Leave the Authentication Token dropdown empty for this connector.
On the Authentication Token feature: you're right that it can't do this. Text and HTTP Request tokens are workspace-wide, not per customer, so the static token working and the dynamic one not is expected.
One alternative if your customers are already logged in on your site, would perhaps be to skip the OTP connector entirely and use a User authentication token. Your server mints a per-user JWT after login, your frontend passes it with Intercom('setAuthTokens', { your_token_name: '<jwt>' }), and you attach that token to the recommendations connector. Intercom then sends it in the header on every call for that user, no Procedure plumbing needed. Setup is in https://www.intercom.com/help/en/articles/6615543-setting-up-data-connectors-authentication under User tokens.
Give the data input approach a go and post back here if the header still comes through empty, and I’ll do my best to take a better look as well! :)
