Privacy and Zero Data Retention in Web Search APIs

Zero data retention in web search APIs sounds like a compliance checkbox, something legal signs off on and everyone forgets about. It isn't, because whether a provider can actually deliver ZDR depends on facts about index ownership, subprocessor chains, and memory handling that most procurement teams never ask about. ZDR is an infrastructure property, and whether a provider can actually deliver it depends on facts about index ownership, subprocessor chains, and memory handling that most procurement teams never ask about. This piece walks through what a real ZDR guarantee requires, why most search APIs structurally cannot offer one end to end, and how to identify whether a provider built for it or just wrote it into a slide deck.

Start with what ZDR actually means in operational terms, because the phrase gets used loosely enough that it's stopped meaning much on its own. A genuine zero data retention setup means no query strings hit disk, no retrieved content gets written to a log, and no user identifier persists anywhere after the response goes back to the caller. Data lives in memory for the duration of processing and then it's gone: not archived, not moved to cold storage, not anonymized and kept for analytics. Gone.

Three things get sold as ZDR that aren't. Encryption at rest is the most common one: a provider will point to a strong encryption standard or similar and call it a privacy guarantee, but encrypted data is still retained data. It still exists on a disk somewhere, it's still subject to subpoena, breach, or insider access, and "encrypted" just means someone needs a key to read it, not that it was never stored. Second, short deletion windows. OpenAI's default retention policy holds data for 30 days before deletion, which is a reasonable privacy practice but is not zero. Thirty days is a window, and a window is not the absence of one. Third, anonymization. Stripping user identifiers from a log doesn't dispose of the log itself, it's still sitting somewhere, still subject to whatever access controls and retention schedules govern that provider's infrastructure, and the buyer usually has no way to audit it.

There's a second axis that gets collapsed into the first one, and it shouldn't be: data residency. Retention answers whether anything persists after the request finishes. Residency answers where the live request gets processed geographically, which matters enormously for teams bound by a regional privacy regulation or anyone under a data localization mandate. A provider can offer airtight ZDR while still routing every query through servers outside a given region, and a provider can guarantee processing confined to that region while retaining logs indefinitely. Neither one substitutes for the other, and compliance teams that treat them as the same question end up with a gap they didn't know to look for.

So the real job, for anyone evaluating a ZDR claim, is figuring out whether the guarantee describes something structural, baked into how the system processes a request, or whether it's a policy promise sitting on top of an architecture that was never built to keep it. That distinction runs through every section below.

Why AI query payloads carry real compliance risk

A search API call from an AI agent carries more than a question. It can carry customer names, internal document references, regulated identifiers, material non-public information, or protected health information, depending entirely on what the application does. An analyst tool querying financial filings leaks different things than a hospital scheduling assistant, but both are sending payloads that, if logged somewhere outside the buyer's control, become a liability the moment anyone asks where that data went.

GDPR Article 5 requires data minimization: processing only what's necessary for a stated purpose, and a search subprocessor logging every query indefinitely isn't something the controller authorized, it's scope creep baked into infrastructure. That's a live legal exposure for any company serving customers in a regulated region while routing queries through a vendor that hasn't committed, contractually, to not doing that.

Procurement teams have caught up to this faster than the marketing side of the search API market has. Vendor risk assessments at banks and professional services firms now ask about subprocessor retention early, often before anyone discusses accuracy or pricing, and the answer can end a deal before it starts. A major MENA bank managing a substantial pool of assets isn't going to adopt a search API that logs its analysts' research queries, full stop. Retention behavior functions as a filter applied before the evaluation even begins.

There's a third pressure that's easy to miss: training reuse. If a provider's terms allow using submitted queries to improve its model or its index, then a customer's prompt engineering, its research strategies, and its end users' actual questions become inputs the customer no longer controls. That is not a hypothetical; it is a contract term, and it appears in default terms of service more often than buyers realize.

The HIPAA gap makes the structural point concretely. Web search with live internet access is generally not considered HIPAA-eligible, because pulling live results from the open web means touching infrastructure that hasn't been built or certified for protected health information, regardless of which LLM sits downstream. Any application layering web-grounded search onto a health-adjacent workflow inherits that gap, even if no one building the app realized it was there.

The subprocessor problem: why most search APIs cannot guarantee ZDR end to end

This mechanism explains why so many ZDR claims fall apart under a real architecture review. Most search APIs don't run their own search engine. They relay the query, at request time, to an upstream provider, usually Google or Bing, get results back, and pass them along. The moment that relay happens, the query payload leaves the API provider's infrastructure.

That's the whole problem in one sentence: a provider can commit to deleting its own logs, but it cannot commit on behalf of an engine it doesn't operate. Google's logging behavior, Bing's logging behavior, whatever retention policy sits on the other end of that relay, none of it falls under the API provider's data processing addendum. None of it falls under any ZDR commitment that provider makes to its customers, because the provider has no enforcement leverage over infrastructure it doesn't own.

Scraper APIs make this especially visible. A query goes to the scraper API, which routes it through an anonymous instance running a major search engine, and results come back. But the search engine on the receiving end still sees the query and, depending on its own policies, still logs it. The scraper API sits in the middle with zero ability to stop that from happening. It can promise whatever it wants about its own layer. It cannot promise anything about the layer underneath it, because that layer belongs to someone else.

Direct APIs from the large search engines carry a related but distinct problem. Their business model runs on profiling infrastructure, query logs feed ranking systems, ad targeting, and product development, and that was true well before the Bing Search API's retirement on August 11, 2025 closed off one of the more commonly used direct integration paths. Even setting that retirement aside, the incompatibility was structural from the start: a company whose revenue depends partly on understanding search behavior isn't going to architect a product around discarding that behavior.

How each provider in the market currently handles ZDR

Evaluating providers on this question comes down to three things: does the provider own its own index or relay to someone else's, what does its ZDR commitment actually cover, and which plans include it. Index ownership is the structural test, because everything downstream depends on it. A provider relaying to an upstream engine has already lost the ability to guarantee ZDR end to end, no matter what its own DPA says about its own servers.

Linkup operates its own search index and its own processing stack, with query handling staying inside Linkup's infrastructure from request to response, no relay to a third-party engine anywhere in the chain. Its ZDR implementation processes requests in temporary computing environments, holds data only in memory, and destroys that temporary data once results are delivered. Nothing gets written to persistent storage in the first place, which means there's no log to delete, because none was ever created. That's a meaningfully different claim than "we delete logs after 30 days." One is a policy about what happens to data that exists. The other removes the step where data would have started existing.

Linkup makes ZDR available on every plan, tier included, rather than gating it behind an enterprise contract, though it requires activation rather than running by default. The company holds SOC 2 Type II attestation, offers EU data residency on its standard plans, and provides Private Link and bring-your-own-cloud options at the enterprise tier. ZDR and data residency get configured independently here, which matches the distinction laid out earlier. An EU team can turn on both, using ZDR to answer what persists (nothing) and regional processing guarantees to answer where the request physically runs.

On accuracy, Linkup self-reports a 92% F-score on Verified SimpleQA, which the company states is the highest among sub-second web search APIs, with the evaluation harness published openly at github.com/LinkupPlatform/eval-simpleQA for anyone who wants to reproduce the number rather than take it on faith. Pricing starts from $0.005, with /fetch running $0.001 to $0.005 and /research running $0.25 to $2.50 depending on depth.

That's one accounting of how a single-index, no-relay architecture translates into an actual ZDR product. The pattern generalizes: any provider building on its own crawl and its own index, rather than routing traffic through someone else's search engine, starts from a structural position where end-to-end ZDR is achievable. A provider relaying to an upstream engine starts from a position where it isn't, regardless of intent.

Four questions that separate a ZDR guarantee from a ZDR claim

Anyone evaluating a vendor's ZDR page should be running through four questions, in this order, because each one either confirms or collapses the guarantee before moving to the next.

Who executes the search? If the answer involves relaying to an upstream engine at any point in the request path, the ZDR commitment ends at the provider's own perimeter, no matter what the marketing copy says. This is worth asking for architecture documentation on, not a policy statement. A sales page will say "zero data retention." An architecture diagram will show whether that's true.

How is the guarantee implemented technically? In-memory processing with no persistent writes is something an outside reviewer can actually verify, given the right access or attestation. A promise to delete logs after the fact is something the customer has to take on faith, because by definition the data existed at some point and the only evidence it's gone is the vendor's word. That's a real distinction, not a semantic one. Look for language around temporary compute environments, explicit no-write confirmation, and destruction confirmation timed to delivery, not to a scheduled batch job that runs later.

Does the provider have a signed, auditable data processing addendum that covers ZDR specifically? A marketing claim isn't a contractual commitment, and only one of those creates liability if it turns out to be false. Ask whether subprocessors are listed by name, and whether each one's retention behavior is addressed in the same document. A DPA that's silent on subprocessors is a DPA that hasn't actually closed the loop.

One might argue a fourth question is redundant once the first three are answered. It isn't, because a buyer needs both the contractual guarantee and the technical one. The guarantee's contractual status and its technical status are separate facts, and a buyer needs both. Architecture without contract leaves no legal recourse. Contract without architecture is a promise resting on infrastructure that may not support it.

How ZDR interacts with compliance certifications

SOC 2 Type II attestation confirms that a provider's stated controls operated effectively over the audit period. It does not confirm that zero data retention is one of those controls, unless ZDR is explicitly named in the scope of the audit. A provider can hold a clean SOC 2 report and still retain query logs indefinitely, because SOC 2 tests whatever the provider told the auditor to test. It's a real signal, but it answers a narrower question than most buyers assume.

The healthcare-compliance gap mentioned earlier applies here too: a provider can have SOC 2 attestation and a working ZDR configuration and still be unable to offer search suitable for regulated health data, if the search leg of its pipeline routes through a third party that doesn't itself carry that certification. OpenAI's documentation states this outright for web-enabled endpoints. Certifications stack, but they don't transfer automatically across every hop in a request path.

What a signed DPA adds, that a SOC 2 report doesn't, is contractual enforceability. An audit report tells a buyer what happened during a review period. A DPA with explicit ZDR language and a full subprocessor list gives the buyer something to point to if the vendor's practice ever diverges from what was promised, and it lets the buyer trace the entire data path rather than trusting a summary paragraph on a trust page.

GoSearch's enterprise architecture illustrates the layered version of this well: single-tenant deployment, bring-your-own-cloud options, ZDR agreements negotiated directly with LLM providers, and permission-aware search that respects existing access controls. None of those four pieces does the whole job alone. Together they form a governance stack: ZDR is one control inside a broader framework, not a substitute for the rest of it.

Whether ZDR trades accuracy or speed

There's a common assumption that locking down data means accepting a weaker or slower product, as if privacy and performance sit on opposite ends of some dial. But what if that framing is just wrong, on technical grounds rather than as a matter of opinion? Retention policy and retrieval pipeline are independent variables. ZDR governs where data lives and for how long during a request. It has nothing to do with the ranking logic, the index freshness, or the model producing the actual answer. Nothing about discarding a log after the fact makes the search underneath it worse.

The numbers back this up. Linkup, running full ZDR by default availability across all plans, posts a 92% F-score on Verified SimpleQA, a benchmark with a published, reproducible eval harness rather than a number pulled from a private report. Its /research endpoint scores 61% on SealQA-0, a harder benchmark built around adversarial and ambiguous queries specifically to stress-test retrieval quality beyond simple factual lookups. Neither number reads like a system that sacrificed accuracy to keep data from persisting.

That pattern shows up across this entire piece, actually. The providers doing ZDR seriously, the ones building it as an architectural default rather than an enterprise add-on, tend to be the same providers that own their index. Index ownership is what makes strong retrieval possible, and it's the same structural fact that makes real ZDR possible. Youcom, which operates its own proprietary index and processing infrastructure rather than relaying queries to an upstream search engine, is in that same category: query payloads never leave its own infrastructure, so they can be held in memory only for the duration of processing, with no persistent log created at any point in the chain. The privacy property and the performance property come from the same design decision. They were never actually in tension to begin with.