> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brandfetch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zero data retention

> An enterprise feature that keeps request metadata — the brands you query and the users behind the requests — out of Brandfetch's records.

<Tip>
  Zero data retention is an enterprise feature. [Contact
  sales](https://brandfetch.com/developers/contact/sales) to enable it for your
  organization.
</Tip>

## Overview

Some customers — banks and other regulated businesses among them — must be able to show that their vendors keep no record of what their systems look up. Zero data retention is an enterprise feature built for exactly that, enabled for your organization by your account representative — [reach out](https://brandfetch.com/developers/contact/sales) if you would like it turned on. Once enabled, the following are excluded from all retained request records — request logs, usage analytics, and internal events:

* Queried domains and brand identifiers (tickers, ISINs, crypto symbols, brand IDs)
* IP addresses
* User-Agent strings
* Referer headers
* Query parameters

It applies to every request made with your organization's credentials: [Brand API](/brand-api/overview), [Brand Context API](/brand-context-api/overview), and [Transaction API](/transaction-api/overview) requests authenticated with an API key, and [Logo API](/logo-api/overview) and [Brand Search API](/brand-search-api/overview) requests carrying a client ID.

## What is retained

For the covered APIs, billing and quota enforcement still count your usage, so records that attribute usage to your organization — but not what was queried or by whom — are kept:

* Request counts, timestamps, and response status codes
* The API key or client ID that made each request

The request logs in your [developer portal](https://developers.brandfetch.com) reflect this too: identifying fields are empty, and queried identifiers appear as the placeholder `redacted.invalid`.

## Scope

* Zero data retention applies from the moment it is enabled. It does not retroactively purge data recorded before then — talk to us if you also need historical records removed.
* Short-lived operational logs involved in serving and metering requests are purged automatically within days.
* Your own account activity — signing in, managing keys in the developer portal — is unaffected; the feature covers your API traffic's metadata, not your use of the dashboard.

## Why isn't this on for everyone?

Request data makes the product better, and most customers benefit from contributing it. We use it to:

* **Keep brand data fresh.** The domains and identifiers customers query tell us which brands to refresh first and which to elevate for manual curation and review — frequently requested brands get the most attention.
* **Expand coverage.** Queries for brands we don't know yet are the strongest signal for what to index next.
* **Maintain quality of service.** Traffic patterns drive caching, capacity planning, and performance work, and retained request records let us investigate abuse and enforce fair use — all of which keep the APIs fast and reliable for everyone.
* **Help you debug.** The request logs in your developer portal — and the ones our support team reads when you report a problem — show exactly what a failing request looked up.

With zero data retention enabled, your traffic stops contributing those signals: your queries no longer influence refresh and curation priority, and troubleshooting is limited to what you can share with us, since neither you nor our support team can see what a past request queried. That trade-off is the right one for regulated workloads and the wrong one for most — which is why it's opt-in per organization rather than the default.