Debug Trustpilot in Chrome DevTools

What Trustpilot traffic looks like

Trustpilot ships two scripts with very different privacy profiles: the TrustBox widget that displays reviews, and the invitation script that sends customer details back to Trustpilot after a purchase. They are often installed together and discussed as one thing.

Endpoint pattern

TrustBox widgets bootstrap from widget.trustpilot.com (typically bootstrap/v5/tp.widget.bootstrap.min.js) and render each widget in an iframe served from the same host; the separate Automatic Feedback Service script loads from invitejs.trustpilot.com and posts review invitations to invitations-api.trustpilot.com

Transport

Script load plus iframe embeds for the display side; a JSON POST per invitation on the checkout side

Config object

Widgets are configured through data-* attributes on their container element (business unit id, template id, locale); invitations go through the tp('createInvitation', { … }) call, usually on the order confirmation page

Key parameters

Business unit id and template id on the widget request · recipientEmail, recipientName, and referenceId (the order number) on an invitation

An invitation call, as Event Watcher captures it:

tp('createInvitation', {
  recipientEmail: 'customer@example.com',
  recipientName: 'A. Customer',
  referenceId: 'ORD-10482',
  source: 'InvitationScript'
});

Debugging Trustpilot with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Trustpilot, badged with the Widgets category, and shown with parsed query and body parameters plus the Cookies section.
• The invitation POST to invitations-api.trustpilot.com is the request worth opening on any ecommerce site. It is customer personal data leaving the confirmation page from the browser, and the body shows exactly which fields were included.
• Grouping by Endpoint keeps the widget traffic that appears on every page separate from the invitation traffic that should appear on exactly one.
• Script Tree attributes both scripts to the site's template, a tag manager, or another third-party script.

Trustpilot and consent

Event Watcher checks Trustpilot against the functional consent category.

The category fits the widget: rendering review content is display functionality. It fits the invitation script much less well. Sending a customer's email address and order reference to a third party is not what most consent notices mean by functional, and it is a distinct processing purpose from showing star ratings. Treat the two hosts as two decisions: widget.trustpilot.com on page load is usually defensible, invitations-api.trustpilot.com deserves its own line in the record of processing and, on most implementations, its own gate.

Common debugging scenarios

• The widget renders empty or shows no reviews. Confirm the bootstrap request succeeds, then check the widget iframe request for the business unit id and locale it was given.
• Invitations are not being created. Check that the invitejs.trustpilot.com script is present on the confirmation page and that an invitations-api.trustpilot.com POST actually fires. A widget-only install has no invitation traffic at all.
• Customer email is visible in a request. Open the invitation body and confirm the fields are the ones intended, and that this transfer is disclosed.
• Invitations fire on the wrong page. Group the stream by Page: invitation traffic outside the confirmation step means the trigger is too broad.
• Trustpilot loads before consent. Filter to Trustpilot and read the consent verdict on the first request of each host.