View as Markdown↗

SDK observability

Observability is documented alongside each SDK so installation, tracing setup, and opt-out instructions use the language and API you are working with.

Server SDKs

• TypeScript
• Python
• Ruby
• PHP
• Go
• Java
• .NET

Mobile SDKs

• React Native
• Flutter

Each page explains how the SDK connects to application-owned telemetry, what it records, and which customer and payment data it deliberately excludes.

Error reporting

The server SDKs also accept an application-owned error reporter. It receives a typed, privacy-safe payload once a logical operation finally fails, so an application can enqueue the report for its existing collector without catching and rebuilding every SDK error itself.

The default policy reports unexpected SDK, transport, timeout, decoding, unknown_error, and server-side failures. Applications can explicitly include expected API failures, but cancellation is never reported. Reporter failures cannot replace the original operation failure.

Reports include bounded operational metadata: SDK language and version, logical operation, static route, server host, HTTP status and request ID when available, duration, safe machine-readable API codes, exception type, stable fingerprint, and trace identifiers when tracing is active. They never include credentials, headers, bodies, resource identifiers, dynamic URLs, exception messages, or stack traces.

Error reporting is completely opt-in. When no reporter is configured, the SDK does not calculate report metadata, generate an event ID or timestamp, allocate a report object, or serialize a payload. Tracing configuration is independent.