PhoneNumber not being fullfiled on contact | Community
Skip to main content
Answered

PhoneNumber not being fullfiled on contact

  • March 16, 2026
  • 1 reply
  • 38 views

Hi everyone,

We are experiencing inconsistent behavior with contacts created through our WhatsApp channel and wanted to check if anyone else has seen something similar.

When users start a conversation via WhatsApp, some contacts are created with the phone field populated, while others are created without the phone number.

However, in the Intercom UI we consistently see the "WhatsApp number" field populated, even when the phone field is null in the Contact API response.

Because of this, we are unable to retrieve the user's phone number via the API.

Example Contact API response

{
"type": "contact",
"id": "69b8334c390fea79a974100c",
"external_id": "whatsapp:xpto",
"phone": null,
"name": "Teste"
}

Conversation payload

{
"type": "conversation",
"source": {
"type": "whatsapp",
"author": {
"type": "lead",
"id": "69b8334c390fea79a974xxxc",
"name": "Teste"
}
}
}

In the Intercom UI the WhatsApp number is visible, but it does not seem to be exposed through either the Contact API or Conversation API.

 

Has anyone experienced this before?

Specifically, we are trying to understand:

  • Is the WhatsApp number stored in a field that is not exposed in the public API?

  • Is there a configuration required for WhatsApp numbers to populate the phone field?

  • Is there any endpoint that allows retrieving the WhatsApp number associated with the contact?

We rely on the phone number to identify users in our backend systems, so having access to it via API is critical for our integration.

Thanks in advance!

Best answer by Dara K

Hey ​@fabiofontesx 

What’s going on is that Intercom currently treats the WhatsApp number and the phone attribute as two separate things:

  • When someone writes in via WhatsApp, Intercom always stores their number in a WhatsApp-specific attribute (what you see in the UI as “WhatsApp number”).
  • The phone attribute is only populated when it comes from other data flows, for example:
    • CSV imports or your own backend / REST API updates
    • Data passed in via the Messenger snippet or other channels
    • Syncs from integrations (e.g. Salesforce)
    • When a WhatsApp lead is merged into an existing contact that already has a phone value

There is no automatic mapping today from “WhatsApp number” → phone, and the WhatsApp-specific number isn’t exposed as a separate field in the public Contacts or Conversations APIs. That’s why you see:

  • In the UI: “WhatsApp number” always present
  • In the API: phone is sometimes populated (where it came from another source or a merge), and null for “pure” WhatsApp-only contacts that never had phone set elsewhere

So:

  • Yes, the WhatsApp number is stored in an internal WhatsApp attribute that isn’t currently exposed via the API.
  • No, there’s no setting that auto-copies that into phone.
  • No, there isn’t an endpoint today that returns the WhatsApp number field directly.

In practice, the contacts where you do see phone filled in your API responses are the ones that got it from those other sources (imports, your own integrations, or merges), not from WhatsApp itself.

I’ve logged this as a product gap (exposing the WhatsApp number via API and/or allowing it to map into phone) and attached your use case so the impact is clear. In the meantime, the only reliable workaround is to ensure that, wherever you already know a user’s phone number in your systems, you also write it into Intercom’s phone attribute via API or sync, so it’s available to you for identification.

1 reply

Forum|alt.badge.img+5
  • Intercom Team
  • Answer
  • March 27, 2026

Hey ​@fabiofontesx 

What’s going on is that Intercom currently treats the WhatsApp number and the phone attribute as two separate things:

  • When someone writes in via WhatsApp, Intercom always stores their number in a WhatsApp-specific attribute (what you see in the UI as “WhatsApp number”).
  • The phone attribute is only populated when it comes from other data flows, for example:
    • CSV imports or your own backend / REST API updates
    • Data passed in via the Messenger snippet or other channels
    • Syncs from integrations (e.g. Salesforce)
    • When a WhatsApp lead is merged into an existing contact that already has a phone value

There is no automatic mapping today from “WhatsApp number” → phone, and the WhatsApp-specific number isn’t exposed as a separate field in the public Contacts or Conversations APIs. That’s why you see:

  • In the UI: “WhatsApp number” always present
  • In the API: phone is sometimes populated (where it came from another source or a merge), and null for “pure” WhatsApp-only contacts that never had phone set elsewhere

So:

  • Yes, the WhatsApp number is stored in an internal WhatsApp attribute that isn’t currently exposed via the API.
  • No, there’s no setting that auto-copies that into phone.
  • No, there isn’t an endpoint today that returns the WhatsApp number field directly.

In practice, the contacts where you do see phone filled in your API responses are the ones that got it from those other sources (imports, your own integrations, or merges), not from WhatsApp itself.

I’ve logged this as a product gap (exposing the WhatsApp number via API and/or allowing it to map into phone) and attached your use case so the impact is clear. In the meantime, the only reliable workaround is to ensure that, wherever you already know a user’s phone number in your systems, you also write it into Intercom’s phone attribute via API or sync, so it’s available to you for identification.