Response-Body Capture

errorResponseBodies is an account-level capture setting for failed HTTP responses. When it is enabled, the SDK may attach the glasstrace.error.response_body span attribute for 4xx and 5xx responses so the dashboard and MCP tools can show the body that accompanied the failure.

This setting is off by default. Anonymous mode does not retain error response bodies. If the setting is off, missing, malformed, or blocked by an operator override, the ingestion service strips glasstrace.error.response_body before writing the trace.

Why It Is High Risk

Failed response bodies can contain data that the application did not intend to send to Glasstrace, including:

• personal data or other user identifiers
• authentication artifacts such as tokens, cookies, signed URLs, or session hints
• user-supplied content from forms, uploads, prompts, comments, or messages
• application-specific secrets returned by an error handler

Enable this setting only when the account owner is comfortable retaining that data for debugging, has authorization from the affected project or customer, and has reviewed the privacy and deletion impact.

Enable or Disable Capture

Open Account Settings -> Capture Configuration in the dashboard and toggle Capture error response bodies. The SDK reads capture settings during startup through the SDK init call, so restart the development server after changing the setting.

The setting affects new traces only. Existing retained response bodies remain stored until normal retention, erasure, or purge handling removes them.

Operator Disablement

Glasstrace operators can disable retention globally or for one account. The server-side override is authoritative: it strips response-body attributes before trace storage even if an SDK process still has cached opt-in config.

Operators may disable response-body retention when:

• an incident or suspected compromise requires reducing retained sensitive data
• an account owner requests temporary disablement
• captured data appears to include credentials, protected user content, or data outside the intended debugging scope
• legal, security, or infrastructure review requires a pause

An operator disablement does not erase previously retained data. It only stops new response-body retention while the override is active.

Export and Erasure Requests

Account owners can request access or erasure for retained response-body content by contacting support with:

• the account email or account ID
• the identifier to search for, such as an email address, user ID, request ID, or other data-subject identifier
• the requested action: access/export or erasure
• the time window or project context, when available

For access requests, Glasstrace searches the response-body stores for matching content and provides a private export through an operator-controlled process. The export includes matched response-body attributes and any matching derived enrichment text that needs review.

For erasure requests, Glasstrace removes matching glasstrace.error.response_body attributes from stored traces and enrichment context. If matching data appears only in derived enrichment text, the result is escalated because a broader purge may be required.

Operator actions are audited. Audit rows record counts, identifiers by hash, routes, operators, and timestamps; they do not store response-body text.

Data Roles

For end-user data captured inside response bodies, the account owner controls the application and decides whether capture is enabled. Main Street Integrations LLC processes retained response-body content to provide the Glasstrace debugging service.

The public Privacy Policy summarizes this feature’s baseline data handling. Data-processing agreements, account-owner consent copy, and incident notification language still require legal review before production release.