Observability

How to get visibility into your Pulse Collect integration: your own logging around the SDK, identification headers, and correlating with Pulse support.

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:

X-Pulse-SDK: pulse-node/<version> node/<node version> (<platform>)

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:

try {
  await pulse.collectionOrders.retrieve(orderId);
} catch (e) {
  if (e instanceof PulseApiError) {
    console.error(e.code, e.message, e.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.