Debug Zendesk in Chrome DevTools

What Zendesk traffic looks like

Zendesk's embeddables have two generations running side by side, and they use different infrastructure. Knowing which hosts belong to which generation is most of the debugging.

Endpoint pattern

The bootstrap is static.zdassets.com/ekr/snippet.js?key=<embeddable key>; the key is resolved against ekr.zdassets.com, the Embeddable Key Registry, which returns the widget's configuration; the classic Chat widget still runs on Zopim infrastructure at v2.zopim.com with its live session held open through widget-mediator.zopim.com; Sunshine Conversations messaging goes to api.smooch.io

Transport

Script load plus a configuration fetch, then a persistent connection for live chat. Individual chat messages do not appear as separate requests, only the session

Config object

window.zESettings for the classic widget, and the zE(...) command API for both generations

Key parameters

The embeddable key in the snippet URL is the account and widget identifier, and the fastest way to confirm which Zendesk instance a page is wired to

Cookies

__zlcmid is the persistent Zopim machine identifier, set as soon as the chat widget initializes

The load sequence, as it appears in the stream:

static.zdassets.com/ekr/snippet.js?key=<embeddable key>   widget bootstrap
ekr.zdassets.com                                          configuration for that key
v2.zopim.com                                              classic Chat assets
widget-mediator.zopim.com                                 live chat session
api.smooch.io                                             Sunshine Conversations messaging

Debugging Zendesk with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Zendesk, badged with the Widgets category, and shown with parsed query and body parameters plus cookies set and sent.
• Read the key query parameter on the snippet request to confirm which widget configuration is live. Two different keys in one session means two widgets.
• Grouping by Endpoint is what separates the generations: zdassets.com hosts belong to the modern embeddable, zopim.com hosts to classic Chat. Seeing both is common on sites that migrated without removing the old snippet.
• Script Tree shows whether the snippet came from the site's template, a tag manager, or another script, which is usually the deciding factor in whether it can be gated.

Zendesk and consent

Event Watcher checks Zendesk against the functional consent category.

Support widgets are typically hardcoded into a theme or layout template rather than deployed through a tag manager, so the CMP often has no control over them at all. The observable consequence is that __zlcmid is set and the chat session opens on page load, before any banner interaction. That may well be the intended posture, but it should be a decision rather than a side effect of where the snippet was pasted.

Common debugging scenarios

• The widget is missing on some pages. Check whether snippet.js is requested there at all. If it is, the widget is loading and the configuration returned by ekr.zdassets.com is what suppressed it.
• Wrong brand or wrong department. Read the key in the snippet URL and compare it against the widget you expect.
• Both widget generations installed. Zopim hosts appearing alongside modern embeddable traffic means the old snippet was never removed. Users can end up in two different queues.
• Chat works but nothing shows in the stream. Live chat runs over a persistent connection. You see the session open, not each message.
• The widget loads before consent. Filter to Zendesk and read the consent verdict on the first request.