Skip to main content
The endpoint pages in this section are generated from the live OpenAPI specification (api/openapi.json), which the API builds from the same TypeBox schemas it validates requests and responses against. Paths, methods, parameters, request bodies, and response shapes therefore cannot drift from the running service — when a route changes, the spec (and these pages) change with it.
The machine-readable spec is published at GET /openapi.json on the API, and an interactive Swagger UI is served at /docs when enabled. The pages here are rendered from a committed snapshot of that spec.
Base path: /v1. See Base URLs for environment hosts.

​
Authentication

Every authenticated endpoint requires two headers together:
  • Authorization carries your MeshQu API key as a bearer token. Keys are prefixed mqu_. Mint one in the console (Settings → API keys). This is not an X-API-Key header.
  • X-MeshQu-Tenant-Id is your tenant UUID. It is validated before the API key, so a missing or malformed value returns 400 (MISSING_TENANT_ID / INVALID_TENANT_ID) before authentication runs.
Public verification endpoints (receipts, chain verify/seal/bundle, public form schema and submission) require no auth — they host their own access control. Each endpoint page shows its exact security requirement, derived from the spec. See Authentication for scopes, key lifecycle, and worked examples.

​
Determinism guarantee

Given the same decision context and the same policy snapshot, MeshQu always returns the same verdict. The evaluated_rules_hash and integrity_hash in each response let you verify this independently.
Example: Replaying a decision six months later produces the same verdict as long as the same policy snapshot is used, even if current policies have since changed.
Determinism applies strictly to MeshQu’s policy evaluation logic and snapshot resolution. Client-supplied data and external evidence are outside this guarantee. Evaluations are designed for synchronous use at decision boundaries. Typical policy-evaluation time is single-digit milliseconds, excluding network latency. Clients should still set timeouts and fallback strategies.

​
Evaluate vs record

Two endpoints sit at the core of the API, and the difference matters for audit:
  • POST /v1/decisions/evaluate — dry-run. Evaluates a context against active policies and returns a signed receipt. Nothing is persisted.
  • POST /v1/decisions/record — evaluates and persists the result. Requires an idempotency_key for safe retries.
Both are documented in full under Decisions in the generated pages, with the exact request and response schemas.

​
Errors

Every response carries a correlation_id. Error bodies follow a consistent { error: { code, message, details }, correlation_id } shape. See Errors & Status Codes for the full code catalogue and retry guidance.

​
Public verification & trust roots

The unauthenticated receipt, chain, and bundle endpoints are intended for offline verifiers and counterparties holding a receipt or chain ID. Verifiers should fetch the JWKS at GET /v1/.well-known/signing-keys out-of-band, pin the key fingerprints, and use them as trust roots. The trusted_keys.json file inside an exported bundle is informational only and must not be used as a trust root. See Verifying offline and Verification Bundle.