Capture response details

Record response bodies, headers, and timings for diagnostics.

Use Capture response details to save a representative set of request and response data from your test run so that you can debug failures and inspect key successful responses.

Response details show how your application behaves under load. They combine high-level metrics with raw protocol data so that you can trace issues back to individual HTTP calls.

Depending on your preferred method, select any one of the following to capture response details:

captureResponses: true #enable to capture successful and failed response bodies

excluded-success-endpoints: #exclude response capture for specific successful requests
  - path: "/checkout"
    methods: ["POST"]
  - path: "/login"
    methods: ["POST"]

When you enable response capture, BrowserStack records the following for matching requests:

• Request line and status information, such as HTTP method, URL, response code, and latency.
• Response headers that affect caching, compression, content type, and security.
• Response body samples for supported content types, with large bodies safely truncated when needed.

BrowserStack captures responses for:

• Error responses (4xx and 5xx) to help diagnose failures.
• A limited set of successful responses (2xx) to help validate “happy-path” correctness.

You can use this information to:

• Debug unexpected status codes, timeouts, or spikes in error rates.
• Verify that APIs return the correct payload under load.
• Compare behavior across environments, such as staging and production.

When to enable response capture

Enable response capture in the following situations:

• You are investigating functional issues that only appear under load, such as incorrect responses or partial payloads.
• You need to confirm that backend changes do not break API contracts while the system is under stress.
• You want to correlate synthetic checks or alarms with the exact responses that users received.

For routine baseline or capacity tests, you can disable detailed capture after you validate the scenario. This reduces result size and keeps the focus on high-level performance metrics.

Performance and storage considerations

Capturing response headers and bodies increases the amount of information stored for each test run. To keep storage predictable:

• Up to 20 response bodies are stored per test run, across both successful and error responses.
• Response bodies are retained for 14 days and then deleted.
• You can download response bodies locally if you want to retain them beyond 14 days.

To balance visibility and efficiency:

• Prefer short, focused runs with capture enabled, and then repeat longer load runs with capture disabled once you validate the scenario.
• For browser load tests, BrowserStack only captures XHR responses. This helps avoid targeting large static assets, such as images or binary files, because they rarely help with API debugging and can increase storage use.

BrowserStack may truncate very large bodies or skip unsupported content types to keep test execution fast and results manageable. If a specific response body is no longer available, you may see messaging such as Req/Response details unavailable in the report.

Exclude endpoints from 200 OK capture

Some 2xx responses may contain sensitive data, such as personal identifiers, tokens, or user profile details. You can exclude 10 specific endpoints so that their 200 OK response bodies are not captured, while still allowing error responses for those endpoints to be recorded within the same run limits.

Configure endpoint exclusions in the UI or CLI using the options described in the preceding tabs.

Data privacy recommendations

Response details can contain sensitive information. Follow these guidelines:

• Use test data wherever possible, and avoid sending secrets such as access tokens, passwords, or personal identifiers in responses.
• Combine response capture with any masking or redaction features available in your application or test setup.
• Share test results only with teams that need access to payload data for debugging.

If your organization has specific compliance or retention requirements, work with your security team to ensure that captured responses align with those standards.