> ## Documentation Index
> Fetch the complete documentation index at: https://docs.meshqu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API Reference

> How to read the generated endpoint reference, plus the guarantees that apply to every call

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.

<Info>
  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.
</Info>

Base path: `/v1`. See [Base URLs](../index#base-urls) for environment hosts.

## Authentication

Every authenticated endpoint requires **two headers together**:

```http theme={null}
Authorization: Bearer mqu_<token>
X-MeshQu-Tenant-Id: <tenant-uuid>
```

* `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](../getting-started/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](/api/errors) 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](../guides/verifying-offline) and
[Verification Bundle](../concepts/verification-bundle).