Skip to main content
MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement. The contract described below is the one those deployments serve.
The endpoint pages in this section are generated from the committed public OpenAPI snapshot (api/openapi.json). It selects customer-facing operations from the API’s validated schemas. Consult the current release notes alongside this reference when integrating with a deployment.
The machine-readable public snapshot is api/openapi.json in this docs repository. This reference covers the operations documented for customer use.
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. Measure latency in your own deployment and set timeouts and fallback strategies for your application.

​
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 the verdict, marked result.dry_run: true. The result is not signed — no signature, signature_kid or signature_algorithm is emitted, and those fields are absent rather than null. It is a preview, not a receipt: integrity_hash is reproducible, so you can recompute it yourself, but nothing attests to it. No decision is recorded — no decision id is returned and nothing is retrievable as a decision afterwards. Resolving the active policies may still persist a reusable policy snapshot and return its policy_snapshot_id; when an existing snapshot matches, no new snapshot is created.
  • POST /v1/decisions/record — evaluates and persists the result. Supply 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 an x-correlation-id header. 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 must use public keys or fingerprints authenticated through an independent channel and pinned according to their own policy. The API’s GET /v1/.well-known/signing-keys document and a bundle’s trusted_keys.json are issuer-provided discovery material, not independent trust roots. Key standing also requires a verified signed trust registry, which is not currently published. See Verifying offline, Verification Bundle, and the Receipt Reference.