Verify the evidence chain's integrity
Re-hashes every record in the requested slice and re-checks every link. An edited record fails its content hash; a deleted or reordered one breaks the chain. Long chains verify in slices — when complete is false, continue from throughSeq + 1.
Requires the read scope. A key with less gets 403 insufficient_scope.
Authorization: Bearer tone_live_… or tone_test_…. The prefix IS the environment: a test key reaches only the sandbox, and no request field bridges the two.
In: header
Query Parameters
Start of the slice to verify, inclusive. Defaults to 1 — the beginning of the chain.
^\d+$End of the slice, inclusive. Defaults to the head of the chain.
^\d+$Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/compliance/evidence-records/verify"{ "data": { "brokenReason": null, "checked": 0, "complete": true, "firstBrokenSeq": null, "fromSeq": "1", "throughSeq": "5000", "valid": true, "verifiedAt": "2026-08-31T09:14:22Z" }}Sealed evidence records, newest first
One tamper-evident record per call attempt — completed calls AND refused dials. Each carries the full basis on which the attempt was allowed or refused, hashed and chained to its predecessor so any alteration, deletion or reordering is detectable.
One event, with its payload re-rendered from current state
⚠️ The payload is RE-RENDERED from the resource as it stands now, not replayed from the signed bytes that were delivered. A transcript that landed after delivery will be present here and absent from what your endpoint received. Use it to understand an event, not to re-verify a signature.