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

# Diagnostic Response Headers

> Distinguish request identifiers from evidence about request effects.

Inspect the response headers as well as the status and error body. Headers can identify a request or add information without changing the response format your origin SDK expects. Different adapters emit different headers; no header listed here should be assumed universal.

## Correlation identifiers

| Header             | Where it is used                                        | What it tells you                                          |
| ------------------ | ------------------------------------------------------- | ---------------------------------------------------------- |
| `x-amz-request-id` | S3 responses.                                           | Identifies an S3-shaped request for correlation.           |
| `x-amz-id-2`       | S3 responses that include the extended identifier.      | Additional S3 response metadata; preserve it when present. |
| `x-amzn-requestid` | AWS-shaped responses including KMS and Parameter Store. | Identifies the request for correlation.                    |

These identifiers do not establish which backend operation ran, whether a write completed or whether a retry is safe. Preserve the exact returned values and correlate them with the relevant adapter logs.

## Request-effect information

`x-tensor9-request-effect` describes a narrowly defined failed-request outcome. The supported value is:

```text theme={null}
x-tensor9-request-effect: refused-nothing-written
```

The adapter is stating that this request was refused before writing anything. The header appears only when the adapter can determine the request effect; its absence means the effect is unknown.

An absent header or an unrecognized value means **the effect is unknown**. A proxy may also omit or replace response headers. Unknown is not equivalent to nothing written: determine the resource state and use the operation's documented retry and idempotency behavior.

The header is not a general description of error provenance. This reference does not define a universal header that tells you whether every error originated in the adapter or its backend.

## Inspect headers from an AWS SDK response

In Python clients that use Botocore response dictionaries, successful responses and a caught `ClientError` expose response metadata. The following helper reads an already captured response; it sends no request:

```python theme={null}
def diagnostic_headers(response):
    metadata = response.get("ResponseMetadata", {})
    headers = {
        key.lower(): value
        for key, value in metadata.get("HTTPHeaders", {}).items()
    }
    names = (
        "x-amz-request-id",
        "x-amz-id-2",
        "x-amzn-requestid",
        "x-tensor9-request-effect",
    )
    return {name: headers[name] for name in names if name in headers}

# For a successful SDK response:
# diagnostic_headers(response)
# For a caught botocore.exceptions.ClientError:
# diagnostic_headers(error.response)
```

An exception caused before a response arrives may have no HTTP metadata. Record that fact instead of treating it as an adapter response. Avoid enabling full wire logging by default: request logs can expose credentials or application data.

Continue with the [debugging workflow](/cloud-adapter/debugging/overview).