zenture Developer Docs

V1 supports personal user-bound tokens only. Tokens are scoped to the user who created them and are evaluated by backend-owned authorization and billing rules.

Policy summary:

• Default expiry: 90 days.
• Maximum expiry: 365 days.
• Maximum active tokens: 10 active tokens per user.
• Token secret display: one-time reveal at creation or rotation.
• Token names: encrypted at rest.
• Expiry reminder: 7-day expiry notification through the internal zenture notification system.
• Revocation: after revocation is accepted, the token cannot create new jobs, poll operations, or read billing/usage.
• Rotation: create or rotate to a new token, deploy the replacement secret server-side, then revoke the old token.

Use the smallest required scope set. Keep token names descriptive but non-sensitive; do not include customer data, prompts, access tokens, or incident details in names.

API token management is handled in the zenture web app profile. These public docs only cover unauthenticated checks and API-token server-to-server requests.

Mutating async routes return operation objects instead of final domain results. Current async mutation routes are:

• POST /v1/chat (postV1Chat)
• POST /v1/evaluate (postV1Evaluate)
• POST /v1/input-wizard (postV1InputWizard)

Poll the operation with:

curl -sS https://api.zenture.app/v1/operations/<OPERATION_ID> \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"

Operation polling is token-bound. A token can poll operations created for that token; another token must not assume access to the same operation id.

Polling TTL is 24 hours. After expiry, the public API returns operation_expired.

Statuses:

• queued: accepted but not started.
• running: accepted and in progress.
• succeeded: terminal success; inspect the safe result projection.
• failed: terminal failure; inspect error.code.
• cancelled: terminal cancellation.
• expired: terminal expiry.

Client behavior:

• Poll with backoff.
• Honor Retry-After and RateLimit-Reset when rate limited.
• Stop polling on terminal statuses.
• Do not treat running as success.
• Do not send prompts, model answers, provider payloads, or tokens in operation ids or idempotency keys.

Completed chat and evaluation operation results include amount_billed when the billing ledger debit is available. The value is a user-facing zenture credit amount, for example {"amount":"4.41","unit":"credits"}; internal ledger subunit names are not exposed.

Public Runs

The canonical Run surface uses the same API-token boundary. Use POST /v1/runs/prepare with evaluation:run for an expiring proposal and then POST /v1/runs with its proposal_id and proposal_hash. Add the optional predecessor_run_id to link the new Run to one of your finished Runs; it is part of the request identity for the Idempotency-Key, and an unknown or foreign Run fails with predecessor_run_invalid. Prefer: wait=0..15 is only a transport hint; it never changes admission, billing, ordering, or idempotency. Every mutation requires an Idempotency-Key.

For file-backed Runs, the supporting routes are POST /v1/run-artifacts/signed-upload and POST /v1/run-artifacts; both use evaluation:run and return only bounded artifact/upload projections.

Use GET /v1/runs/{run_id} for the owner-bound summary or explicit safe full projection, POST /v1/runs/{run_id}/cancel for cancellation, and POST /v1/runs/{run_id}/outcome for explicit used, edited, rejected, escalated, or not_sure feedback. Feedback is accepted for any terminal Run (completed, failed, cancelled, expired or budget_exhausted). GET /v1/runs/{run_id}/events provides bounded replay and GET /v1/runs/{run_id}/events/stream provides replay-then- live SSE with an opaque Last-Event-ID; disconnect never cancels a Run. New successful Product Runs report completed only after settlement. Historical Run responses may still contain succeeded; async Operations continue to use succeeded for terminal success.

Operation endpoint:

• GET /v1/operations/{operation_id} (getV1Operation) uses auth mode api_token.

Evaluation operations:

• POST /v1/evaluate requires user_message and ai_answer.
• New external evaluations may include external_id and bounded metadata for safe caller correlation.
• External evaluations must omit chat_id, turn_id, and model_response_id.
• Internal zenture chat-answer evaluations must include the AI-answer model_response_id.
• chat_id and turn_id are optional internal correlation fields, but if either is supplied, model_response_id is required.
• Invalid internal targets return 422 validation_failed before an operation is created or credits are checked.
• To evaluate a zenture chat answer, create or continue a chat, poll the chat operation, keep the returned chat_id, turn_id, and AI-answer model_response_id, then send those ids with the same user_message and ai_answer text to POST /v1/evaluate.
• To evaluate an answer produced outside zenture, omit chat_id, turn_id, and model_response_id; the evaluation is stored as an external evaluation-only record and does not appear in chat history.
• Use GET /v1/evaluations/{evaluation_id} after completion for detailed evaluation fields: zenture_summary, zenture_suggestion, zenture_kpi_details, results, and sources.
• sources is grouped by model. Source rows can include status/retrievalStatus values such as available, limited, unavailable, and unverified, plus httpStatus, verdict, url, hostname, securityLabel, accessibilityScore, and responseTimeMs when available.

Internal zenture chat-answer evaluation:

curl -sS https://api.zenture.app/v1/evaluate \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_EVALUATION_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "user_message": "<USER_MESSAGE_FROM_CHAT_TURN>",
    "ai_answer": "<MODEL_ANSWER_FROM_CHAT_TURN>",
    "chat_id": "<CHAT_ID>",
    "turn_id": "<TURN_ID>",
    "model_response_id": "<MODEL_RESPONSE_ID>"
  }'

External answer evaluation:

curl -sS https://api.zenture.app/v1/evaluate \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_EXTERNAL_EVALUATION_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "user_message": "<EXTERNAL_USER_MESSAGE>",
    "ai_answer": "<EXTERNAL_AI_ANSWER>",
    "external_id": "<YOUR_CORRELATION_ID>",
    "metadata": {"source": "your_app"}
  }'

Local smoke includes an explicit POST /v1/evaluate check only when ZENTURE_SMOKE_ENABLE_EVALUATE=true is set, because live evaluation scheduling can create billable evaluation usage.

API-token routes use:

Authorization: Bearer <ZENTURE_API_TOKEN>

API tokens are server-side credentials only. Store them in a secret manager or protected server environment. Do not use them in browsers, mobile apps, client-side JavaScript, public repositories, logs, notebooks with shared output, or customer-visible error reports.

Create and manage user API tokens in the zenture app profile: https://ai.zenture.app/profile?tab=api-tokens.

Current auth modes:

• none: public unauthenticated route, currently GET /v1/helloworld.
• api_token: personal API token presented with Authorization: Bearer <ZENTURE_API_TOKEN>.

If a token is exposed, revoke it immediately and rotate any dependent automation to a new token.

Public API usage is user-bound. Backend-owned wallet and usage attribution decide what a token can see and how usage is counted.

Current routes:

• GET /v1/wallet (getV1Wallet) uses auth mode api_token and scope wallet:read.
• GET /v1/usage (getV1Usage) uses auth mode api_token and scope usage:read.

Usage defaults to API-token scope:

curl -sS "https://api.zenture.app/v1/usage?scope=api" \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"

wallet.get() exposes plan, status, and available credits. usage.get() exposes operation counts only; it is not a credit ledger.

scope=all returns the broader user-bound usage view when the backend authorizes it. The public projection does not expose raw billing internals, payment identifiers, provider payloads, or token material.

Current V1 Contract

The current V1 public contract is represented by openapi/zenture-public-api-v1.openapi.json and the generated artifacts under docs/generated/.

1.0.0-rc.3

OpenAPI version: 1.0.0-rc.3.

This release candidate stabilizes V1 OpenAPI for client generation, generated developer docs, and partner-beta review. It keeps public servers as origins, keeps public paths under /v1/..., includes POST /v1/evaluate as an async API-token mutation, and exposes GET /v1/models for API-token-scoped public model availability.

Operation status enum is fixed to queued, running, succeeded, failed, cancelled, and expired. Public error envelopes require top-level request_id and error.code; validation failures use validation_failed.

POST /v1/evaluate is client-ready as a service-authoritative public API workflow. The backend schedules evaluation without fake user sessions or empty Supabase tokens, uses a trusted backend-owned public API marker for tokenless consumer authority and requeue correlation changes, and emits retryable billing reconciliation events instead of silently falling back to free billing on public API billing dependency failures.

POST /v1/chat supports public single and multi modes. agentic is not an accepted V1 public value and requires a later security and billing review before any public API or client surface. Model IDs are backend-authoritative through GET /v1/models; clients must not guess provider IDs or rely on provider routing metadata.

1.0.0 is not released yet. Promotion to stable still requires local live smoke with API token, INT smoke, CTO approval, and a final no-breaking-fix stabilization window.

Breaking V1 behavior changes require /v2 or explicit deprecation. Partner-facing V1 deprecations require at least 180 days unless there is a Security Emergency. Non-breaking changes may add optional response fields, optional query parameters, new endpoints, or new error codes for new failure modes.

Included route families:

• Helloworld and limits.
• Chat create and read/history routes.
• Public model availability reads.
• Input wizard async mutation.
• Evaluation async mutation.
• Operation polling.
• Billing and usage reads.
• Evaluation read/status projections.

Error responses use a stable public envelope:

{
  "error": {
    "code": "validation_failed",
    "message": "The request is invalid."
  },
  "request_id": "req_00000000000000000000000000000000"
}

Do not parse internal exception text. Use error.code, HTTP status, and documented headers.

For Run and artifact operations, send X-Zenture-Error-Details: issues to request safe field validation details. Missing or unknown header values keep the coarse envelope above, preserving clients whose error readers forbid extra fields. The header changes only the error representation; authorization, admission, idempotency, HTTP status, error code/message, request IDs and retry headers retain their existing behavior. Successful responses are unchanged.

When safe details exist, error.issues contains 1–20 deduplicated entries. path is a JSON Pointer to a public argument (for example /task, /edited_artifact_ref, or /Idempotency-Key); an unknown field identifies its nearest known parent, possibly the empty root pointer. category is one of required, invalid_type, invalid_enum, invalid_format, too_short, too_long, out_of_range, invalid_combination, or unknown_field. Optional constraints describe public bounds or allowed values; length units include unicode_code_points, items, bytes, and seconds where applicable. Submitted values, unknown key names and validator context are never included. If no safe issue exists, issues is omitted, never null or an empty array. Clients must handle that omission even after opting in.

For example, a Run prepare request missing task can return:

{
  "error": {
    "code": "validation_failed",
    "message": "The request is invalid.",
    "issues": [{"path": "/task", "category": "required"}]
  },
  "request_id": "req_00000000000000000000000000000000"
}

Current documented error statuses include 400, 401, 402, 403, 413, 422, 429, 431, and 503.

Run-specific codes include proposal_expired, proposal_hash_mismatch, account_required, legal_consent_required, artifact_required, artifact_ambiguous, artifact_unavailable, artifact_not_found, artifact_expired, artifact_type_unsupported, artifact_processing_unavailable, prepare_rate_limited, prepare_capacity_unavailable, too_many_outstanding_runs, capacity_temporarily_unavailable, maintenance_active, engine_unavailable_timeout, capability_unavailable, predecessor_run_invalid, run_not_found, run_terminal, cancel_conflict, budget_ceiling_exceeded, and execution_failed. legal_consent_required (HTTP 403, never retry) means the account has not accepted the current Terms and Privacy Policy; the account owner must sign in to the zenture web app for the same environment and accept them before Prepare or Create can succeed. Use retryable, Retry-After, and the single next_action instead of parsing messages.

Mutating async routes require Idempotency-Key:

• POST /v1/chat (postV1Chat)
• POST /v1/evaluate (postV1Evaluate)
• POST /v1/input-wizard (postV1InputWizard)

Use a stable unique key per logical request. The key comes from the caller's system, not from zenture. A retry with the same key and same request body returns the same accepted operation when the original request was already reserved.

Recommended key shape:

[A-Za-z0-9._:-]+

Use an ASCII-safe caller key such as <system-or-job-id>:<stable-request-id>. Do not put prompts, model answers, customer data, API tokens, PII, or raw request bodies in idempotency keys.

Examples:

support-ticket-123:external-evaluation:v1
case-123:chat-turn-1:v1
case-123:chat-turn-2:v1
response-abc123:evaluation:v1

For zenture client users (Python package zenture), the helper builds the same kind of stable caller-owned key:

from zenture.idempotency import idempotency_key

external_eval_key = idempotency_key("support-ticket-123-answer-a", "evaluate", "v1")
first_turn_key = idempotency_key("case-123", "chat-turn-1", "v1")
follow_up_key = idempotency_key("case-123", "chat-turn-2", "v1")
chat_answer_eval_key = idempotency_key("response_abc123", "evaluate", "v1")

external_id is separate from Idempotency-Key. external_id is an optional caller correlation id stored with an external evaluation; Idempotency-Key is the required retry-safety key for the mutation.

Conflict behavior:

• Same key and same request body: safe retry path.
• Same key and different request body: idempotency_conflict.
• Missing key on required routes: missing_idempotency_key.

Idempotency is a client safety mechanism, not a substitute for authorization. Backend ownership and token binding still apply.

GET /v1/models returns the model IDs and public modes available to the authenticated API token.

Required scope: models:read.

Optional query:

• mode=single
• mode=multi

agentic is not public in V1 and is not an accepted query or chat request mode.

The response is a bounded public projection. It does not expose provider routing config, internal prices, backend paths, raw model config, secrets, or private metadata. Use returned id values with POST /v1/chat.

Chat model selection:

• Omit mode for backend-owned single default behavior.
• For single, send optional model.
• For multi, send models with 1 to 3 unique model IDs.
• Do not send both model and models.

List routes use cursor pagination. Only documented cursor behavior is part of the V1 contract.

Cursor-enabled routes:

• GET /v1/chats (getV1Chats)
• GET /v1/chats/{chat_id}/messages (getV1ChatMessages)
• GET /v1/evaluations (getV1Evaluations)

Query parameters:

• limit: optional integer, default 50, minimum 1, maximum 100.
• cursor: optional opaque cursor returned by the previous page.

Results are ordered by created_at desc. Use the returned cursor as an opaque value and send it unchanged. Do not construct cursors client-side.

Each collection response includes next_cursor. A string value means another page may be requested with cursor=<next_cursor>. next_cursor: null means there is no further page.

GET /v1/runs is newest-first, owner-bound keyset pagination with limit=1..50 and an opaque cursor. Supported filters are status, decision, profile, created_after, and created_before; arbitrary expressions, owner fields, free-text search, and implicit traversal are rejected. Run event replay uses the same bounded cursor discipline, and Last-Event-ID resumes the SSE stream. The status categories are active, completed, failed, and cancelled. completed selects successful Product Runs after settlement. The historical succeeded input remains a deprecated alias for the same success category.

The zenture Public API is exposed under these versioned base URLs:

• Production: https://api.zenture.app/v1
• Integration: https://api-int.zenture.app/v1

Start with a Run

A Run is the primary zenture product surface. It evaluates one selected answer against its task and returns a verdict you can act on. Every Run route requires an API token with evaluation:run for mutations or evaluation:read for reads.

1. Prepare: POST /v1/runs/prepare with a bounded task and exactly one selected

artifact. It returns a proposal; inspect start_admissible, expiry and Credits estimates.

1. Start: POST /v1/runs with the returned proposal_id and proposal_hash.

Both mutations require Idempotency-Key; keep the same key when retrying the same request.

1. Wait: poll GET /v1/runs/{run_id} until the status is terminal, or follow

GET /v1/runs/{run_id}/events and GET /v1/runs/{run_id}/events/stream.

1. Read the result: GET /v1/runs/{run_id}?view=full returns the full result

content, including acceptance_decision (ready, revise, human_review or insufficient_evidence).

1. Cancel if needed: POST /v1/runs/{run_id}/cancel.
2. Record the outcome: POST /v1/runs/{run_id}/outcome with outcome one of

used, edited, rejected, escalated or not_sure.

GET /v1/runs lists your Runs. Over MCP the same flow uses the tools run, get_run, list_runs, cancel_run and record_run_outcome.

curl -sS https://api.zenture.app/v1/runs/prepare \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_PREPARE_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"task":"<TASK>","artifact":{"type":"text","value":"<SELECTED_ANSWER>"}}'

curl -sS https://api.zenture.app/v1/runs \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_START_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"proposal_id":"<PROPOSAL_ID>","proposal_hash":"<PROPOSAL_HASH>"}'

curl -sS "https://api.zenture.app/v1/runs/<RUN_ID>?view=full" \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"

The same flow from Python uses the zenture client (package zenture, https://pypi.org/project/zenture/): pip install zenture, then from zenture import ZentureClient.

Run inputs and file registration

A minimal preparation body is:

{
  "task": "Check whether this answer addresses the question.",
  "artifact": {"type": "text", "value": "The selected answer to evaluate."}
}

task is required, 1–20,000 Unicode code points. Exactly one artifact is required; current evaluation uses text with 1–50,000 Unicode code points. Text starting with http://, https://, data: or file: is rejected case-insensitively; send selected content. Omit profile to use standard. fast uses a shorter execution budget; detailed uses an extended budget and additional review steps. Guest Runs admit fast and standard; detailed requires an account. These restrictions describe service admission; REST Run routes require an API token. task, artifact and any supplied profile cannot be null. Preparation returns a proposal; inspect start_admissible, expiry and Credits estimates before starting it with the returned proposal_id and proposal_hash. Keep the same Idempotency-Key for retries of the same request.

POST /v1/run-artifacts/signed-upload registers an upload intent for a file of 1–10,485,760 bytes; upload its actual bytes with POST /v1/run-artifacts and the returned X-Upload-ID. The declared byte count and lowercase SHA-256 hash must match the complete content. Registration supports plain text, Markdown, JSON, YAML, PDF, DOCX, XLS, XLSX, PNG and JPEG; content validation applies. The upload Content-Type must match the intent's declared media type.

Registration does not enable evaluation. The zenture_ref descriptor remains in the schema, but preparation currently rejects registered-file inputs: textual references return artifact_unavailable, other media types return artifact_type_unsupported. MCP attach_artifact depends on the host's selected file resolver; discover whether it is registered using the actual tools list.

A summary Run read reports status and projections; it does not promise full result content. For interpretation, distinguish technical completion from the acceptance decision, result-content availability and billed Credits. An expired full result is still a successful Run read with unavailable result content. Starting with a predecessor preserves its identity in the request; changing it under the same Idempotency-Key returns idempotency_conflict (409).

Classic resources

The classic resources below (helloworld, models, limits, chat, evaluate) remain available next to Runs.

Use API-token routes only from trusted server-side code:

curl -sS https://api.zenture.app/v1/helloworld
curl -sS https://api.zenture.app/v1/limits \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"
curl -sS "https://api.zenture.app/v1/models?mode=single" \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"

Mutating async routes require Idempotency-Key:

curl -sS https://api.zenture.app/v1/chat \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_UNIQUE_REQUEST_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"message":"<USER_MESSAGE>"}'

Chat Then Evaluate

POST /v1/chat creates or continues a zenture chat. Poll the returned operation_id with GET /v1/operations/{operation_id}. A succeeded single-model chat operation returns safe ids such as:

{
  "result": {
    "result_type": "chat",
    "chat_id": "chat_...",
    "turn_id": "turn_...",
    "model_response_id": "response_...",
    "model_response_ids": ["response_..."],
    "amount_billed": {"amount": "4.41", "unit": "credits"}
  }
}

To continue the same chat, send the previous chat_id:

curl -sS https://api.zenture.app/v1/chat \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_FOLLOW_UP_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"chat_id":"<CHAT_ID>","message":"<FOLLOW_UP_USER_MESSAGE>"}'

To evaluate that zenture chat answer, fetch the chat turn text and evaluate the AI-answer id. model_response_id is the answer id; it is not the user-message id. chat_id and turn_id are optional correlation fields, but if either is sent, model_response_id is required.

curl -sS https://api.zenture.app/v1/chats/<CHAT_ID>/messages \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>"

curl -sS https://api.zenture.app/v1/evaluate \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_CHAT_EVALUATION_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "user_message": "<USER_MESSAGE_FROM_TURN>",
    "ai_answer": "<MODEL_ANSWER_FROM_TURN>",
    "chat_id": "<CHAT_ID>",
    "turn_id": "<TURN_ID>",
    "model_response_id": "<MODEL_RESPONSE_ID>"
  }'

When the evaluation operation succeeds, poll GET /v1/evaluations/<EVALUATION_ID> for detailed results. Completed detail responses can include amount_billed, zenture_summary, zenture_suggestion, zenture_kpi_details, results, and sources. Source rows report statuses such as unavailable, plus fields such as httpStatus and verdict when available.

To evaluate an answer from your own app or another AI system, omit all zenture chat ids, including model_response_id. This creates an external evaluation-only record and does not add the message to normal chat history:

curl -sS https://api.zenture.app/v1/evaluate \
  -H "Authorization: Bearer <ZENTURE_API_TOKEN>" \
  -H "Idempotency-Key: <STABLE_EXTERNAL_EVALUATION_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "user_message": "<EXTERNAL_USER_MESSAGE>",
    "ai_answer": "<EXTERNAL_AI_ANSWER>",
    "external_id": "<YOUR_CORRELATION_ID>",
    "metadata": {"source": "your_app"}
  }'

The committed OpenAPI artifact is the machine-readable contract. Generated artifacts under docs/generated/ are derived from it for later developer-docs consumption.

Rate limits are applied by route policy and cost class. Current cost classes are free_public, polling_read, and expensive_mutation.

Successful public responses include:

• RateLimit-Limit
• RateLimit-Remaining
• RateLimit-Reset

When the limit is exceeded, the API returns 429 with error.code rate_limited and:

• Retry-After
• RateLimit-Limit
• RateLimit-Remaining
• RateLimit-Reset
• X-RateLimit-Limit
• X-RateLimit-Remaining
• X-RateLimit-Reset

RateLimit-Reset is seconds until reset. Legacy X-RateLimit-Reset is retained for compatibility.

Polling discipline:

• Poll GET /v1/operations/{operation_id} (getV1Operation) with backoff.
• Slow down as RateLimit-Remaining approaches zero.
• On 429, wait at least Retry-After seconds.
• Do not run tight polling loops.

Scopes grant the minimum capability required by each API-token route.

Routes with auth mode none do not require scopes. GET /v1/operations/{operation_id} (getV1Operation) is token-bound and does not require an additional domain scope in the current V1 contract.

evaluation:run also authorizes Run artifact attachment, Prepare, Start, cancellation, and explicit outcome feedback. evaluation:read also authorizes owner-bound Run list/get, event replay, and Run SSE. No runs:* scope exists.

Use least privilege for every token. Create separate tokens for separate systems and grant only the scopes required for those systems.

Storage guidance:

• Store API tokens only in server-side secret storage.
• Do not use tokens in browsers, mobile apps, client-side JavaScript, public repositories, logs, notebooks with shared output, or screenshots.
• Do not include prompts, model answers, provider payloads, customer data, or tokens in operation ids, idempotency keys, request ids, or support snippets.

Leak response:

1. Revoke the exposed token.
2. Rotate the affected automation to a new token.
3. Review recent token audit events.
4. Remove the exposed value from logs, notebooks, tickets, or repositories.
5. Contact zenture support with the public request_id values relevant to the incident.

The public API returns stable public errors and request ids. It does not require clients to know storage, signing, or rate-limit key implementation details.