Skip to main content
Pulse Collect doesn’t run telemetry inside your infrastructure — visibility into the integration is something you build around the SDK calls you already make, plus a couple of things Pulse gives you for support correlation.

​
The SDK and embed don’t phone home

@pulsebyshiga/node emits no telemetry from your servers, and the hosted embed doesn’t report back to any sink you own. Instrument the integration the way you would any other outbound dependency: log around your pulse.* calls and the outcomes of onStatusChange / onSuccess / onError, and drive your own alerting off those logs.

​
Identification headers

Every @pulsebyshiga/node request carries an identification header:
This exists so Pulse can measure adoption and error rates per SDK version — it carries no data about your users, orders, or amounts. The hosted embed identifies its own version the same way on the requests it makes directly to Pulse.

​
Correlating with Pulse support

order_id is the business key for a transaction end to end — include it in your own logs and in any support conversation. For request-level errors, every PulseApiError carries a requestId:
Pass requestId (alongside the relevant order_id) when opening a ticket with Pulse — it lets support pull the exact server-side trace for that request. See Error handling.