[Intercom Mobile SDKs] Duplicate intercom account issue when try to login with emailID alone without UserId. | Community
Skip to main content
Answered

[Intercom Mobile SDKs] Duplicate intercom account issue when try to login with emailID alone without UserId.

  • October 30, 2025
  • 1 reply
  • 6 views
G

We’re creating the intercom user account from the backend when a new user signs up in our systems. We set up the account with the email ID, name, and mobile number, but not the user ID. [We wanted to keep the email as the single source of truth.]

When the user logs in to our mobile app (iOS and Android), we use the same email ID to log in to the intercom using the identified user login option (without a user ID).

However, instead of identifying the existing account and logging in, it creates a new account again.
 

Earlier, we faced similar issues with duplicate accounts because a few intercom accounts from the mobile app had logged in with the user ID and email. That created new accounts in the intercom. We resolved this by permanently deleting those accounts and now only using the email ID to log in. But even with this change, the mobile SDK is unable to identify the user and instead creates a new duplicate account again.

 

Could you help me understand the issue better and suggest the right approach to work with our scenario?

Best answer by Emilygav

Hey there ​@Ganesh N, Emily here from Support Engineering at Intercom 👋🏼

 

Thanks for the detailed context — this is almost certainly an identity consistency issue between how contacts are created on your backend and how they’re identified via the mobile SDK.

 

You’re identifying by email only. Intercom prioritizes a stable user_id for matching; if multiple contacts share the same email (or if identifiers were mixed previously), the SDK can’t unambiguously match and may create a new contact.  The durable fix is to make a single, canonical user_id the source of truth for identification, and use email as an attribute (which can change), not as the primary key.

 

Using email as the “single source of truth” sounds simple, but it’s not stable - people can share or change emails, and different systems (SDKs, APIs, imports) will prioritise user_id when available, leading to conflicts if you don’t supply it consistently. Intercom’s identity model is intentionally user_id-first to prevent exactly these duplicate scenarios as your product grows and identifiers evolve.

 

The right approach for your scenario:

  • Use a single, stable and unique user identifier: set a canonical user_id for every person (keep email as an attribute that can change).

  • When creating/updating contacts (backend and SDK), always send both user_id and email to avoid ambiguity now and in the future.

  • Backfill user_id onto existing email‑only contacts via the API, then remove remaining duplicates; note there’s a 7‑day grace window on reusing the same identifiers after deletion.

  • In mobile, always log in identified users with user_id, initialize the SDK only after auth, and call shutdown on logout/user switch to prevent carryover sessions and duplicates.

  • Optional but recommended: enable Identity Verification (JWT) once user_id exists for all users; JWTs require user_id (you can mirror the email into both user_id and email in the payload if needed).

 

Hopefully this helps Ganesh! 

1 reply

Emilygav
Intercom Team
Forum|alt.badge.img+6
  • EmilygavIntercom Team
  • Intercom Team
  • 161 replies
  • Answer
  • November 7, 2025

Hey there ​@Ganesh N, Emily here from Support Engineering at Intercom 👋🏼

 

Thanks for the detailed context — this is almost certainly an identity consistency issue between how contacts are created on your backend and how they’re identified via the mobile SDK.

 

You’re identifying by email only. Intercom prioritizes a stable user_id for matching; if multiple contacts share the same email (or if identifiers were mixed previously), the SDK can’t unambiguously match and may create a new contact.  The durable fix is to make a single, canonical user_id the source of truth for identification, and use email as an attribute (which can change), not as the primary key.

 

Using email as the “single source of truth” sounds simple, but it’s not stable - people can share or change emails, and different systems (SDKs, APIs, imports) will prioritise user_id when available, leading to conflicts if you don’t supply it consistently. Intercom’s identity model is intentionally user_id-first to prevent exactly these duplicate scenarios as your product grows and identifiers evolve.

 

The right approach for your scenario:

  • Use a single, stable and unique user identifier: set a canonical user_id for every person (keep email as an attribute that can change).

  • When creating/updating contacts (backend and SDK), always send both user_id and email to avoid ambiguity now and in the future.

  • Backfill user_id onto existing email‑only contacts via the API, then remove remaining duplicates; note there’s a 7‑day grace window on reusing the same identifiers after deletion.

  • In mobile, always log in identified users with user_id, initialize the SDK only after auth, and call shutdown on logout/user switch to prevent carryover sessions and duplicates.

  • Optional but recommended: enable Identity Verification (JWT) once user_id exists for all users; JWTs require user_id (you can mirror the email into both user_id and email in the payload if needed).

 

Hopefully this helps Ganesh! 


Terms & ConditionsAccessibility statement