GET /runs/{id}/verify
Server-side verification: re-derives the manifest hash from the stored manifest fields and confirms byte-for-byte match with the recorded seal. Used by the dashboard's "Verify" button and by automated audit tooling.
Request
GET /runs/{id}/verify
X-Verdifax-Key: vfx_...
Response
200 OK, regardless of match outcome:
{
"ok": true,
"verified": true,
"manifest_hash": "6c1428f81519c5bb...",
"recomputed_hash": "6c1428f81519c5bb...",
"verification_at": "2026-04-30T03:35:09.001Z",
"verification_kind": "manifest-self-seal"
}
If the recomputed hash differs from the recorded hash, verified is false and recomputed_hash shows what the manifest actually re-derives to. That's a tamper indicator.
What this proves
The verifier confirms that the recorded manifest fields collapse, under SHA-256, to exactly the recorded ManifestHash. Modifying any field invalidates the hash; this endpoint detects that.
What this doesn't prove
This endpoint runs on the same server that recorded the run. Cryptographically, that's a self-check. For third-party verification — what an auditor wants — re-derive the hash on a different machine using the SDK's verify() method or your own SHA-256 implementation against the canonical manifest preimage.
Example
curl -s http://localhost:9090/runs/42/verify \
-H "X-Verdifax-Key: vfx_..." | python3 -m json.tool
