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

# Experimental Response Signatures

> Inspect an available direct-model response signature against exact bytes and a matching model report.

<Warning>
  A signature lookup can return `404` after a direct completion. Treat a missing signature as unavailable; direct response signatures are not a production verification gate.
</Warning>

Use this experimental flow to inspect the signature over exact bytes for a completion sent directly to a model endpoint.

## Preserve exact request and response bytes

Build the request body once and retain the exact bytes sent by the client. Retain the raw response bytes before parsing JSON or Server-Sent Events.

```text theme={"dark"}
request_hash  = SHA-256(exact request-body bytes)
response_hash = SHA-256(exact response-body bytes)
```

Do not parse and re-serialize JSON, normalize whitespace or line endings, omit stream delimiters, or reconstruct a streamed response from parsed events. The signature covers the uncompressed response body. Request `Accept-Encoding: identity`, or hash the body after your HTTP client decompresses it.

## Fetch and verify the signature

Set `<CHAT_ID>` to the `id` in the completion response whose exact bytes you retained.

```bash theme={"dark"}
curl --fail-with-body -G 'https://<MODEL_SLUG>.completions.near.ai/v1/signature/<CHAT_ID>' \
  --data-urlencode 'signing_algo=<SIGNING_ALGO>' \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer <YOUR_NEAR_AI_CLOUD_API_KEY>'
```

Set `<SIGNING_ALGO>` to the explicit algorithm used for the matching model attestation.

For `ecdsa`, recover the Ethereum EIP-191 signer from `text` and `signature`, then compare it with `signing_address`. For `ed25519`, verify the UTF-8 bytes of `text` using `signing_address` as the public key. Reject unsupported algorithms.

Then require that `text` is exactly:

```text theme={"dark"}
<MODEL_NAME>:<request_hash>:<response_hash>
```

Use the `model_name` reported by the direct model attestation. A different string, even if it resembles the hostname or a NEAR AI Cloud gateway model ID, does not satisfy this check. If the report has no non-empty `model_name`, this direct response-signature format cannot be verified.

Use the [manual response-signature helpers](/cloud/verification/reference/response-signature-verification) with the exact request and response bytes, this `model_name`, and the signer from the verified direct model attestation.

## Match the model signer

Request or select a direct model attestation whose `signing_address` and `signing_algo` exactly match the signature. Verify its quote, client-generated nonce, signer binding, and required workload policy as described in [direct model attestation](/cloud/verification/direct/model-attestation). A matching signer does not establish that the report and completion came from the same serving instance.

Do not infer a gateway or model classification from the format of the signed text, and do not substitute a report for a different signer.

`ecdsa` identities are Ethereum-style signing addresses. `ed25519` identities are Ed25519 public-key bytes encoded as hexadecimal. Always compare the identity together with `signing_algo`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.