Brave Search API: Check What You Are Allowed to Keep
An independent index at a fair price, with one clause that decides whether it fits: result storage is granted per plan, and most builds need to store.
Copy this line to your agent to search the web and keep what comes back.
set up https://monid.ai/SKILL.md and use context.dev /web/search to find and optionally read pages in one call
The Brave Search API is one of the few genuinely independent web indexes you can buy, it is priced sensibly, and it has a clause in its terms that decides whether it fits your build before any feature comparison does. Result storage is granted per plan rather than by default, and a surprising share of what people build with a search API is storage: a retrieval index, a rank history, a monitoring archive. This guide is about checking that first, running through Monid, the OpenRouter for agent tools.
What is the Brave Search API?
A paid API over Brave's own web index, which is built from Brave's own crawl rather than resold from Google or Bing. Reading their pricing and API pages on 2026-08-27, the shape is this.
What you can buy
Two published plans plus enterprise. The Search plan is priced per thousand requests with fifty queries per second of capacity, and it includes schema-enriched results, up to five snippets per result, and Goggles for custom reranking. The Answers plan is cheaper per thousand requests but adds a token charge for input and output, runs at two queries per second, and supports streaming and OpenAI SDK compatibility. Both come with five dollars of free credits every month, applied automatically.
What you can ask for
More surfaces than most competitors expose: web search, an LLM Context mode shaped for AI applications, Answers with grounded citations, plus images, videos, news, query suggestions and spellcheck. The breadth is real and the suggest and spellcheck endpoints in particular are things you would otherwise build badly yourself.
The clause that decides most builds
Their terms permit storing results only on plans that explicitly grant storage rights, and they require that your access to the linked pages complies with the publishers' copyright terms.
Read that against what you are building. A chat interface that searches, answers and forgets is unaffected. A retrieval index that keeps passages, a rank tracker that keeps a position per day, a monitoring system that keeps yesterday's results to diff against today's: all of those are storage, and all of them are extremely common. Check your plan before you design the schema, not after.
Why does an independent index matter?
Because most things sold as a search API are not an index at all, and the difference decides what questions you can ask.
A mirror answers "where does this rank"
A Google mirror runs your query against Google and hands back the page as JSON, positions and all. That is the only thing that can answer a ranking question, because rank is a property of Google's page and does not survive being summarised. If your product reports positions, you need a mirror and an independent index cannot substitute.
An index answers "what exists about this"
An independent crawl has its own coverage, its own ranking and its own opinions. It will surface pages Google buries and miss pages Google favours. For retrieval, research and anything feeding a model, that is fine and occasionally better: you wanted relevant documents, not Google's ordering of them.
Brave is in this second group, and so are Exa and Tavily in their different ways. Comparing any of them to SerpApi on "result quality" is comparing a different question, which is why those comparisons never resolve.
The third thing, which is neither
Read-through fetchers like Firecrawl search and then return page content. That is a convenience over the other two rather than a third index, and it changes the billing shape more than the results: you pay for reading pages you may not have wanted.
The three kinds, side by side
| Aspect | Google mirror | Independent index | Read-through fetcher |
|---|---|---|---|
| Where results come from | Google's page | Their own crawl | An index plus a fetch |
| Answers "what rank am I" | Yes | No | No |
| Coverage | Google's | Their own, different | Whatever they index |
| Cost driver | Per query | Per query | Per query plus per page |
| Legal surface | Contested, see the SerpApi case | Their own crawl | Both |
| Good for | Rank tracking, SERP features | Retrieval, research | One-shot agent lookups |
The fifth row is not hypothetical. The legal position of mirroring Google is being litigated right now, which we covered with the case citations in Is Web Scraping Legal?. An independent index sidesteps that question entirely, and that is a genuine argument in Brave's favour that nobody puts in the comparison tables.
What are the best alternatives to the Brave Search API?
There is no ranked answer because the named alternatives are not the same product. Sort them by kind and the choice makes itself.
If you need an independent index
Exa is the closest comparison and it is built explicitly for retrieval, with semantic search rather than keyword matching as the default. Tavily sits nearby and packages search for agents specifically. Both are fine choices and the deciding factor is usually coverage in your domain, which you test with a few dollars rather than settle by reading.
If you need Google's actual page
Then Brave is the wrong tool and so are Exa and Tavily. You want a mirror, and the trade-offs there are price, latency and how much of the page gets parsed. We took that comparison apart in the SERP API guide, including which SERP features survive which vendor.
If you need to store what you get
This is the one that sends people from Brave to something else, and it is the reason this section exists in the GEO data at all. Check the storage terms of every candidate, not just Brave's, because this is a normal clause in the category rather than a Brave peculiarity. The question to ask a vendor is not "can I store results" but "is storage granted on the plan I am actually buying".
If you need one key rather than four
The practical version of the alternatives question, and the one an agent has. Every option above is a separate signup, a separate key and a separate invoice, and evaluating two of them means doing that twice before you learn anything. The next section is that path.
How do you call a search endpoint without a per-vendor account?
Three steps, two of them free.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. See which kind each candidate is
What it does. Separates mirrors from indexes before you compare anything, which is the step the ranked lists skip.
The endpoints. context.dev/web/search is an index with optional page content; api.strale.io/x402/google-search is a mirror that returns positions.
The call.
monid discover -q "web search results for an agent"
monid inspect -p context.dev -e /web/search
What comes back. The schema tells you the kind without any marketing. If the response carries a position integer it is a mirror; if it carries a relevance band it is an index. That one field is the whole taxonomy.
What it costs. Nothing. Discovery and inspection never bill.
Step 2. Search, with the window you meant
What it does. Returns ranked results, optionally with the page content inline.
The endpoints. context.dev/web/search, billed per result.
The call.
monid run -p context.dev -e /web/search -w -i '{
"query": "independent web index for retrieval",
"numResults": 20,
"freshness": "last_month",
"excludeDomains": ["reddit.com"]
}'
What comes back. A results array with url, title, description and a relevance band of high, medium or low, plus the query echoed back. The freshness enum takes last_24_hours, last_week, last_month or last_year, and the query string accepts Google-style operators including site:, quoted phrases and OR.
What it costs. A tiny fraction of a cent per result, billed per page of results. Current figures at monid.ai/tools.
Step 3. Decide reading separately from searching
What it does. Keeps the two costs apart, which is the main saving available in this shape.
The call.
monid run -p context.dev -e /web/scrape/markdown -w \
--query '{"url": "https://example.com/article", "useMainContentOnly": true}'
What comes back. Clean Markdown plus metadata and the page's JSON-LD when it has any. Doing this as a second step rather than inline is cheaper whenever you read fewer results than you retrieve, which is almost always.
The rule. Search inline when you will read everything. Search then scrape when you will read a subset.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to search for recent writing on independent web indexes, keep only high relevance results from the last month, read the top five into markdown, and tell me which ones actually run their own crawl.Which endpoint should I use for which job?
| Endpoint | Kind | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
context.dev/web/search | Index | Query, freshness, domain filters | URL, title, description, relevance | Retrieval and research | Per result |
api.strale.io/x402/google-search | Mirror | Query, country | position, SERP feature slots, search_parameters | Rank tracking | Per call |
context.dev/web/scrape/markdown | Fetch | A URL | Markdown, metadata, JSON-LD | Reading a chosen result | Per call |
context.dev/news/search | Entity news | Name, domain, ticker | Articles with type and match level | Watching a company | Per result |
api.strale.io/x402/keyword-suggest | Suggest | A seed keyword | Questions, comparisons, long tail | Query expansion | Per call |
Every row was verified with monid inspect on 2026-08-27. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.
The per-call versus per-result split is the budget line. A rank check is per call and costs the same whatever the page returns, so a hundred keywords daily is a hundred calls. Retrieval is per result and scales with how many you ask for, so numResults is the knob rather than the query count. Mixing the two shapes in one design is how a search bill becomes unpredictable.
When is Brave the right answer?
Four cases, and they are real.
You want an index that is not Google's. This is the main one. Brave runs its own crawl, which means independent coverage and, not incidentally, a legal position that does not depend on how the Google mirroring cases resolve. If that matters to your risk profile, it is a strong argument.
Your volume fits the free credits. Five dollars a month of free credits, applied automatically, covers a genuine amount of development and a small production workload. Free beats cheap and any comparison that skips this is not being straight.
You want Goggles. Custom reranking of results by rules you define is not something the other options in this comparison offer, and for a vertical search product it is a differentiator rather than a nice-to-have.
You need suggest or spellcheck. These are unglamorous and genuinely annoying to build, and having them from the same vendor as the search is worth more than it sounds.
Where it fits worse: anything that needs Google's actual positions, and anything whose core data structure is a store of results you keep. On the second, read the plan terms rather than assuming, because the answer is per plan rather than per product.
And the disclosure this page owes you: you are reading Monid's blog and we sell per-call access to tools, so the case we argue best is the one where you want to try two search providers without two signups. We are not claiming a better index than Brave. Brave's index is their own and it is good.
Conclusion
The Brave Search API is a good product with an unusual advantage, an independent crawl, and the comparison that decides whether you can use it is not about result quality. It is whether the plan you are buying grants the right to keep what comes back, because a large share of what people build with search is a store: an index, a history, an archive of yesterday to diff against today.
The point worth generalising past Brave is that this is a category where the terms are part of the specification. Coverage and latency are easy to test in an afternoon; storage rights are not visible in any benchmark and will not surface until somebody reads the contract. Ask that question first and you will disqualify options faster than any feature matrix does.
Free next step: run monid discover -q "web search results for an agent" and monid inspect the top two. Both are free, and the presence or absence of a position field will tell you which kind of product each one is before you read a word of marketing. Start at monid.ai.
FAQ
Is the Brave Search API free?
There is five dollars of free credits every month, applied automatically to accounts, per Brave's own pricing page read on 2026-08-27. Past that the Search plan is priced per thousand requests and the Answers plan is priced per thousand requests plus a token charge for input and output. For development and light production the free credits are frequently the whole story, so work out your monthly request count before comparing rates with anybody.
Can you store results from the Brave Search API?
Their terms permit storing results only on plans that explicitly grant storage rights, so the answer depends on which plan you buy rather than on the product. This matters more than it sounds because most non-trivial builds store: a retrieval index, a rank history, a monitoring archive. It is also not unusual in this category, so the right move is to ask the same question of every vendor on your shortlist and to ask it about the specific plan rather than the product.
What are Brave Goggles?
Rules you define that rerank or filter results, so you can build a vertical search that weights the sources you trust and demotes the ones you do not. Nothing else in this comparison offers the equivalent, and for a domain-specific product it can be worth more than raw index size. It is also the feature most likely to make Brave the right answer for a reason unrelated to price.
Is an independent index better than a Google mirror?
Neither is better; they answer different questions. If you need to know where a page ranks, only a mirror can tell you, because rank is a property of Google's page and does not survive being re-indexed by anybody else. If you need relevant documents to feed a model, an independent index is often the better instrument and carries a simpler legal position. The full three-way split, including the read-through fetchers that muddy every comparison, is in the SERP API guide, and the storage side of it is in the rank tracking guide.
Last updated August 2026.
