What Is a SERP API, and Which Kind Do You Need?

Copy this line to your agent to give it live search it can call.

set up https://monid.ai/SKILL.md and use context.dev /web/search to answer a question from the live web

Three different products are sold as a SERP API, and picking the wrong one is why people say the results were useless. One mirrors a Google results page and hands you positions. One runs its own index and hands you an answer set. One searches, then reads the pages, and hands you text. They overlap enough to look interchangeable in a feature table and they are not. This guide separates them, then shows how to call each through Monid, the OpenRouter for agent tools.

What is a SERP API?

A SERP API is an HTTP endpoint that returns search engine results as structured data instead of as a web page you have to parse. That is the whole definition, and it is why the category name tells you almost nothing about the product. What actually differs is where the results came from.

The Google mirror

This kind runs a Google query on your behalf and gives you back the page as JSON: organic results with their positions, plus whatever blocks Google rendered that day. SerpApi and Serper are the reference examples, and Bright Data sells one too. You reach for a mirror when the position is the data. Rank tracking, share of voice, checking whether an AI Overview fired for a query, pulling the People Also Ask box: none of that survives a summary, so you need the page itself.

The tell is in the response. A mirror returns fields no independent index can invent, because they describe Google's layout rather than the web: position, answer_box, knowledge_graph, people_also_ask, sitelinks.

The independent index

This kind crawls the web itself and answers your query from its own store. Exa is the clearest example, and Brave's search API is another. There is no Google in the path at all, which means no positions, no SERP features, and no reason for the ranking to match what a person would see. What you get instead is a result set tuned for a machine reader: neural retrieval on the meaning of the query, filters for category and publish date, and a stable schema that does not change when Google redesigns something.

You reach for an index when you want documents about a thing, not what ranks for a string. Most retrieval augmented generation belongs here, and using a mirror for it is the most common mismatch in this category.

The read-through fetcher

This kind searches, then fetches the pages it found and returns their text. Context.dev does it with one flag on its search endpoint, and Firecrawl is built around the idea. The output is markdown you can hand a model without a second round trip, which matters more than it sounds: search results are titles and two-line snippets, and a snippet is almost never enough to answer with.

The pattern the table shows is that positions and content pull in opposite directions, and no product in this category gives you both cheaply.

📖 See also The Best Web Search API for AI Agents in 2026

How does a SERP API work?

A Google mirror works by scraping, and every honest vendor in that group will tell you so. The endpoint takes your query, issues it against Google from infrastructure the vendor operates, parses the HTML that comes back, and returns the parsed shape. Nothing about that is exotic, and everything hard about it lives in the parts you do not see.

What a mirror actually does on each request

It picks an exit address, renders or fetches the page, survives whatever bot check fires, and parses a layout that changes without notice. That last part is the real product. Google ships SERP layout changes constantly, and the value of a mirror is that somebody else maintains the parser. Run one yourself and you are not buying search, you are volunteering to maintain a parser for a page you do not control.

You can read the provenance straight out of the response. Calling api.strale.io/x402/google-search through Monid on 21 August 2026 returned a _meta.provenance.source of google-serper, which is the endpoint telling you exactly whose crawl it sits on. That is the right amount of honesty for this category, and it is worth checking before you architect around a result.

Why the same query returns three different answers

Because the three kinds are not sampling the same thing. Ask a mirror and an index the same question and the overlap is often under half, and neither is wrong. The mirror reports what Google ranked, which is shaped by commercial intent, freshness signals and personalisation defaults. The index reports what its own retrieval thinks is closest to the meaning of the query. If your evaluation harness assumes the two should agree, it will report a bug that is really a category difference.

The legal shape changed in July 2026

This is the part the explainers skip, and it belongs in an architecture decision. Google sued SerpApi on 19 December 2025 over scraping and reselling search results. On 20 July 2026 the Northern District of California dismissed both of Google's DMCA claims, one of them permanently, holding that Google had not shown its SearchGuard protection operated with the authority of a copyright owner. Google's standing and its circumvention allegation survived, and Google filed an amended complaint weeks later. The case is live as of August 2026.

The practical read is not that mirrors are doomed. It is that the three kinds carry structurally different exposure: a mirror resells someone else's results page, an independent index resells its own crawl, and a read-through fetcher takes the text from the publisher. If that distinction matters to your legal team, it is a design input rather than a footnote.

📖 See also Bing Search API Retired: What Actually Replaces It

How do you use a SERP API?

The three steps below are the same whichever kind you picked: find the endpoint, run one small query, then decide whether you need the page bodies. Everything expensive is in the third step, so it goes last on purpose.

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. Find the endpoint before you pick a vendor

What it does. Searches the catalog by capability, so you compare response shapes rather than marketing pages.

The endpoints. api.strale.io/x402/google-search for the mirror, exa/search for the index, context.dev/web/search for the read-through.

The call.

monid discover -q "google search results serp"
monid inspect -p api.strale.io -e /x402/google-search

What comes back. A ranked list carrying the provider, the billing shape and the current price, then the full input schema for whichever row you inspect.

What it costs. Nothing. Discovery and inspection never bill, which is the point of doing them before you commit to a vendor.

Step 2. Pull ranked results

What it does. Runs one query and returns the structured result set.

The endpoints. api.strale.io/x402/google-search when you need positions, context.dev/web/search when you need coverage.

The call.

monid run -p api.strale.io -e /x402/google-search \
  --query '{"query":"rotating proxy","country":"us","num_results":10}' -w

monid run -p context.dev -e /web/search \
  -i '{"query":"rotating residential proxy pricing 2026","numResults":10}' -w

What comes back. From the mirror, verified on 21 August 2026: query, then results[] carrying position, title, url, snippet, date and sitelinks, plus result_count, knowledge_graph, answer_box and people_also_ask. Those three block fields come back empty when Google did not render the block, which is information rather than a failure. From the read-through: results[] carrying url, title, description, relevance and a markdown object.

What it costs. The mirror bills per call and sits well above the read-through, which bills per result. Current figures live on monid.ai/tools, and inspect shows the exact number before anything runs.

Step 3. Read the pages, but only the ones you kept

What it does. Turns the handful of results you actually want into text a model can use.

The endpoints. context.dev/web/scrape/markdown for one URL, octen/extract for up to twenty at once, tinyfish/fetch for a free batch of up to ten.

The call.

monid run -p context.dev -e /web/scrape/markdown \
  --query '{"url":"https://example.com","useMainContentOnly":true}' -w

What comes back. success, markdown, contentLength, url, and a metadata object carrying sourceUrl, finalUrl, title and language. Verified 21 August 2026.

What it costs. A fraction of a cent per page. The detail that matters is not the figure: context.dev bills only successfully scraped pages, so a blocked fetch does not charge, and octen returns failed URLs with a failed status and does not bill those either. That billing unit is the whole argument against buying bandwidth instead, which the proxy guide works through in full.

📖 See also A Free API to Extract Page Content for RAG

Serper vs SerpApi vs Tavily: which comparison actually matters?

Almost none of the comparisons people search for are between like products, which is why they are hard to resolve. Serper versus SerpApi is a real one, because both are Google mirrors and they differ on latency, price and how much of the page they parse. That comparison you can settle with a benchmark.

The others are category confusions wearing a versus. SerpApi against Tavily puts a mirror next to a retrieval service built for agents. SerpApi against Firecrawl puts a mirror next to a read-through fetcher. SerpApi against Brave puts a mirror next to an independent index. In each case the honest answer is that they solve different problems, and the useful question is which problem you have.

So run the comparison in this order. First, do you need positions? If yes, only a mirror qualifies and the rest of the field is irrelevant. If no, do you need page text in the same hop? If yes, you want a read-through fetcher, and paying mirror prices for snippets is waste. If neither, you want an index, and you should be evaluating recall and freshness rather than SERP fidelity.

That ordering matters more than any feature table because the wrong kind fails quietly. A mirror pointed at a RAG job returns ten plausible titles and no substance, and the pipeline downstream produces confident thin answers rather than an error anyone can see.

📖 See also Automate SERP Tracking with a Structured Google Search API

Which endpoint should I use for which job?

Every row verified with monid inspect on 21 August 2026. The table states the billing shape rather than a figure, because the shape changes your architecture and a number goes stale silently.

When should you use Google's own API instead?

When the results are the product you are selling. Google runs licensed programmes for exactly this, and a mirror is not a substitute for a licence when your business depends on redistributing search results at scale. The litigation above is the reason to read that sentence as advice rather than as boilerplate.

Use Google's Custom Search JSON API when your job is site search or a narrow set of domains. It is cheap, it is supported, its quota is published, and nothing about it can be taken away by a court. It is a poor general web search and an excellent constrained one, and plenty of teams reach for a SERP API when this was the right tool.

Go direct to a single vendor when one search product dominates your usage. If you send millions of queries a month to one mirror, a committed contract with that vendor will beat per-call pricing, and the honest recommendation is to sign it. A catalog earns its place when you do not know in advance which of the three kinds a given job needs, not when you settled that question a year ago.

Conclusion

There is no best SERP API, because SERP API names three products and the winner depends entirely on whether you need positions, documents or text. Deciding that first collapses a twenty-vendor comparison into a three-way one, and the three-way one is easy.

Two things matter more than the vendor choice. The first is that a mirror is a parser somebody else maintains for a page Google changes without notice, and that maintenance is what you are actually buying. The second is that the legal shape of the three kinds genuinely differs, and after July 2026 that is a design input rather than a hypothetical.

Free next step: run monid discover -q "google search results serp" and monid inspect the two rows that look closest to your job. Both are free, and comparing two real schemas beats comparing two pricing pages. Start at monid.ai.

FAQ

Last updated August 2026.