Fin + Data Connectors: how to implement SMS OTP before personal data access? | Community
Skip to main content
Answered

Fin + Data Connectors: how to implement SMS OTP before personal data access?

  • January 22, 2026
  • 3 replies
  • 64 views
ב
Forum|alt.badge.img+1

Hi Intercom Support/Community,


We want Fin to trigger an OTP verification flow whenever a customer asks for personal information, before Fin is allowed to call our backend and retrieve sensitive data.

 

What we have today (custom SMS OTP via our backend):

  1. Data Connector – Generate OTP: calls our backend, and the user receives a code via SMS.

  2. Data Connector – Verify OTP: Fin should ask the user for the code, send it to our backend for verification, and then our backend returns a token.
    After verification, we want Fin to use that token to access backend information via subsequent calls

We tried implementing this via Fin Tasks, but it’s not working well for us.

Question: What is the most effective/supported way in Intercom to implement this flow end-to-end (SMS OTP + verification + then allow sensitive Data Connector calls)?

Best answer by Dara K

Hey ​@בן גטניו, the most effective/supported/easiest way to do this is to use Intercom’s built‑in OTP gate for Data connectors wherever possible: enable “Email verification (OTP)” on the connector and let Fin/Workflows handle the verify→30‑minute session window automatically before any sensitive calls. It’s supported across Let Fin Answer, Fin Tasks, and Workflows. Today this OTP is only email‑based though.

If you need SMS OTP via your own backend, use a two‑step flow plus “User tokens” for auth: run your Generate/Verify OTP Data connectors; when your backend issues a short‑lived token, set it into the Intercom Messenger as a per‑user auth token, and configure subsequent Data connectors to use that token in headers. This is the most supported way to carry a verified token across subsequent Fin calls.

3 replies

D
Intercom Team
Forum|alt.badge.img+1
  • Dara KIntercom Team
  • Intercom Team
  • Answer
  • January 30, 2026

Hey ​@בן גטניו, the most effective/supported/easiest way to do this is to use Intercom’s built‑in OTP gate for Data connectors wherever possible: enable “Email verification (OTP)” on the connector and let Fin/Workflows handle the verify→30‑minute session window automatically before any sensitive calls. It’s supported across Let Fin Answer, Fin Tasks, and Workflows. Today this OTP is only email‑based though.

If you need SMS OTP via your own backend, use a two‑step flow plus “User tokens” for auth: run your Generate/Verify OTP Data connectors; when your backend issues a short‑lived token, set it into the Intercom Messenger as a per‑user auth token, and configure subsequent Data connectors to use that token in headers. This is the most supported way to carry a verified token across subsequent Fin calls.

ב
Forum|alt.badge.img+1

Hey ​@בן גטניו, the most effective/supported/easiest way to do this is to use Intercom’s built‑in OTP gate for Data connectors wherever possible: enable “Email verification (OTP)” on the connector and let Fin/Workflows handle the verify→30‑minute session window automatically before any sensitive calls. It’s supported across Let Fin Answer, Fin Tasks, and Workflows. Today this OTP is only email‑based though.

If you need SMS OTP via your own backend, use a two‑step flow plus “User tokens” for auth: run your Generate/Verify OTP Data connectors; when your backend issues a short‑lived token, set it into the Intercom Messenger as a per‑user auth token, and configure subsequent Data connectors to use that token in headers. This is the most supported way to carry a verified token across subsequent Fin calls.

 

But should we do this with Tasks or workflows? or… something else maybe?

​@Dara K 

D
Intercom Team
Forum|alt.badge.img+1
  • Dara KIntercom Team
  • Intercom Team
  • February 2, 2026

Hey ​@בן גטניו if you’re going with option 1 and using the built in OTP email verification either one would be fine. If you want to stick with your custom SMS OTP then I suggest using workflows instead.

    Terms & ConditionsAccessibility statement