Skip to main content
Every request to the MeshQu API (except health and readiness checks) requires two headers:

API keys

API keys are created via the /v1/api-keys endpoint (requires the api-keys:admin scope) or through the MeshQu Console. When you create a key, the plaintext value is returned exactly once. Store it securely — it cannot be retrieved again. The API stores only a hashed representation. Each key has:
  • Name — a human-readable label for audit trails.
  • Scopes — the set of permissions the key grants (see below).
  • Expiry (optional) — an expires_at timestamp after which the key is rejected.
  • Prefix/suffix — a safe fragment (e.g. mqu_...c123) shown in dashboards for identification.
Keys are mqu_ followed by a base64url-encoded random token (e.g. mqu_EXAMPLEKEYdonotuse_replace_with_ownx_abc123). There is no environment segment such as _live_ or _test_ — a single key format is used everywhere.

Revoking a key

Revoked keys are rejected immediately. Revocation is permanent.

Scopes

Each API key carries one or more scopes that control what it can access:
A tenants:provision scope also exists for cross-tenant operator keys, but it is not grantable through the API — an api-keys:admin key cannot mint itself one. It is assigned out-of-band by MeshQu operators only.
Principle of least privilege: create separate keys for different services. A service that only evaluates decisions needs decisions:evaluate — not api-keys:admin.

Multi-tenancy

All data in MeshQu is isolated per tenant. The X-MeshQu-Tenant-Id header determines which tenant’s data is accessed. The API key must belong to the specified tenant; a mismatch returns 403 Forbidden.

Rate limits

MeshQu applies two tiers of rate limiting: When a limit is exceeded the API returns 429 Too Many Requests with a Retry-After header. Standard rate-limit headers are included on every response:

Example: creating an API key

Response (key shown once):
Store the key value immediately — it will not be returned again.