Zero Data Retention Across Firecrawl Search, Scrape, and More

Firecrawl offers Zero Data Retention (ZDR) on every endpoint that handles page content: /scrape, batch scrape, /crawl, /parse, /search, /interact, and /agent, for Enterprise plans. With ZDR on, we do not keep page content, extracted data, or search queries beyond the lifetime of the request, apart from an agent result, which stays retrievable for 24 hours and is then deleted. Search has two modes:

• End-to-end: our upstream search provider also keeps nothing.
• Anonymized: we keep nothing and the provider may cache an anonymized query.

The compliance paperwork behind it lives in our Trust Center.

Zero Data Retention means we process a request in memory and discard its inputs and outputs once the response is delivered. For /scrape, /crawl, and /parse that covers page and document content and extracted data. For /interact it covers page content and execution output. For /search it covers the query and the results. For /agent it covers the prompt, the content of every step, and the result, with one exception. The result stays retrievable for 24 hours after the run completes so you can fetch it, and is deleted after that.

Teams ask for this because the inputs to a web data API are themselves sensitive. The URLs an AI agent scrapes reveal which companies a fund is diligencing. The queries a research agent runs reveal which drug, which litigation target, or which acquisition a team is looking at. A retained log of those requests is a liability for a bank, a hospital system, or a law firm, even if no page content is ever leaked.

For enterprise buyers, this is usually the first gate. Procurement asks where the data goes before anyone evaluates output quality. ZDR, a signed Data Processing Agreement, and a Trust Center with the policies on request answer that question up front.

We are already through that gate at scale. 150,000+ companies and 1.5M+ users rely on Firecrawl, including 67% of the Fortune 100, and our open source repository has 180K+ GitHub stars.

Most search APIs cannot offer end-to-end Zero Data Retention because they do not run the search. The query is forwarded to a consumer search engine, and that engine keeps what it sees. A provider can delete its own copy of your query and still hand it to a subprocessor that never will. Firecrawl's /search separates the two hops so you know which claim you are getting.

Search APIs rarely say where the query goes after it leaves their server. In most cases it is relayed to a machine somewhere running a consumer search engine, and the results are passed back. Consumer search engines log queries and use them to improve ranking and train models. So the API in front can promise whatever it likes about its own storage, because the query has already left it.

"We don't store your queries" and "nobody stores your queries" are different claims. The first covers one hop. The second covers the whole pipeline, including every subprocessor, and it is the one a security review asks for.

Firecrawl's /scrape, /crawl, /parse, and /interact endpoints never have this problem. Our own browsers fetch the page, render it, and return Markdown or JSON, so the data stays inside one ZDR system and is discarded when the request ends. We have offered ZDR for scraping on Enterprise plans since July 2025.

Firecrawl's /search is backed by an upstream search provider, so we state the two hops separately:

• End-to-end ZDR (enterprise: ["zdr"]): we and our upstream search provider both enforce zero data retention. No query or result data is stored at any point in the pipeline.
• Anonymized ZDR (enterprise: ["anon"]): we retain nothing. The search provider may cache the query, stripped of anything that identifies you.

If your review needs the whole-pipeline claim, use the end-to-end mode. If it only needs the one-hop claim tied to your account, the anonymized mode costs a fifth as much at standard rates (2 credits per 10 results against 10). Enterprise agreements can set different pricing.

The upstream hop only exists for the open web. We also run our own indexes inside Firecrawl Alexandria: a Research Index of about 43M paper abstracts, a Developer Index of 70M+ pages from code repositories and documentation, and a Government & Legal Index of 30M US pages. A query against one of those is served by infrastructure we operate, with no third-party search engine in the loop. Government & Legal Index searches are free, with or without ZDR.

Enabling ZDR is one field per request. Scrape, batch scrape, crawl, parse, interact, and agent take zeroDataRetention: true. Search takes enterprise: ["zdr"] or enterprise: ["anon"]. If your team has not been enabled for ZDR, the request fails rather than running without it. Interact returns a 403, and agent returns a 400 with the code zdr_not_enabled, since an agent run needs both Scrape ZDR and Search ZDR enabled. Confirm the plan setting with us first.

Scrape with ZDR:

curl -X POST https://api.firecrawl.dev/v2/scrape \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer fc-YOUR_API_KEY" \
  -d '{
    "url": "https://example.com",
    "formats": ["markdown"],
    "zeroDataRetention": true
  }'

Search with end-to-end ZDR:

curl -X POST https://api.firecrawl.dev/v2/search \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer fc-YOUR_API_KEY" \
  -d '{
    "query": "sensitive topic",
    "limit": 10,
    "enterprise": ["zdr"]
  }'

Search that also scrapes the results, with ZDR enforced on both steps. The enterprise parameter covers the search portion and carries ZDR to every resulting scrape. No second flag is needed:

curl -X POST https://api.firecrawl.dev/v2/search \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer fc-YOUR_API_KEY" \
  -d '{
    "query": "sensitive topic",
    "limit": 5,
    "enterprise": ["zdr"],
    "scrapeOptions": {
      "formats": ["markdown"]
    }
  }'

An agent run with ZDR. The agent scrapes and searches as it works, so it needs both Scrape ZDR and Search ZDR enabled for your team:

curl -X POST https://api.firecrawl.dev/v2/agent \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer fc-YOUR_API_KEY" \
  -d '{
    "prompt": "Find the pricing plans of firecrawl.dev",
    "zeroDataRetention": true
  }'

For /interact, pass zeroDataRetention: true on the first call that opens the session. The rest of the session inherits it, and a session started without ZDR cannot be switched on later. The interact endpoint guide covers sessions in more detail, and the scrape endpoint guide covers the other scrape options you can combine with ZDR.

Lockdown Mode counts, because it is a cache-only mode for /scrape that serves results from our existing index with no outbound request to the target site. Every lockdown request carries ZDR by default. The URL is not persisted, the response is not stored, and the job is cleaned up after delivery. The standard ZDR credit uplift is waived.

The two solve different problems. ZDR limits what we keep, and Lockdown Mode limits what leaves our infrastructure. When an AI agent chooses which URLs to scrape, a prompt injection can push context out through the request's path or query string. Pinning the agent to the index closes that channel. Teams in regulated industries often want both, lockdown for agent-chosen URLs and ZDR for live scrapes of approved sources.

We are SOC 2 Type II compliant (renewal in progress) and process all data in the United States. Enterprise customers can sign a Data Processing Agreement and a custom MSA with us. Our subprocessor list is public, with advance notice of changes. We enforce identity, network, and audit controls server-side, so they hold whichever client calls the API.

Our Trust Center is the starting point for a review. It lists our current controls across infrastructure, organizational, product, and data security. You can request our SOC 2 Type II report, the latest penetration test, and our Access Control, Data Management, Information Security, and Third-Party Management policies there. The subprocessor page takes subscriptions, so your team hears before a new subprocessor handles customer personal data.

Beyond ZDR, the controls that come up most in reviews:

• SSO and SCIM. SAML and OIDC single sign-on with Okta, Entra ID, Google Workspace, and others, plus SCIM directory sync, so access follows your identity provider.
• IP restrictions and static IPs. Limit a team's API keys to an allowlist of IP addresses or CIDR ranges, and route traffic through dedicated IPs you can allowlist on your side.
• Key restrictions and spend limits. Lock an API key to specific endpoints and output formats, enforced server-side, and cap spend per key or per team.
• Threat Protection. Block us from fetching risky URLs under a policy your organization controls and can lock.
• SIEM audit logging. Stream a structured audit event for every scrape to your SIEM, starting with Microsoft Sentinel. Events from ZDR teams are flagged as such.
• PII redaction. Set redactPII: true to strip personally identifiable information from scrape and parse output before it reaches you, for 4 additional credits per page.

These are managed controls, so data is still processed on our US infrastructure. That setup may meet a review's data-handling requirements. Teams that need processing inside their own network self-host our open source engine instead, with a smaller feature set.

ZDR is an Enterprise feature and we enable it per team. Reach out through our Enterprise page or email help@firecrawl.dev with the endpoints you need and which search mode your review requires. Request the security documents from our Trust Center in parallel, so the paperwork and the plan setting land together.