Skip to main content
When an auditor asks “prove your AI traffic is governed,” you don’t want to screenshot a console. OrcaRouter turns your live guardrail and firewall posture into a signed, publicly verifiable evidence report mapped to a regulatory framework — SOC 2, HIPAA, GDPR, the EU AI Act, and more. This page is the API surface for that workflow: how to browse the catalog, install a pack, generate a report, and let an auditor verify the signature without an OrcaRouter account. Compliance is the third plane in OrcaRouter’s control stack, alongside Guardrails (text) and the Firewall (tool calls). A compliance pack is just a pre-authored bundle of those two — installing one materializes a real, editable guardrail and firewall policy in your workspace.
All /api/compliance/* routes authenticate with your console session / access token (the same login you use for the dashboard), not a sk-orca-… relay key. Configure everything from the console; the REST surface below is for automating evidence collection in CI.

​
1. What the compliance api reference covers

Two route groups, two audiences:
GroupAuthAudience
/api/compliance/*Console sessionYou + your auditors (in-workspace)
/api/public/compliance/*None (token / signature)Anyone verifying a report
Reads in the first group — browsing the catalog, installed packs, readiness, residency, and report metadata — are open to every workspace member and free. Every write (installing a pack, going live, generating or downloading reports, changing residency, sharing) requires workspace Admin (server-enforced). A paid plan is additionally required to install a pack, take it live, and export CSV/JSON or generate more than the one free report — but not to change residency or generate your first PDF.

​
2. Browse the catalog and check readiness

Start read-only. These three endpoints need no special role and cost nothing:
Returns the framework registry. OrcaRouter ships packs for the major security, privacy, and AI-governance regimes — including soc2, hipaa, gdpr, uk_gdpr, eu_ai_act, iso_27001, iso_42001, nist_ai_rmf, nist_800_53, pci_dss, glba, ccpa, and a long tail of regional privacy laws (PIPL, APPI, PIPA, LGPD, PIPEDA, DPDP, and the US state acts). OWASP Top 10 for LLM Applications (owasp_llm) ships as a first-class pack too — it materializes real guardrail and firewall controls (prompt injection, insecure output, sensitive disclosure, excessive agency) just like every other framework.
Lists the packs already materialized in this workspace, each with its lifecycle mode (observe or enforce) and the guardrail + firewall policy it created.
Scores your current posture against each framework’s checklist: which controls your live guardrails and firewall rules already satisfy, and which are still organizational gaps you must close yourself. Read this before you install anything.

​
3. Install a pack

Installing a pack is the value moment: it writes a real Guardrail (text/data plane) and a WorkspaceFirewallPolicy plus rules (tool-call plane) into your workspace, tagged to the framework. Both are fully editable afterward — the pack is a starting point, not a locked template. 
# Admin + paid plan. Installs in observe mode first.
curl -X POST https://api.orcarouter.ai/api/compliance/packs/soc2/install \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"
New packs land in observe mode — guardrail actions coerced to flag, firewall in shadow/log-only — so you can watch coverage before anything blocks live traffic. When you’re ready, promote it: 
curl -X POST https://api.orcarouter.ai/api/compliance/packs/soc2/golive \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"
golive flips the materialized guardrail and firewall policy into enforcement. Run it after reviewing the enforcement modes so you know exactly what deny and mask will do to live traffic.
Other pack writes (all Admin): POST …/packs/:key/controls to wire a single control, POST …/packs/:key/update to re-sync after the catalog changes, and DELETE …/packs/:key to uninstall.

​
4. Generate a signed evidence report

The report is the artifact you hand an auditor. Each one is rendered from your live posture, content-hashed with SHA-256, and signed with Ed25519 so it can’t be silently edited after the fact. 
curl -X POST https://api.orcarouter.ai/api/compliance/reports \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"framework":"soc2","format":"pdf"}'
Formats are pdf, json, and csv.
Your first PDF report is free so you can demo the artifact. CSV/JSON export and additional reports are part of the paid plan — the report is the sellable evidence, so the gateway returns a friendly upgrade message rather than a hard error when you hit the free cap.
List and fetch reports with GET …/reports and GET …/reports/:id; download the rendered file with GET …/reports/:id/download (Admin).

​
5. Let an auditor verify it — no account required

Three public endpoints make a report independently checkable by anyone holding the file:

Get the public key

GET /api/public/compliance/pubkey returns the Ed25519 public key your reports are signed with.

Verify a signature

POST /api/public/compliance/verify checks a report’s signature and content hash and tells the caller whether it’s been tampered with.

Share with an auditor

Mint a read-only link from POST …/reports/:id/share (Admin); the auditor opens GET /api/public/compliance/share/:token — no login.
Because verification is public and offline-checkable, an auditor never touches your workspace or your traffic — they confirm the cryptography and read the evidence.

​
6. Data residency

Residency here is the region your compliance evidence is stamped and stored under — us, eu, uk, ap, cn, or global. It governs where reports live and from which region they may be served; a report is withheld if read from a non-matching region. (This is an evidence-artifact control, not geo-pinning of your inference traffic.) 
curl -X PUT https://api.orcarouter.ai/api/compliance/residency \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"region":"eu"}'
Read the current setting with GET …/residency (any member); changing it is Admin.

​
7. Retention, erasure, and audit

The compliance plane is backed by the same data-lifecycle guarantees that apply across the gateway:
Request logs are kept 30 days by default and 180 days maximum — the gateway clamps anything longer. Retention feeds directly into your readiness score.
An account-deletion request opens a 30-day grace period (the default), after which the account’s PII is irreversibly scrubbed: the cascade redacts the identifiers on retained request logs and purges the user-scoped guardrail matches, firewall events, and agent-trace records.
A compliance report’s change-log section is drawn from the workspace audit log, scoped to the report period. Member and admin emails are masked by default in the exported report (e.g. j•••@acme.com) unless full PII is explicitly requested at generation time. See the audit action catalog.

​
Where to go next

Guardrail API

The text/data-plane policy a compliance pack materializes.

Firewall API

The tool-call policy plane the pack writes alongside it.

Control stack

How guardrails, firewall, and compliance compose into one posture.

Error codes

Every status the gateway can return, including paywall and role gates.
For term definitions — compliance pack, signed report, data residency, right to erasure — see the concepts glossary.