Document Processing APIs That Include Zero Data Retention by Default Instead of Charging Extra for It

A healthcare software team connects a document API so it can process patient support tickets. Three months later, during a security review, someone discovers the vendor has been holding those documents, patient names, diagnosis codes, insurance numbers, for 30 days before deletion.

People use zero data retention to describe at least three different architectures in production today, and the differences between them are not small. True zero data retention processes content in volatile memory only: it never touches persistent storage, never enters logs, and never feeds analytics, evaluation, or training pipelines.

The distance between the first tier and the third is a different engineering commitment, and for a document processing API where the payload is a PDF containing payslips, invoices, medical records, or mortgage applications, it is the entire question.

Even a signed ZDR agreement often carries an exception clause, and that clause can swallow part of the commitment. The ZDR label covers the normal processing path. It does not cover what happens once a document gets flagged.

How "Safety Metadata" and classifier outputs get handled is the real question, because those categories are frequently scoped out of the ZDR commitment entirely, even in agreements that otherwise look airtight on paper.

Retained document data as a legal and operational liability, not just a privacy preference

Retained document data is not a privacy nicety that only matters to the cautious. It creates a breach surface, a subpoena surface, and a compliance gap at the same time, and the regulatory environment is shrinking the room for treating a 30-day retention window as an acceptable default.

Every prompt, file, and output a vendor stores becomes something that can be stolen, subpoenaed, or audited. For legal, healthcare, finance, and HR workflows, that exposure is direct: if the data is stored, it is discoverable. Under true zero data retention, a breach on the vendor's side exposes far less, simply because there is far less sitting there to expose. If a vendor holds 30 days of document processing logs, a legal hold or a government subpoena against that vendor can expose client contracts, financial records, or patient data the customer assumed was gone the moment the API call completed.

GDPR gives this risk a specific legal shape through two provisions that default-retention architectures tend to violate structurally. Article 5(1)(e) requires that data be kept only as long as necessary for the purpose it was collected for, and a 30-day abuse-monitoring window is difficult to justify for a single invoice extraction call that finished processing in milliseconds. Article 25 requires data protection by design and by default, so systems need to minimize personal data exposure from the start. A default-retention architecture inverts that requirement: it makes the customer responsible for opting out of retention, rather than making non-retention the baseline the customer starts from.

Accounts payable, mortgage, insurance, and healthcare teams process these document types every day, and they happen to be exactly the categories regulators treat as highest-risk. Financial services teams process invoices, bank statements, closing disclosures, and payslips, data that every GDPR, GLBA, and FINRA risk framework treats as high-risk. Running these documents through an API with a default 30-day retention window effectively creates a temporary copy of regulated data sitting inside a third-party system for a month, whether or not anyone at the customer company realizes it.

The gap in enforcement usually isn't technical, it's procedural. Confirming zero data retention requires reading the actual DPA or MSA: which endpoints are covered, which models, what the retention window is, whether inputs and outputs are both included, and whether error logs, retries, and subcontractors fall under the same commitment. SOC 2 Type II is a useful starting point, but it only confirms the vendor has controls in place.

ZDR as an enterprise upsell and the compliance risk transferred to customers

Gating zero data retention behind a sales process, an enterprise tier, and a signed addendum is a business decision with a real cost attached, and the customer pays that cost. When ZDR is something a customer has to unlock, the vendor is charging for the right not to be held liable for data it chose to retain by default.

A customer on a mid-market or standard tier, or one still working through an enterprise approval process, absorbs the retention risk that ZDR would otherwise eliminate. Pricing it as a premium add-on inverts the usual economics of a feature.

Stateful API features make this worse, because they sit outside ZDR coverage even when a provider's core completion endpoint is eligible. Anthropic's Files API retains files until they are explicitly deleted, and it is not ZDR-eligible. The Gemini File API stores uploaded files at rest until a user deletes them or they expire, and that storage runs independently of ZDR logging controls. A document pipeline using file upload for large PDFs carries retention risk even on a paid plan, even with ZDR enabled elsewhere in the stack.

The clearest illustration of what this risk looks like in practice came from a 2025 preservation order tied to the New York Times copyright litigation against OpenAI, which required OpenAI to retain output data beyond its normal deletion schedule. API customers with a ZDR agreement, along with ChatGPT Enterprise and ChatGPT Edu customers, were explicitly excluded from that preservation order. For a document processing team, that is what default retention actually means once it intersects with a legal process outside anyone's control: data assumed to be transient becomes subject to a court order the customer never anticipated and had no ability to prevent.

Major API providers' document processing offerings under ZDR

No general-purpose LLM API on the market ships zero data retention as the default when you run document processing workloads. Every provider examined here requires enterprise contracting, an explicit opt-out of stateful features, or both, before you get anything close to a true zero-retention posture.

Invofox is built specifically for document extraction, invoices, payslips, contracts, utility bills, bank statements, tax forms, and closing disclosures, rather than adapted from a general-purpose LLM endpoint. Invofox enforces zero data retention as an architectural default: content is processed in volatile memory only and never written to persistent storage, logs, or training pipelines. Field-level confidence scores and agentic validation sit inside the extraction pipeline itself, so uncertain fields get flagged for human review based on calibrated confidence, not blanket manual checking. The system also learns from corrections in real time, improving accuracy as fields get flagged rather than requiring a separate retraining cycle, which sets it apart from static OCR tools. For a team weighing build-vs-buy, the combination of ZDR by default, a per-field accuracy SLA, and an on-premise deployment option addresses three risk categories, retention, accuracy, and data residency, that a self-built pipeline would otherwise need to solve one at a time.

Anthropic offers ZDR as a formal arrangement for the Claude Platform API, and any commercial organization can get it once Anthropic's sales team approves it. The standard Messages API is ZDR-eligible, and PDF support sent inline through the Messages API is both ZDR- and HIPAA-eligible. Even then, User Safety classifier results can be retained for up to 7 years, and flagged inputs and outputs for up to 2 years, separate from the ZDR commitment covering normal traffic.

OpenAI offers ZDR if you apply through its sales process and get approved. Fine-tuning, Assistants, and Stored Completions each carry their own separate retention rules, tied to opting into those specific features, and you don't get any of them under a core ZDR agreement automatically. Without ZDR in place, the standard API default is up to 30 days of retention for abuse monitoring.

Google's Gemini Developer API does not use prompts or responses from paid usage to improve its products, but it does log them for a limited period to monitor abuse and policy violations. Grounding with Google Maps stores prompts and output for 30 days for reliability engineering, and that storage cannot be disabled. Implicit in-memory caching, which runs on a 24-hour TTL, stays in RAM, and is isolated per project, does not violate ZDR. For workloads that need guaranteed ZDR or formal enterprise data processing agreements, Google points developers toward Vertex AI.

Mistral offers ZDR only on its Scale plan, and only after a support request with a documented justification. For any document processing workflow relying on file upload or batch processing, which describes most of them, those carve-outs remove coverage from the exact features the workflow depends on.

Runware sits in a different product category from the rest of this list: it is an image and media generation API, not a document extraction service. It's included here because its ZDR model is unusually explicit. If Runware forwards a third-party model from an upstream provider, ZDR then depends on that provider's own agreements. Runware holds ISO 27001 certification, GDPR compliance, and supports SSO/SAML.

Checking a vendor's DPA before trusting a ZDR claim

A vendor's marketing page describing its ZDR policy is not the document that matters. The data processing agreement, the master service agreement, and the security addendum are where the actual commitment lives, or where it quietly falls apart.

A short checklist for evaluating any vendor's ZDR claim before trusting it for document processing:

• Covered endpoints: confirm the specific API paths the pipeline actually uses are named in the agreement. ZDR that applies to a completions endpoint but not to file-upload or batch-processing endpoints does not amount to ZDR for a document processing workflow.
• Input types: confirm that uploaded files, PDFs, images, scanned documents, are covered in addition to text prompts. Many ZDR commitments are written with chat-style prompts in mind and exclude binary file uploads by omission.
• Error logs and retries: confirm whether a failed extraction call still logs the payload for debugging, and whether retry payloads and error-state logs fall under the same ZDR commitment as successful calls.
• Subcontractors: confirm the DPA covers upstream providers and subprocessors. A ZDR agreement with the primary vendor is not automatically a ZDR agreement with every infrastructure provider that vendor relies on.
• Safety classifier exceptions: confirm how flagged-content exceptions are scoped, including whether classifier metadata, safety scores, and abuse-flag records are retained separately, and for how long.
• Billing metadata retention: separate content retention, which ZDR should eliminate, from metadata retention, such as token counts, timestamps, and API key identifiers, which typically persists for billing and security auditing under every plan regardless of ZDR status.

Certifications establish a floor, not a guarantee. SOC 2 Type II confirms a vendor has controls in place, but confirming those controls apply to the specific document payloads a pipeline sends, or that ZDR is enforced at the infrastructure level, requires separate verification. ISO 27001 requires documented retention policies, so if a vendor holds that certification, you should be able to ask for a precise retention schedule for every data type the pipeline generates. GDPR-readiness documentation, including DPIA support, DPA templates, and sub-processor lists, is how a vendor demonstrates Article 25 compliance by design, and it should be requested before deployment rather than during an audit after something has already gone wrong.

For document-specific pipelines, three questions matter more than they do in general-purpose API comparisons, and they rarely come up there. A document extraction API built on zero-retention architecture by default, like Invofox, removes the breach and subpoena surface that grows out of stored payslips, invoices, and financial records, and it structures compliance around data protection by design rather than asking the customer to negotiate an exit from default retention.

Document-specific APIs with ZDR as baseline versus adapted general-purpose LLM APIs

General-purpose LLM APIs were built for conversational and generative workloads first.

The stateful features that make these APIs useful for general-purpose work, file upload endpoints, caching, conversation history, multi-turn context, are the same features that sit outside ZDR coverage, because each one requires persistence by design. Adapting a general-purpose LLM endpoint to document extraction without resolving its retention carve-outs produces a ZDR claim with an asterisk: it covers the common path but leaves failures, retries, and large file uploads exposed exactly where the real risk tends to concentrate.

A document processing API designed with ZDR as the baseline makes different architectural choices from the start. Document payloads are never persisted. Confidence scores are tied to pixel-level grounding in the source document; they are not inferred statistically. Validation layers flag uncertain fields for human review instead of returning a plausible-sounding value with false confidence attached. If a system keeps learning from corrections, it needs to get more accurate without holding onto the sensitive documents that produced those corrections, so the architecture differs fundamentally from fine-tuning a general-purpose model on retained customer data.

For teams in accounts payable, mortgage lending, insurance, and healthcare, the real question is whether the engineering work required to configure a general-purpose LLM to extract documents under ZDR correctly, and to keep it correct across every API version change, costs more than simply using a tool where ZDR is the default from day one.

The pricing model behind each approach tells its own story. A vendor charging only for correctly extracted pages, Invofox's model, ties accuracy to revenue directly, and the absence of default retention becomes a design commitment baked into the product. Teams trying to assemble a ZDR-compliant document extraction pipeline from general-purpose LLM endpoints are taking on harder engineering work to arrive at a weaker compliance posture than a purpose-built API delivers as its starting point.