Checklist
Does Intercom tracking fire before Accept?
Check Intercom messenger cookies and widget.intercom.io requests before Accept, then again after Reject. A gated widget does not prove API sends stopped.
In brief
Intercom often loads as a messenger or visitor-identity script, and many setups also send events or sync conversations from the server. Check cookies, storage, and requests to widget.intercom.io, js.intercomcdn.com, or api.intercom.io on Fresh, then after Reject. Gating the widget does not prove those API sends stayed off. ConsentProbe can store both packs. A free US-baseline scan is not an EU or California legal conclusion. This page is not an Intercom setup guide and not legal advice.
Not legal advice
This guide explains how to observe Intercom messenger and visitor-identity browser activity, plus any related server or API sends, relative to Accept and Reject. It is not legal advice, not an Intercom workspace, messenger, Series, or outbound setup tutorial, and not a GDPR, ePrivacy, CPRA, or other compliance certificate. ConsentProbe reports are technical observations of what fired. They do not say what counsel would allow. Observation is not counsel permission.
Last updated October 1, 2026. Heap is a separate analytics page. Attentive is an SMS and on-site identity check. This page stays on the Intercom messenger.
Short answer
Check Intercom cookies, storage, and network requests before Accept. Do not assume server or conversations API sends are off because the messenger widget is gated. Intercom often loads through a messenger or visitor-identity script, and many setups also send events or sync conversations from the server.
Record cookies, storage, and requests to widget.intercom.io, js.intercomcdn.com, api.intercom.io, or related hosts on Fresh, then again after Reject. Treat banner text that says functional or marketing is off as a claim. Downstream conversation or event APIs are harder to see from DevTools alone. Ask engineering for delivery logs labeled by consent state when the browser pack is clean and Intercom still shows sessions. First-party versus third-party labeling still applies when Intercom cookies sit on your domain. Host names are examples. This page does not say which Intercom cookies are essential.
Messenger, API, and the banner claim
Three layers get mixed when someone says Intercom is off because the widget waits for Accept. Separate the messenger from server or conversations API traffic. Write the finding as an Intercom host before Accept, or a host after Reject.
| Layer | What a browser test can see | What you may need engineering for |
|---|---|---|
| Intercom messenger or visitor identity | Cookies, storage, and Network rows to widget.intercom.io, js.intercomcdn.com, api.intercom.io, or related hosts before Accept | Usually nothing beyond those browser rows |
| Intercom server or conversations API | Indirect storefront clues. DevTools rarely shows the full payload | Event or conversation delivery logs labeled by consent state |
| CMP category claim | A screenshot of the banner or the category | Matching runtime on Fresh and Reject |
Fresh and Reject on the browser
These steps compare a claimed wait-for-Accept state with cookies and requests. They do not create an Intercom workspace, install a messenger, or write Series copy. The before-Accept audit and the pre-consent checklist hold the general method.
- Use a clean profile. Load the storefront once. Do not click Accept.
- Capture cookies, storage, and Network for Intercom-related hosts, including widget.intercom.io, js.intercomcdn.com, and api.intercom.io.
- Screenshot the banner state. Label the pack Fresh.
- Open a new clean profile, or clear storage. Click Reject All. Navigate once more.
- Recapture cookies and Network. Label the pack Reject. Compare it with Fresh and, if you ran one, with an Accept control.
- Write one finding sentence per mismatch, such as an Intercom host on Fresh, or the same host after Reject.
API sends when the widget looks gated
A quiet messenger leaves conversations API sends untested. A browser gate and an API gate are different checks. Intercom's messenger cookie article describes one install pattern where the script can load and wait to boot, and it says cookies are not used in that waiting state. That sentence is a vendor description, not a result for this URL.
Look for requests to widget.intercom.io, js.intercomcdn.com, or api.intercom.io on Fresh, and for cookies whose names start with intercom-. The article names intercom-id, intercom-session, and intercom-device-id, each with an app id suffix. Those names are jar clues. A missing name does not prove the host stayed quiet. This page does not class those cookies as essential.
If Fresh and Reject look clean and Intercom still shows sessions, ask engineering for delivery logs tagged by consent state and timestamp. This page does not walk through workspace creation, messenger install, Series, or outbound campaigns. Attentive is SMS and on-site identity. This page stays on Intercom.
When checking Intercom hosts gets slow
Checking Intercom hosts across templates by hand takes a long time. ConsentProbe runs Fresh and Reject on the storefront URL. Each finding stays tied to a request, a cookie, or a screenshot. The cookie audit product page describes that browser recording.
Use the free US-baseline visit for the report format, and paid EU or California scenarios when those regions are the claims. ConsentProbe does not install or configure Intercom, does not install a CMP, and does not issue a certificate. A free US-baseline scan is not an EU or California legal conclusion.
FAQ
Does Intercom tracking fire before Accept?
It often does when the messenger loads on first paint. Verify Network and cookies on a Fresh visit, including widget.intercom.io and js.intercomcdn.com, before you treat the banner as proof.
Does Reject All stop Intercom?
Check a labeled Reject visit. Do not trust the banner category alone. The Reject leftovers guide is the network check when the same host remains.
If the widget is gated, are server events off?
Not necessarily. A delayed messenger leaves conversations API and event sends untested. Ask engineering for logs labeled by consent state.
Is this an Intercom setup guide?
No. This page is a Fresh and Reject check. It does not install a messenger, configure a workspace, or write Series or outbound campaigns.
Is this the same as Attentive before Accept?
No. Attentive is an SMS and on-site identity check. This page is the Intercom messenger. Heap is a separate analytics page.
Is this legal advice?
No. These are technical observations. It is not legal advice. Observation is not counsel permission. ConsentProbe does not replace counsel, and it does not install a CMP.
Limits of this page
This page checks Intercom cookies and hosts on Fresh, repeats the check after Reject, and says a gated widget leaves API sends untested. It is not legal advice and not an Intercom setup guide. Observation is not counsel permission. A free US-baseline scan is not an EU or California legal conclusion.
Related guides
Open the before-Accept audit, the Reject leftovers guide, the pre-consent checklist, the marketing-pixels FAQ, and the party-label guide.
- How to run a cookie audit before Accept
- Reject All still tracking
- Pre-consent audit checklist
- Does Reject All stop marketing pixels?
- First-party vs third-party cookies
- Does Attentive tracking fire before Accept?
- Free US-baseline vs paid EU and California
- Cookie audit product: what ConsentProbe records before Accept
- Pricing and listed regional products
Sources
These links cover the platform and regulatory context used in this guide. Applicability still depends on the organization and jurisdiction.
Save a US-baseline technical record
After a DIY check, run a free US-baseline audit: one browser visit outside California, with cookies, requests, and screenshots stored as evidence. That visit does not run EU reject/accept or California GPC. EU, California, and Global 2 audits can be purchased from Billing after sign-in.