TL;DR
- Context.dev fits synchronous AI pipelines that need per-request ZDR checks. Once your organization is enabled, you can verify a request through the documented response header. Batches and Monitors reject ZDR.
- Firecrawl fits enterprise workloads that need ZDR for batch scraping and crawl jobs. Its documentation also describes separate upstream search-retention modes, but ZDR requires Enterprise access.
- Spider fits workloads that prefer an account-level ZDR switch. Streaming and webhooks continue to work, but self-serve requests cost 2.5 times the usual credits while ZDR is on.
Why zero data retention matters for AI scraping pipelines
When you feed scraped pages into an LLM pipeline, your scraping provider handles target URLs, search queries, and page content before your model receives the data. Zero data retention, or ZDR, should give you a defined commitment about what the provider stores and whether it uses your data for model training. A technical ZDR setting does not replace contractual terms. It also cannot control what your application or downstream model provider retains.
A vendor’s ZDR claim needs a clear boundary. Our ZDR policy covers what Context.dev retains, but it does not cover your application’s logs. Although Search supports ZDR, the published policy does not establish retention terms for upstream search providers.
When comparing APIs, check which endpoints support ZDR and how you activate and verify it. Ask what operational metadata remains, whether requests bypass shared caches, and whether the terms extend to search providers. Async job support and plan access also matter if your pipeline depends on batch crawls rather than individual requests.
Decision table: Context.dev vs Firecrawl vs Spider on ZDR
We recommend Context.dev when you need per-request ZDR verification across scraping and extraction endpoints. Choose Firecrawl for enterprise batch jobs or Spider for an account-level switch that also covers streaming and webhooks.
| Product | Supported endpoints | Activation method | Verification mechanism | Async/batch support | Cache behavior under ZDR | Plan/pricing access |
|---|---|---|---|---|---|---|
| Context.dev | Scrape, Crawl, Search, Answers, Parse, Map URLs, People Enrich, Brand, and Styleguide | Organization enablement, then zdr: "enabled" on each request | X-Context-ZDR: true response header. Scrape also returns cache_metadata.status: "zdr" | Batches and Monitors reject ZDR | Web-content requests skip shared caches. Brand and Styleguide may still use caches | Requires organization enablement. ZDR adds no credit surcharge |
| Firecrawl | Scrape, batch scrape, crawl, parse, search, interact, and agent | Enterprise enablement, then a per-call parameter. Search uses a separate enterprise option | Unsupported access returns an error. No universal success indicator is documented | Batch scrape and crawl supported | Lockdown Mode may read an existing index. Other ZDR cache behavior needs confirmation | Enterprise only |
| Spider | Search, streaming, and webhooks are documented. The ZDR page does not list every endpoint | Account owner enables a setting that takes effect within about five minutes | No per-request success indicator is documented | Streaming and webhooks work. Storage-dependent features return zdr_unsupported | Neither reads nor writes cached pages | Self-serve ZDR costs 2.5× credits. Enterprise agreements include it without a surcharge |
Retention details also differ. Context.dev retains operational fields such as request ID, status, and credits for web-content requests. Firecrawl does not specify all retained operational metadata, and its agent results remain retrievable for 24 hours. Spider keeps hashed request-log rows for up to 30 hours.
For Search, Context.dev does not document an upstream provider retention guarantee. Firecrawl describes separate end-to-end ZDR and anonymized search modes, with different upstream retention claims that buyers should confirm in their agreement.
Context.dev
Context.dev is the best fit when you need per-request ZDR that your application can check on synchronous scraping and extraction calls. We support Scrape, Crawl, Search, Answers, Parse, Map URLs, People Enrich, Brand retrieval, and Styleguide through one API. Crawl is covered, but asynchronous Batches and persistent Monitors reject a ZDR request with ZDR_NOT_SUPPORTED. If your pipeline depends on batch jobs, that exclusion matters more than the breadth of the supported endpoints. Our ZDR documentation defines the endpoint boundary.
After we enable ZDR for your organization, you must send zdr: "enabled" on each covered request. A successful response carries X-Context-ZDR: true, and a Scrape response also sets cache_metadata.status to "zdr". You can make that field a pipeline check and throw an error when it does not equal "zdr", as our ZDR product page demonstrates. The check confirms the response reports ZDR treatment. It does not replace a contractual commitment or an audit of our systems.
For web-content requests under ZDR, we skip shared caches and retain operational fields for billing and usage, including request ID, time, endpoint, status, latency, and credits. Skipping cached results can make a request slower. Brand retrieval and Styleguide requests create no request-log entry under ZDR, but brand records and hosted assets can still persist. Our published ZDR terms also do not establish an upstream search provider’s retention policy. If you use Search, ask for those terms rather than treating our per-request status as an end-to-end guarantee.
Pros Per-request checks make ZDR treatment visible to your application without requiring you to maintain a crawler. The Tinfoil account describes one customer’s use case, not a guarantee for every pipeline.
Cons Batches and Monitors do not support ZDR, and enabling it for an organization requires a sales or support conversation rather than a self-serve toggle.
Pricing ZDR requests use the same credits as standard requests, with no ZDR credit surcharge.
Firecrawl
Firecrawl is the best fit when you need ZDR for enterprise batch scraping or asynchronous crawl jobs. Firecrawl says its Enterprise ZDR covers /scrape, batch scrape, /crawl, /parse, /search, /interact, and /agent. Batch and crawl coverage gives it an advantage over Context.dev if your workload depends on asynchronous jobs.
For most supported endpoints, you request ZDR with zeroDataRetention: true. Search uses a separate setting. Firecrawl describes enterprise: ["zdr"] as end-to-end ZDR across Firecrawl and its upstream search provider, while enterprise: ["anon"] permits the provider to cache an anonymized query. Firecrawl lists standard rates of 10 credits per 10 results for the first mode and 2 credits per 10 for the second. Treat those retention and pricing terms as vendor-stated claims, and confirm the upstream provider’s obligations in your enterprise agreement.
Firecrawl documents two limits to check against your retention policy. An agent result remains retrievable for 24 hours after completion. Lockdown Mode can read an existing index, although Firecrawl says it does not store the ZDR request URL or response. Its article does not specify every operational record retained for each endpoint, so ask Firecrawl about request and billing metadata.
Pros Firecrawl extends ZDR to batch scrape and crawl, and it offers distinct upstream search modes. Unsupported access fails explicitly, with documented 403 and 400 examples, rather than silently falling back.
Cons ZDR requires Enterprise enablement and is unavailable on Free, Hobby, Standard, Growth, and Scale.
Pricing Enterprise terms require a sales agreement. Firecrawl publishes the standard search credit rates above, but your agreement may differ.
Spider
Spider is best for teams that want one account-level ZDR setting across search, streaming, and webhooks, without adding a flag to every request. According to Spider’s ZDR documentation, the account owner enables it in account settings, and it covers new requests within about five minutes. Unlike a per-request flag, the setting applies across the account.
With ZDR enabled, Spider returns results but keeps no page content, request parameters, cached copies, or browser session recordings. It replaces URLs and hosts in request logs with one-way hashes. Those log rows can retain the account, status, timing, and credits charged for up to 30 hours. Spider may also retain a record of a refused ZDR request for up to 90 days, without page content.
Search and streaming continue to work. Webhooks send results to your configured endpoint, and Spider says it keeps no payload copy. Features that require stored results instead return a 4xx zdr_unsupported error. For AI extraction, Spider says it uses model endpoints that keep no data and do not train on requests, but its ZDR documentation does not name those providers or endpoints.
Pros: One owner-controlled setting covers supported workflows, including streaming and webhooks.
Cons: Activation takes about five minutes, and the published documentation does not identify the AI model endpoints for independent review.
Pricing: Self-serve requests cost 2.5 times the usual credits while ZDR is on. Spider says the multiplier does not apply to unlimited meters or enterprise agreements.
Procurement checklist for verifying ZDR claims
Verify ZDR on the endpoints you plan to use, then ask each vendor to back the technical behavior with written terms. A successful API response can show that a ZDR setting was applied. It cannot, by itself, prove what happens in downstream systems.
- Test activation and failure behavior. For a Context.dev Scrape request, set
zdrtoenabled, then check forX-Context-ZDRset totrueandcache_metadata.statusset tozdr. Reject the result if either check fails. Our ZDR documentation describes these signals, but a response field remains a vendor-reported signal, not an independent audit. - Match the test to your workload. Ask each vendor to demonstrate ZDR on every endpoint you will use, including search and asynchronous jobs. Confirm what happens when ZDR is unavailable, whether caches are read or written, and whether completed results remain retrievable.
- Get the retention boundary in writing. Request the names and retention terms of search providers, model providers, and other subprocessors. Ask which URLs, request parameters, content, and operational records each party keeps.
- Check the contractual evidence. Ask for an SLA or equivalent commitment covering ZDR behavior, current audit or compliance artifacts, data residency terms, and the retention period for billing, security, and abuse records. Confirm who can inspect those records and how you can verify deletion.
FAQs
Does ZDR mean nothing is logged? No. For web-content ZDR requests, Context.dev retains operational fields, including request time, endpoint, status, latency, and credits, but says it does not keep URLs, parameters, or page content. Ask each vendor which records remain and for how long.
Can I use ZDR with async or batch jobs? Firecrawl documents ZDR for batch scrape and crawl on Enterprise. Context.dev supports Crawl with ZDR, but Batches and Monitors reject it. Spider supports streaming and webhooks, while requests for storage-dependent features return zdr_unsupported. Check your exact job type before choosing.
Does scraping API ZDR cover my application’s logs? No. Your application remains responsible for anything it stores, including submitted URLs, returned content, webhook payloads, and LLM prompts. Scraping API ZDR governs what the provider retains under its stated terms.
How can I confirm that a request used ZDR? On Context.dev, send zdr: "enabled" and check the X-Context-ZDR: true response header. Scrape responses also report cache_metadata.status as "zdr". Those signals let your code catch a request that lacks ZDR confirmation. They cannot independently prove what the provider retained, so request contractual terms and audit evidence too.
Do search results receive the same retention protection? Do not assume every provider covers the full search chain. Context.dev lists Search as ZDR-supported but does not document upstream search-provider retention terms. Firecrawl describes separate end-to-end ZDR and anonymized search modes. Spider says Search works under its account-level ZDR setting. Ask each vendor which upstream providers receive queries and what those providers retain.
Conclusion
For synchronous scraping and crawling, choose Context.dev when you need per-request ZDR and a response header you can check. Our documentation also makes the boundary clear. Batches and Monitors reject ZDR. Firecrawl better fits enterprise workloads that need batch coverage, while Spider suits teams that prefer an account-level setting with streaming and webhooks.
Test the endpoints your pipeline uses before choosing. Ask each vendor what operational data it retains and whether its search providers follow the same retention terms.