> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pulseshiga.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```http theme={null}
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`:

```ts theme={null}
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](/backend/errors).