How to Verify a Zero-Log AI API? A Four-Category Data Retention Checklist

Many teams assume that sending a few test requests and capturing packets can prove whether a provider stores your prompts, but that's impossible. Judging whether a zero-log AI API can be verified requires a three-layer approach: "field-level commitments + contractual constraints + observable behavior cross-check." Any client-side probing alone is insufficient. Especially after the recent acquisition of a major aggregator gateway by a payment infrastructure company (official announcement, August 2026), token metering is rapidly integrating into payment and financial systems. This means the retention boundaries between "billing metadata" and "call content" need to be re-confirmed item by item, rather than trusting a blanket "we don't store data" statement.

Conclusion First: Whether Zero-Log Can Be Verified Depends on Which Data Category You Ask About

Judging whether a zero-log AI API can be verified depends on the data category in question. "Zero-log" is not a single switch but a set of tiered commitments. Strictly speaking, whether the server immediately erases Prompt and Output content after inference completes cannot be physically proven from the client side. What you can verify are: how the provider's public documentation defines fields, whether the console allows viewing historical content, and whether request-level mandatory parameters are offered. We can classify data into four categories: request body, model output, billing metadata, and debug/security logs. Each has a completely different verifiability strength.

Four Data Categories: Request Body, Model Output, Billing Metadata, Debug & Security Logs

To make "zero-log" operational, mainstream gateways commonly adopt layered governance. A typical example is OpenRouter's official privacy documentation (2026-06), which states: by default, Prompt and Completion content are not stored, only metadata like token count, latency, model name, and timestamp are recorded for billing and troubleshooting. Content retention requires user opt-in, and the API supports passing zdr: true to enforce zero retention and filter out providers that retain downstream data. Based on this, the retention motives and risk levels for the four categories are as follows:

Statements like "we don't store data" are meaningless; you must ask for specifics about which fields are retained for each category.

What Can You Verify Yourself vs. What Depends on Terms: Three Actions and One Hard Boundary

When evaluating a zero-log AI API, you can perform three cross-verifying actions before signing:

1. 【Self-verifiable】 Check the model field in the response body to confirm the actual model executed matches the one specified in the request, preventing silent downgrade/replacement. This is also part of field-level commitments.
2. 【Self-verifiable】 Check whether the console allows you to view historical request bodies. If it does, that indicates server-side persistence. If the console only shows token count, latency, status code, etc., it aligns with "not storing content."
3. 【Observable but not proof】 Check if request-level retention switches are provided. For example, some gateways offer a request-level zero-retention parameter (e.g., zdr: true) that enforces zero retention at the request level and filters out providers that don't commit. If a provider lacks such a parameter, it at least signals that "zero-log" isn't productized.

【Completely unverifiable externally】 After TLS decryption, "in-memory discard" and "persistent storage" appear identical to the client. Any claim that "sending a few requests proves nothing is stored" is false.

Reasonable Boundaries for Billing Metadata: Request ID, Model Name, Token Count, Timestamp, Status Code – and What Else?

Billing metadata is an inevitable part of zero-log services, but the collected set should have a reasonable upper limit. The following fields are typically considered the "minimal necessary" set:

• Request ID (for bill and troubleshooting correlation)
• Model name (to distinguish call tier)
• Token count (input/output)
• Timestamp
• Status code (success/failure)

Any fields beyond this set warrant questioning, such as: prompt summaries, cached content fragments, and links between user identifiers and original content. A truly compliant approach is to include the field list in the contract appendix.

You can copy this question template directly to providers: "Please list, by field name, all fields you actually persist for each API call. If you include prompt summaries, cached content fragments, or links between user identifiers and original content, please explain the purpose, retention duration, and deletion triggers."

One Extra Hop Means Two Accounts: Separately Confirm Upstream Model Provider Retention and Gateway Retention

In a relay chain, the gateway has its own retention policy, and upstream model providers have their own – they are two independent commitments and must be confirmed separately in writing. Also, note the distinction between "stateful features" and "stateless API": OpenAI's Zero Data Retention upgrade notice (official announcement, August 19, 2026) explicitly states that stateless inference APIs erase content immediately after request completion, but stateful features like Vector Store and Threads are not covered. So, don't just rely on a provider's overall "zero-log" claim; evaluate per feature module.

Three Clauses Worth Re-Confirming After Billing and Financial System Integration

After the acquisition of a major aggregator gateway by a payment infrastructure company (official announcement, 2026-08-19), token routing and financial settlement are deeply integrated. Although the official statement claims independent operation and neutral routing, enterprise customers have reason to re-confirm three clauses:

1. Whether billing-side metadata is linked to call content: For example, does the bill detail include prompt summaries or content fragments? The original gateway documentation said content wasn't stored by default, but after integration into the payment system, the possibility of new financial fields needs written confirmation.
2. Notification and effective mechanism for retention policy changes: For instance, if metadata retention duration changes, will customers be notified via email 30 days in advance? If not specified, it's as good as no commitment.
3. Whether data processing commitments continue under change of control: After the acquisition, do the original data protection commitments remain valid, or is a new DPA required?

In today's M&A wave, putting "zero-log" commitments into DPA/SLA is more important than ever.

Pre-Contract Written Commitment Checklist and Trial Period Verification Order

Instead of relying on verbal assurances from zero-log AI API providers, send the following checklist to candidate providers and demand written responses item by item:

• Field-level retention enumeration: List which fields are retained for request body, model output, metadata, and logs
• Retention duration and deletion mechanism: Especially for metadata and logs – the number of days and deletion triggers
• Sub-processor list: Which upstream model providers and cloud vendors will have access to data
• Retention policy change notification period: How many days, and via what channel
• Access scope for incident logs: Who can access, can they be exported, and is there an audit log?

A comparable reference is NexAIX's public zero-log policy: it explicitly does not record prompts or completions, only retains billing/troubleshooting metadata (request ID, model name, token count, timestamp, status code), uses the response body's model field to ensure actual execution matches the request, and returns a standard 429 when overloaded rather than silently downgrading. Such item-by-item statements are far more contract-friendly than "we don't store data." Of course, always refer to the official website's current terms.

Paste the field checklist above into your procurement questionnaire and request written responses from each candidate. For a sample wording, you can refer to NexAIX's current data processing terms and API documentation on their official website, as the official version prevails.

Suggested trial period verification order: Read privacy terms → Compare official documentation → Observe retrivable fields in the console → Run small-scale load tests to record status codes and model field consistency. For more on how to choose an AI relay station, refer to its data retention transparency; if you find the response body model differs from the request, also be wary of common watering-down tactics in AI relay stations.

FAQ

Will the AI API save my prompt?

Depends on the provider. OpenRouter's official privacy documentation (June 2026) states it does not store Prompt or Completion by default; other providers may differ. The determining factor is whether they can provide a written answer on three items: whether content is retained, for how long, and who has access. If they cannot provide a field-level written response, treat it as "they retain."

How long does large model API data persist?

There is no uniform answer, and no industry-standard number of days can be cited. What we can confirm from available materials: OpenRouter by default does not store content, only metadata (official docs, 2026-06); OpenAI's frontier model ZDR erases content immediately after stateless request completion, but stateful features like Vector Store and Threads are excluded (official announcement, 2026-08-19). The specific retention days for metadata must be obtained from each provider in writing; do not speculate.

What metadata is recorded when calling an AI API?

Common fields include request ID, model name, token count, timestamp, and status code. If a provider records extra fields (e.g., precise location from user IP), ask for the reason and retention duration.

Is it true that relay stations are zero-log?

Partially true. The key is whether they distinguish between "content" and "metadata" commitments, and whether they provide request-level mandatory parameters (e.g., zdr: true). If they only give verbal statements without a field list, be suspicious.

What should enterprises ask for API compliance?

At minimum, ask five things: whether content is retained, the metadata field list, retention duration and deletion mechanism, sub-processor list, and policy change notification period. All should be put in writing and included in the DPA. For more, see the AI API selection checklist.