Skip to main content
A compliance report is only useful to an auditor if they can trust it has not been edited since you generated it. Every report OrcaRouter produces carries two things that make that check possible without any account access: a SHA-256 content hash of the canonical evidence and an Ed25519 signature over that hash. This page shows how to verify a compliance report — fetch the public key, confirm the hash, and check the signature — using only public endpoints. The use case is concrete: you hand an auditor a signed report (or a share-portal link), and they need to prove it is authentic and untampered before they rely on it. They never touch your workspace, your key, or the console.

​
1. What travels with a report

Three values make a report self-verifying. They appear on the report artifact and on the public share-portal metadata for the link.
A lowercase hex SHA-256 digest of the report’s canonical evidence JSON. The bytes are deterministic for a given report, so anyone with the same evidence recomputes the identical hash. Any edit to the evidence changes this value.
A base64 Ed25519 signature computed over the hex content_hash. It proves the hash was signed by OrcaRouter’s signing key and not forged.
A short, stable identifier for the active public key (for example orca- followed by a hex fragment). The verifier uses it to confirm the report was signed by the key currently published — a report signed by an unknown key id fails closed.
The signature covers the content hash, not the rendered PDF, CSV, or JSON bytes directly. The same evidence renders to all three formats from one hash, so the integrity guarantee is on the underlying evidence — every export of a given report shares one content_hash, signature, and sig_key_id.

​
2. Fetch the public key

The signing public key is published at an open endpoint — no auth, no workspace context. An auditor calls it directly. 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
The public_key is the base64-encoded 32-byte Ed25519 public key. The key_id here must match the sig_key_id on the report — if it does not, the report was signed by a different (likely rotated or older) key and will not verify against this published key.

​
3. Verify the signature

You can verify the signature two ways. Either ask OrcaRouter to check the tuple for you, or verify entirely offline with the published public key.

​
The hosted verify endpoint

POST the three values from the report to the open verify endpoint. It is public — an auditor calls it with no credentials. 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true means the signature checks out against the active key for that key id. valid: false means either the signature does not match the hash, the hash is empty, or the sig_key_id does not match the currently published key.
The verify endpoint echoes back the active key_id. Compare it to the sig_key_id you submitted: if they differ, the report was signed by a key that is no longer the active one, which is why it failed to verify.

​
Verify offline with the public key

A skeptical auditor does not need to trust the verify endpoint at all. Because the algorithm is standard Ed25519 over the hex content hash, the signature is checkable with any crypto library: 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
The signed message is the hex hash string itself, encoded as ASCII bytes — not the raw 32 bytes the hash decodes to. Pass the content_hash value through as-is before signature verification, or the check will fail on a correct report.

​
4. What the signature covers

A signature proves the report’s content_hash was signed by OrcaRouter, and the hash proves the evidence is unedited. One subtlety: the hash is computed over a canonical form of the evidence the gateway builds — not the raw bytes of the JSON or PDF file. So re-hashing the downloaded artifact yourself will not reproduce content_hash. Use the verify endpoint (§2/§3), which recomputes the canonical hash and checks the Ed25519 signature for you:
CheckMeaning
signature_valid: trueThe content_hash was signed by OrcaRouter’s key — evidence is authentic and unedited.
Key id matchesReport sig_key_id == the published key id → signed by the active key.
Both passing means the report is authentic and untampered. A failed signature means the hash, evidence, or key id does not belong to OrcaRouter’s signing key.

​
5. Verifying a shared report

When you send an auditor a share-portal link instead of the file, the portal metadata already carries content_hash, signature, and sig_key_id, plus a server-computed signature_valid flag. The auditor can trust the flag and re-run the checks above against the public key independently — the share portal needs no login, and the verification path is identical.
A shared artifact is only served while its stamped region still matches your workspace’s declared data-residency region. If the region was changed, downloads are withheld even though the signature metadata stays verifiable. This is by design — see Cross-region reads.

​
6. Where to go next

Signed reports

How a signed report is generated, what evidence it captures, and how to mint an auditor share link.

Export evidence

Pull report evidence as PDF, CSV, or JSON for your auditor’s workpapers.

Data residency

How the region stamp on a report governs where it is stored and served.

Shared responsibility

What OrcaRouter guarantees on the gateway path versus what stays yours.
The signing key is OrcaRouter’s; the verification is anyone’s. That split is the whole point — an auditor proves a report is authentic without ever needing access to the workspace that produced it.