How do we set up Intercom Messenger identity verification (JWT) so we can handle account-specific requests securely?

Most teams hit the same wall with Messenger pretty quickly: customers start asking account‑specific questions (“What’s my current plan?”, “Can you update my billing email?”), and you can’t safely answer them unless you’re certain the person in the Messenger is who they say they are. That’s exactly what Intercom Messenger identity verification with JWTs solves.

Quick Answer: You generate a signed JSON Web Token (JWT) on your backend for each logged‑in user and pass it to the Messenger when you boot Intercom. Intercom verifies the signature on every request—so Fin, Workflows, and agents can confidently handle account‑specific requests without exposing data to the wrong person.

The Quick Overview

What It Is: A secure way to prove a Messenger user’s identity using a signed JSON Web Token (JWT) generated by your backend and verified by Intercom on every request.
Who It Is For: Product and support teams that use Intercom Messenger for logged‑in customers and need to safely expose account data or perform sensitive actions.
Core Problem Solved: It closes the “who is this really?” gap—so you can let Fin AI Agent, Workflows, and agents handle account‑specific support without resorting to manual identity checks or risking data leaks.

How It Works

At a system level, Messenger identity verification is a shared‑secret handshake between your application and Intercom:

Your backend generates a JWT for a logged‑in user, using your Intercom identity verification secret.
Your frontend boots the Intercom Messenger and passes that JWT in the configuration.
Intercom verifies the signature on the token and, if valid, trusts the user identity and attributes you’ve provided.

From that point on, every Messenger request from that browser is tied to that verified user record. That gives you a secure foundation to:

Let Fin resolve account‑specific questions.
Show personalized data in Workflows.
Give agents one trusted view of the customer in the Inbox.

Here’s the high‑level flow broken down into phases.

Server‑side: Generate a JWT per logged‑in user
- Store your Intercom identity verification secret on the server only.
- When a user logs in, your backend creates a compact JWT with their user_id (and optionally, other claims), signed using your secret and a supported algorithm (e.g., HS256).
- You return this token to your frontend as part of your standard session/bootstrap API.
Client‑side: Boot the Messenger with the signed token
- Install the Messenger first: go to Settings > Channels > Messenger > Install, and choose Install for web (code snippet, platform integration, or tag manager).
- In your page’s Intercom boot call, pass the same user_id and add the JWT under the configured identity field (e.g., user_hash or user_verification_token, depending on the method you use).
- Intercom receives both the user identifier and the token, verifies the signature, and links the browser session to the verified user.
Runtime: Use verified identity to handle account‑specific requests
- Fin AI Agent and Workflows can safely use Data connectors and Fin Tasks/Procedures that hit your APIs, because you can trust the Intercom user ID mapping.
- Agents in the Inbox see the same verified user with unified history—no duplicate profiles and fewer “can you confirm your email?” loops.
- You can enforce stricter flows for sensitive topics (billing, account closure) knowing the session is backed by identity verification.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
JWT‑based identity verification	Uses a signed JWT from your backend to prove user identity to Intercom.	Ensures only authenticated users can access account‑specific conversations and data—reducing security risk.
Server‑side secret management	Keeps the Intercom identity secret on your server, never in the browser.	Prevents token forgery and protects your support surface from impersonation attacks.
Verified user mapping in Messenger	Binds each Messenger session to a single, verified Intercom user record.	Eliminates duplicate profiles and gives agents/Fin a consistent, trusted view of every customer.

Ideal Use Cases

Best for secure in‑product and account portals: Because it lets you treat Messenger like a first‑class, authenticated surface—so Fin and agents can discuss billing, usage, or configuration without constant manual checks.
Best for AI‑driven account automations: Because Fin can rely on a verified identity when calling your APIs via Data connectors and Fin Tasks/Procedures—so you can automate tasks like “upgrade plan” or “reset MFA device” with appropriate controls.

Limitations & Considerations

JWT must be generated server‑side only:
Never generate or sign the JWT in the browser or a mobile app. Keep the Intercom identity secret on your backend where it’s protected by your existing security model.
Identity verification covers web Messenger, not teammate login:
JWTs secure your end‑user Messenger sessions. Teammate access to the Intercom workspace should still be protected via SAML SSO, Google Sign‑In, and workspace‑level controls like enforced 2FA.

Pricing & Plans

Identity verification with JWT is part of the core Intercom Messenger offering. You’ll need:

An active Intercom trial or subscription to install and configure the Messenger.
A plan that includes Messenger and the Helpdesk; Fin AI Agent, Workflows, and advanced automation features are available on AI‑enabled plans.

Typical fit by plan:

Core / Growth‑style plans: Best for startups and scaling teams needing secure in‑app support with some automation. JWT lets you confidently answer account questions from day one.
Advanced / Enterprise‑style plans: Best for larger teams orchestrating Fin, Workflows, Data connectors, and detailed governance. JWT becomes the foundation for secure, AI‑driven workflows across web, email, and mobile.

For specific pricing, feature tiers, and AI add‑ons, see Intercom’s pricing page or talk to Sales.

Frequently Asked Questions

Do we really need JWT identity verification if users are already logged in to our app?

Short Answer: Yes—your app’s login does not automatically prove identity to Intercom.

Details:
Your session cookies or OAuth tokens only exist within your application. Intercom is a separate system and cannot see or validate those credentials. Without JWT identity verification:

Messenger traffic is treated as coming from an unverified browser session.
It’s easier to end up with duplicate user records (e.g., same email, different anonymous IDs).
You should not expose sensitive account data or actions in Messenger, because Intercom cannot cryptographically verify who’s on the other side.

JWT identity verification bridges that gap. Your backend vouches for the logged‑in user using your Intercom secret, Intercom verifies the signature, and then Fin, Workflows, and agents can act on that identity with a high level of confidence.

How should we structure our JWT and boot logic in a real application?

Short Answer: Generate and sign the JWT in your backend after login, return it alongside the user’s Intercom ID, and include both in the Messenger boot call on the client.

Details:
Operationally, the pattern looks like this:

Backend: add Intercom fields to your session bootstrap API
- After a user signs in, your API returns:
  - Your internal user ID and profile data.
  - The Intercom user_id or email you use to identify them.
  - A freshly signed JWT using your Intercom identity verification secret.

Frontend: boot Intercom after you know who the user is

Once your SPA or web app receives the session bootstrap response, you call something like:

window.intercomSettings = {
  app_id: "<YOUR_WORKSPACE_ID>",
  user_id: "<USER_ID_FROM_API>",
  // or email: "<USER_EMAIL>",
  user_hash: "<JWT_FROM_API>" // or the identity verification field Intercom specifies
};

Intercom('boot', window.intercomSettings);

If you’re delaying Messenger until cookie consent, set:

window.intercomSettings = { app_id: "<YOUR_WORKSPACE_ID>", disabled: true };

and then, after consent plus session bootstrap:

Intercom('boot', {
  app_id: "<YOUR_WORKSPACE_ID>",
  user_id: "<USER_ID_FROM_API>",
  user_hash: "<JWT_FROM_API>",
  disabled: false
});

Important operational notes:
- Keep the Intercom identity secret in backend configuration, not in JavaScript or mobile binaries.
- Regenerate the JWT when a user logs in or when key attributes change.
- If a user logs out, call Intercom('shutdown') to clear their session and avoid cross‑user leakage on shared devices.

This pattern treats identity verification as a production dependency: your app authenticates the user, your backend signs the claim, and Intercom verifies it—so every account‑specific action through Messenger rests on a cryptographically proven identity.

Summary

Implementing Intercom Messenger identity verification with JWTs is the difference between “a chat widget in your app” and “a secure customer service surface that can safely touch account data.” By signing a JWT on your backend and booting Messenger with that token, you give Fin AI Agent, Workflows, and your human team a trusted identity to work with—so they can resolve billing, usage, and configuration requests quickly without sacrificing security.

Once identity verification is in place, you can confidently layer on AI, Data connectors, and Fin Tasks/Procedures, knowing you’re operating on verified users instead of anonymous browsers.

Next Step

Get Started