Skip to main content
Brand Search API provides fast querying of brands. It lets you search by brand names and match them to their corresponding URLs, enabling you to create rich autocomplete experiences. The Brand Search API is designed to work in tandem with our other services. Once a user selects a brand, you can use its unique identifier to retrieve detailed data using our other APIs.

​
Implementation guide

1

Get your client ID

You’ll need to create an account on our Developer Portal. Creating an account is quick and easy, and will give you access to your dashboard where you’ll find your client ID.
2

Make your first API call

Brand Search API is free to use and we don’t ask for any attribution.
Implement or run the code below to make your first API request.
Authentication is done by passing your client ID as a query parameter.
3

Test and deploy

The Brand Search API is a free product. Before you deploy your application to a live environment, be sure to consult our rate limits and review our usage guidelines to ensure a smooth launch.

​
Usage guidelines

Authentication

To use Brand Search API, you must include your client ID with every request.Adding your client ID provides reliable access, supports fair usage, and keeps consistent performance across all requests.Create a free account and access your client ID from the Developer Portal.To use Brand Search API, include your client ID with every request as shown below:
We require Brand Search API to be directly embedded in your user-facing applications.The API should be used directly as is, with all data fetched live and not altered or persisted. Your users should make requests to the API directly from their browsers.The logo image URLs provided by the Brand Search API must be hotlinked. Other data, such as brand names, should not be cached and should be used exclusively for building an autocomplete experience. Image URLs expire after 24 hours and must be refetched.For more information on the API’s availability, see our uptime status. We can provide custom SLAs for enterprise customers.If your use case requires more flexibility, please contact us for a custom setup.
You cannot replicate the core user experience of Brandfetch.The best way to ensure that your application doesn’t violate this guideline is by integrating Brandfetch into an existing app that offers more value than just the Brandfetch integration.Some examples:
  • ✅ The Pitch integration helps their users autocomplete brand names to streamline logo search within Pitch’s editor. Without this integration, the app still has a lot of value to its users.
  • 🚫 An unofficial Brand Search API that allows users to autocomplete brands. Without the API, the app has no content and no value to users.
If you’re unsure about your use case, please contact us.

​
Rate limits

Every plan includes a monthly Brand Search allowance: 500,000 requests per month on the free plan, and 1 to 5 million on paid plans. See the pricing page. These are soft limits, so exceeding yours does not block you straight away. Traffic that runs far beyond your allowance can eventually be refused with a 429 carrying quota_exceeded. Usage is counted per client ID. Every GET answered with a 2xx or 3xx status counts, whether it was served from the edge cache or freshly. Browser preflight requests, refused requests, and requests without a valid client ID do not count. Your month’s usage and every counted request are under Usage History in your developer dashboard. To maintain platform reliability, two request throughput limits also apply:
  • 200 requests every 5 minutes per IP address
  • 6,000 requests every 5 minutes per client ID, counted across every address it is used from. Enterprise client IDs are exempt.
Both count answers served from the edge cache. The per-IP limit also counts browser preflight requests; the per-client limit leaves them out, so a browser that goes over it still receives a refusal it can read. The per-IP limit allows roughly 30 search sessions in a 5-minute period for a single visitor; the per-client limit applies to all of your application’s traffic together. Use a debounce strategy between keystrokes to stay under both. Exceeding the per-IP limit returns an HTTP 429 status code without an x-bf-error header; exceeding the per-client limit returns a 429 with x-bf-error: rate_limited. See Errors for how to tell a throughput block from the other reasons a request can be refused. For enterprises, we provide custom solutions, including SLA agreements, custom terms, and flexible caching options to ensure optimal performance at scale. These plans are tailored to meet the needs of high-volume users. Feel free to contact us to discuss the right plan for your use case.

​
Errors

When the Brand Search API refuses a request because of its client ID, its client ID’s throughput or your allowance, the response carries an x-bf-error header naming the exact reason, and a JSON body with the same code in error, a message written for a human, and a docs link. The header is exposed through CORS, so a browser caller can read either one.
The per-IP throughput limit under rate limits is enforced separately, before the client ID is looked at, so those 429 responses carry no x-bf-error header and no error field, only a short message. The presence of the header is what tells you the request was refused for one of the reasons below.

​
When a search fails

A search that could not be answered returns 503 with x-bf-error: temporarily_unavailable and a JSON body with a message. It never returns an empty array, so a 200 with [] always means no brand matched. Retry after about 10 seconds. An identical request made sooner can get the same 503. A 503 does not count towards your Brand Search allowance.

​
Responses without an x-bf-error header

Every other response is either the per-IP throughput limit, which is checked before the client ID, or the search’s own answer.
You can see all of these responses for your own traffic under Usage History in your developer dashboard, filtered by status class.

​
API Reference

For more details, refer to our API Reference.