[developersdigest]

Documents how to run an Alexandria provider call with zero data retention.

The page is Alexandria → Zero Data Retention. It explains what is kept, how to tell which providers support ZDR, how to set the flag, the +1 credit, and what a retry does. Scrape, billing, security, enterprise, agent, the error catalog, and the v2 scrape reference cross-link that section instead of repeating it.

How to enable it

POST /v2/scrape accepts zeroDataRetention: true as a sibling of alexandria, next to timeout, origin, and integration. Verified in apps/api/src/controllers/v2/scrape-alexandria.ts on firecrawl/firecrawl main, and in firecrawl/firecrawl#5178. A team with forceZDR / scrapeZDR: "forced" gets the flag on every Alexandria call without setting it. The public API forwards the field to Exchange as x-exchange-zero-data-retention: true on the quote and the retrieve call.

The current JavaScript and Python SDKs on that same main do not send the field for an Alexandria scrape. JavaScript rejects any key other than alexandria, requestId, timeout, integration, and origin. Python forwards timeout, integration, and request_id only. The page says to send the HTTP request.

What a ZDR call keeps

The original response is returned to the caller. After that:

• The 7-day idempotency record stores no provider response (responseWithheld). Replaying the same x-request-id returns 409 response_not_retained with "This provider request already completed. Its response is not kept under zero data retention."
• A different body on that id, including a different zeroDataRetention value, returns 409 duplicate_request.
• The provider activity row redacts the target, options, and error text, and keeps success, duration, and credits. The request log redacts the target hint.

domainTools on a URL scrape is still refused with 403 when zero data retention is active. Alexandria execution itself is no longer described as a 403 for that reason. The OpenAPI 403 text is updated to match.

Not verified here

• +1 credit per request. The public API does not add this credit. It bills the creditsCost Exchange returns. firecrawl/firecrawl#5178 says Exchange prices +1 credit for workflow programs in the quote, and that this depended on firecrawl/exchange#936, which was not merged when that pull request landed. firecrawl/exchange and firecrawl/firecrawl-web#4267 both returned 404 to this environment, so the pill copy and the quote math were not read from source. The page states the cost the provider-page pill is described as showing: +1 credit per request when ZDR is enabled, on top of the tool price, with data.creditsCost as the total. It does not say how that credit multiplies when one HTTP request batches several calls.
• zero_data_retention_unsupported. The merged API change says Exchange answers 400 with this code for a capability that cannot honor ZDR, and the controller comment says Exchange decides per capability. The code string is not asserted in the public API tests; the API relays Exchange's body. The exact error sentence is not documented.
• Find Tools under ZDR. The API pull request lists firecrawl/find-tools as still refused by Exchange unless Exchange allows it. The public API forwards the flag and skips recording discovery. That refusal is not written up here.
• An enterprise gate on the flag. Scrape and Interact docs say ZDR must be enabled for the team. The Alexandria controller does not check allowZDR before forwarding zeroDataRetention: true. Only the forced mode is applied automatically. No 403 for a team without ZDR enabled is documented for this path.

  

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
firecrawl	🟢 Ready	View Preview	Oct 22, 2026, 5:54 PM

💡 Tip: Enable Automations to automatically generate PRs for you.