# Fetch a call's sealed evidence record

Source: https://docs.usetone.ai/reference/calls/evidence

> The tamper-evident evidence document for this call: the legal basis it was placed on (DNC, consent, carrier signal), how it was placed (DLT registration, A2P declaration, calling window, AI disclosure), the outcome, and the hash-chain seal.

`GET /v1/calls/{id}/evidence`
The tamper-evident evidence document for this call: the legal basis it was placed on (DNC, consent, carrier signal), how it was placed (DLT registration, A2P declaration, calling window, AI disclosure), the outcome, and the hash-chain seal. Available shortly after the call ends.

Requires the `read` scope.

## Parameters

| Name | In | | Meaning |
|---|---|---|---|
| `id` | path | required | The call's id. |

## Response

| Field | Type | | Meaning |
|---|---|---|---|
| `callId` | string | null | required | The call this record seals. Null for a blocked dial, which never created a call. |
| `campaignId` | string | null | required | The campaign, when the attempt belonged to one. |
| `chainSeq` | string | required | Position in your organisation’s evidence chain, from 1. Also the list cursor. |
| `content` | object | required | The evidence document itself — call identity, the legal basis to call (DNC result, consent record, scrub token, carrier signal), how the call was placed (DLT PE ID, A2P declaration, calling window, number status at dial time, AI disclosure), and the outcome. This is exactly the document `contentHash` covers. |
| `contentHash` | string | required | sha256 (hex) of the canonical serialisation of `content`. Recompute it to prove the document was not altered. |
| `e164` | string | required | The number the attempt was about, in E.164. |
| `id` | string | required | The sealed record’s id. |
| `kind` | string | required | What kind of attempt this seals. Open set — handle an unrecognised value rather than throwing. Today: `completed_call`, `blocked_dial`. |
| `prevHash` | string | required | The previous record’s `recordHash` — 64 zeros for the first record. What makes deletion and reordering detectable, not just edits. |
| `recordHash` | string | required | sha256 (hex) of `contentHash + prevHash` — the seal. |
| `sealedAt` | string | required | When the record was sealed, RFC 3339 UTC. Also inside `content`, covered by the hash. |

### Example response

```json
{
  "data": {
    "callId": "9f1c2d84-4e3a-4f6c-b902-7d1e8a33c451",
    "campaignId": null,
    "chainSeq": "4211",
    "content": {},
    "contentHash": "a3f1…",
    "e164": "+919876543210",
    "id": "9f1c2d84-4e3a-4f6c-b902-7d1e8a33c451",
    "kind": "completed_call",
    "prevHash": "0000…",
    "recordHash": "b7e2…",
    "sealedAt": "2026-08-31T09:14:22Z"
  }
}
```