Data controls

Review the effective data-handling posture for an organization and its projects.

An effective data-handling posture applies to the organization and each project. A value can come from the default policy, organization policy, project policy, contract, or a compliance override. The posture identifies the source and scope of each value and is read-only in the API Platform.

What the posture describes

Policy axis	What it describes
Request metadata	Whether operational fields such as request id, status, model, operation, timing, and cost attribution can appear in Usage, Logs, filters, and exports.
Customer content	Whether customer-provided content can be stored separately from request metadata.
Inference data	Whether inference inputs and outputs can be retained for benchmarks or training.
Request detail retention	Whether new request-level detail is retained and for how long it remains available.
Historical detail	Whether request detail retained before a policy change remains available.
Improve QuiverAI	Whether eligible organization data may be used to improve QuiverAI.

Prompts, request bodies, response bodies, uploads, and generated artifacts are not captured alongside request metadata. A request-detail retention window describes supported access, not proof of physical deletion at its boundary. When policy becomes more restrictive, historical detail can be withdrawn immediately or after the policy change finishes applying.

The one manageable setting is organization consent to Improve QuiverAI. Owner and Admin members can change that consent when it is not contract-controlled. The remaining axes describe the policy in force; they are not editable settings.

Responses API behavior

POST /v1/responses is stateless. Omit store or send store: false. store: true returns 400 invalid_request regardless of organization policy; changing policy cannot enable response storage. There is no stored-response retrieval endpoint.

To continue a conversation, replay the full input history rather than a response ID. Omit previous_response_id or send null; a non-null value also returns 400 invalid_request. See Responses limitations.

These API limitations do not replace the metadata and inference-retention policies above. Caller functions run in your application, so any files or other content they store remain your application’s responsibility.

Runtime policy evidence

Successful attributed API requests include response headers that identify the effective policy:

x-quiver-request-metadata-policy
x-quiver-request-metadata-retention-seconds
x-quiver-payload-capture
x-quiver-inference-data-policy
x-quiver-zero-data-retention

Record these headers with the request id when your integration needs evidence of the policy applied to a request. Their values describe the effective posture; they do not replace your organization’s contract or compliance requirements.

Open Data Controls

Review effective organization and project policy, retention, provenance, and runtime headers.

Policy can reduce or remove information from Usage and Logs.