Debug Intercom in Chrome DevTools

What Intercom traffic looks like

Intercom's Messenger is not page-view shaped. It boots once from a settings object, then stays alive for the life of the page, so most of what you see is one identity-carrying boot call followed by repeated polling.

Endpoint pattern

The snippet pulls the Messenger from widget.intercom.io/widget/<app_id> with its JavaScript chunks served from js.intercomcdn.com; the running Messenger then talks to api-iam.intercom.io and api.intercom.io for boot, ping, and conversation traffic

Transport

JSON POSTs. The boot call carries the visitor identity; a ping request repeats on an interval for as long as the tab is open, which is why Intercom keeps appearing in the stream long after page load

Config object

window.intercomSettings = { app_id: '<app_id>', … }, then the Intercom('boot'), Intercom('update'), and Intercom('trackEvent', name, metadata) calls

Key parameters

app_id · user_id, email, name when the visitor is identified · user_hash when identity verification is enabled · whatever custom attributes the site chose to attach

Cookies

intercom-id-<app_id>, intercom-session-<app_id>, and intercom-device-id-<app_id>: the workspace id is encoded in the cookie name, so the cookies tell you which workspace is installed even before you read a request

A boot or update payload, as Event Watcher captures it:

{
  "app_id": "ab12cd34",
  "user_id": "u-4821",
  "email": "customer@example.com",
  "user_hash": "9f8c…",
  "custom_attributes": { "plan": "pro", "seats": 12 }
}

Debugging Intercom with Event Watcher

• No dedicated parser. Each request is matched by hostname, named Intercom, badged with the Widgets category, and shown with its parsed query and body parameters plus the Cookies section.
• The boot and update payloads are where the answers are: which app_id is live, whether the visitor is identified or anonymous, which custom attributes the site sends, and whether user_hash is present.
• Grouping the stream by Endpoint separates the one-time bundle loads on js.intercomcdn.com from the repeating API traffic, which otherwise dominates the view.
• Script Tree attributes the snippet to the site's own template, a tag manager, or another third-party script. That decides whether a CMP can gate the Messenger at all.

Intercom and consent

Event Watcher checks Intercom against the functional consent category.

Chat gets left out of consent management more often than any other widget, on the reasoning that support is necessary functionality. That holds for an anonymous Messenger. It holds less well once the boot payload carries an email address, a name, and custom attributes, and once intercom-id-* is written before the visitor has touched anything. Read the boot payload first, then decide whether functional is the honest classification.

Common debugging scenarios

• The Messenger never appears. Confirm the widget.intercom.io/widget/<app_id> request returns, then check that a boot POST followed with the same app_id.
• Logged-in users show up as anonymous leads. Look for user_id or email in the boot payload, and for user_hash alongside them. With identity verification on, a missing or stale hash makes Intercom reject the identity.
• Custom attributes never reach Intercom. They have to be in the boot or update payload. Setting intercomSettings after boot without an update call changes nothing on the wire.
• Two workspaces installed. Two different intercom-id-* cookie names in one session means two snippets are running.
• Chat loads before consent. Filter to Intercom and read the consent verdict on the first request of the session.