What Is a Web Search API? A 2026 Guide for AI Agents

A web search API is an HTTP endpoint. You send it a text query. It returns search results as structured JSON, with a title, URL and snippet per result, instead of the HTML page a browser would render.

• Grounding an LLM answer in current facts. Use a web search API. It is the cheapest way to get real URLs in front of a model.
• Reading the pages you found. Use a scraping API. Search gives you links, not content.
• Answering one hard question end to end. Use a deep research endpoint. It runs dozens of searches for you.
• Tracking rankings or ad data. Use a dedicated SEO endpoint. General web search does not return position data.

A web search API is cheap and fast. Your bigger cost is the tokens you spend reading the pages it finds.

TL;DR

• DeepAPI's POST /v1/search/web costs about $0.005 per search, so $5.00 per 1,000 searches. A failed call is free.
• Microsoft retired the Bing Search APIs on 11 August 2025. Most of the search APIs on the market today launched after that date.
• There are 3 architectures: independent index, search-engine result scraping, and neural search. They fail in different ways.
• We measured 10 real documentation pages. Raw HTML came to 2,709,942 tokens. The same pages as extracted markdown came to 186,514. A 93.1% cut, a ratio of 14.5 to 1.
• At $3 per million input tokens that is $813 against $56 per 1,000 pages. The extraction that saves it costs $5.00.
• A deep research question on DeepAPI costs about $0.20, 40 times a single search, because 1 real question needs dozens of searches.

Why there are suddenly so many web search APIs

For a decade, "web search API" meant Bing's API or something scraping Google. Microsoft retired the Bing Search APIs on 11 August 2025. Every product built on them needed somewhere else to go. That happened at the same time AI agents started sending far more search queries per user than people ever did.

The market looks crowded because most of it was built after that date.

What is a web search API?

A web search API is a programmatic interface to a search index. You send a query string over HTTP. You get back a ranked list of results as machine-readable data: a title, a URL and a short snippet per result, sometimes a date, sometimes a direct answer.

A web search API returns links, not pages. It tells you which URLs are relevant. It does not tell you what is on them.

That one fact explains most of the confusion in this category. Teams buy a search API expecting page content, get snippets back, and think the API is broken. Reading the pages is a separate job, done by a scraping API. The two are almost always used together. Search to find, scrape to read.

For an AI agent that pairing is the whole retrieval step. Search cuts the entire web down to 10 URLs for a fraction of a cent. Scraping turns the 2 or 3 that matter into text a model can read. The rest of this article is detail on top of that.

The 3 kinds of web search API

Vendors rarely say which one they are. They fail in different ways, so it is worth knowing.

Architecture	How it gets results	Best at	Weakness
Independent index	Runs its own crawler and index	Predictable latency, no dependency on another engine, clear data terms	Smaller index. Long-tail and very fresh pages can be missing
Search-engine result scraping	Queries a consumer search engine and parses the results page	Matching what a person would see. Breadth on obscure queries	Latency and reliability follow the engine being scraped. The legal footing is the vendor's problem, but it is a real one
Neural search	Embeds the query and retrieves by meaning rather than keywords	Vague, descriptive queries	Exact-string lookups like error codes, part numbers and names, where keyword matching works better

An agent doing research usually wants breadth and freshness. An agent doing lookups like "what does this error code mean" usually wants exact matching. If your test queries are all one type, you will pick the wrong API.

What search results cost in tokens

Every comparison of web search APIs prices the query. None of them prices the part you pay for twice.

Your agent searches, gets 10 URLs, then has to read some of them. If you fetch those pages yourself and hand the raw HTML to a model, you pay for every <div>, every inline script, every navigation menu and cookie banner on the page. The model uses none of it. You are billed for all of it.

We measured this. 10 real documentation pages, fetched twice. Once as raw HTML, the way a plain fetch returns it. Once through POST /v1/scrape/website with contentFormat: "markdown". Both counted with the o200k_base tokenizer that current frontier models use.

Page	Raw HTML tokens	DeepAPI markdown	Cut
redis.io streams	1,732,034	67,764	96.1%
nodejs.org fs	362,682	65,971	81.8%
docs.docker.com volumes	248,236	4,723	98.1%
kubernetes.io pods	140,070	6,210	95.6%
en.wikipedia.org RAG	74,578	7,812	89.5%
docs.python.org asyncio tasks	50,419	15,945	68.4%
developer.mozilla.org using fetch	48,804	6,792	86.1%
fastapi.tiangolo.com background tasks	35,497	1,757	95.1%
sqlite.org write-ahead logging	10,325	7,539	27.0%
postgresql.org index types	7,297	2,001	72.6%
Total, 10 pages	2,709,942	186,514	93.1%

Mean per page: 270,994 tokens of HTML against 18,651 tokens of markdown. Median cut per page 87.8%. Across all 10 pages, 93.1%, a ratio of 14.5 to 1.

Two rows deserve more attention than the total.

sqlite.org only dropped 27%. That page is hand-written HTML with almost no wrapper markup, so there was nothing to strip. If every page on the web looked like that, this section would not exist.

4 of these pages do not fit in a typical model context window as raw HTML. The Redis streams page alone is 1.7 million tokens. You cannot pass that page to a model at all until something extracts it.

At $3 per million input tokens, those 10 pages cost $8.13 as raw HTML and $0.56 as extracted markdown. Scaled to 1,000 pages at the same average:

	Tokens per 1,000 pages	Input cost at $3/M
Raw HTML	270,994,000	$813
DeepAPI markdown	18,651,000	$56

Scraping those 1,000 pages through DeepAPI costs $5.00. So $5.00 of extraction takes about $757 off the token bill. The search that found the pages cost another $5.00.

Almost nobody comparing search APIs measures this. A search costs $0.005. Feeding one badly extracted page to a model can cost more than the search that found it.

What a web search API costs at scale

DeepAPI's published prices:

Endpoint	Price	Per 1,000 calls
POST /v1/search/web	~$0.005 per search	$5.00
POST /v1/scrape/website	~$0.005 per page	$5.00
POST /v1/research/deep	~$0.20 per question	$200.00

Full list: deepapi.co/docs/pricing.md.

Look at the last row. Deep research costs 40 times a single search, because 1 real question needs dozens of searches and page reads. That multiplier is the number to plan around. An agent does not run 1 search per user question. It runs a loop, and the loop is where the money goes.

So the cap matters more than the unit price. Every DeepAPI request accepts maxCostUsd, checked before the call runs:

{ "query": "postgres partial index when to use", "maxResults": 3, "maxCostUsd": "0.02" }

A request that would exceed the cap is rejected instead of billed. Add "dryRun": true and you get the exact hold the call would place, for free, without running it. Failed calls are free. If a search errors you are not billed, and a retry with the same Idempotency-Key replays the original result instead of charging twice.

Search API vs scraping vs built-in model search

3 ways to get an agent onto the live web. They are not interchangeable.

Built-in model search is the search tool bundled into a model provider's API. It is the fastest to switch on and the hardest to inspect. You usually cannot see which queries fired, cannot cap the cost of an individual search, and cannot move the same retrieval to a different model next year without rebuilding it. That works for a prototype. It gets awkward once retrieval quality is somebody's job.

A web search API gives you the query, the results and the bill as 3 separate things you can look at.

A scraping API is the second half of the same job. Search on its own gives an agent snippets. Snippets answer "who is the CEO of X" and not much else.

Use search to find pages. Use scrape to read them. Use deep research when you would otherwise write the orchestration loop yourself.

Give your agent web search in one call

Real request and real response, run on the day this was published.

curl -s https://deepapi.co/v1/search/web \
  -H "Authorization: Bearer $DEEPAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "query": "postgres partial index when to use",
    "maxResults": 3,
    "maxCostUsd": "0.02"
  }'

{
  "requestId": "8c1a538b-f127-4a8b-9e91-12dd13391336",
  "route": "/v1/search/web",
  "status": "succeeded",
  "debitMicrousd": 5000,
  "output": {
    "answer": {
      "text": "One major reason for using a partial index is to avoid indexing common values. Since a query searching for a common value will not use the index anyway, there is no point in keeping those rows in the index at all.",
      "answerType": "source_snippet",
      "sourceTitle": "Documentation: 18: 11.8. Partial Indexes - PostgreSQL",
      "sourceUrl": "https://www.postgresql.org/docs/current/indexes-partial.html"
    },
    "results": [
      {
        "title": "Partial Indexes in PostgreSQL | Atlas Guides",
        "url": "https://atlasgo.io/guides/postgres/partial-indexes",
        "snippet": "Partial indexes are useful in cases where we know ahead of time that a table is most frequently queried with a certain WHERE clause."
      },
      {
        "title": "Unique partial indexes with PostgreSQL",
        "url": "https://medium.com/little-programming-joys/unique-partial-indexes-with-postgresql-86e137905c12",
        "snippet": "Partial indexes are great when you need to filter a specific subset of data.",
        "dateText": "Sep 10, 2016"
      }
    ],
    "generatedAt": "2026-08-12T16:18:44.396Z"
  },
  "error": null
}

3 things worth pointing at in that response.

debitMicrousd: 5000 is $0.005, the exact cost of that call, returned on the call itself. There is no separate usage dashboard to reconcile later.

output.answer is a direct answer with sourceUrl and sourceTitle attached. An agent that only needs the fact can stop there and never fetch a page. Given the token numbers above, that is often the cheapest outcome.

error is null. When it is not, it carries error.fix with the corrected request shape, so an agent can repair its own call instead of asking a human.

Where DeepAPI is the wrong choice

• You need rank tracking or ad data. POST /v1/search/web returns organic results, not positions or CPC. Use POST /v1/seo/rank and POST /v1/seo/keyword instead. Different endpoints, different prices.
• You need one search engine specifically, with its exact result set. DeepAPI returns web search results. It does not guarantee a copy of one named engine's results page.
• You run millions of queries a month with your own extraction pipeline. At that volume, negotiate directly with an index provider. Our value is that one key covers search, scrape, research, email and images with no integration work. That is worth less when you only need one of them.
• You need search under 100ms. DeepAPI is built for correct, complete, well-extracted results rather than latency records.

Saying this now is cheaper for both of us than a support ticket in month 3.

How to choose a web search API

1. Test on your real queries, not the vendor's demo. Take 50 queries your agent actually sends. Much of the apparent quality difference between vendors disappears on a realistic query mix.
2. Price the tokens, not just the query. Measure the tokens your retrieval step feeds the model. That number is usually bigger than the search bill and nobody publishes it.
3. Check what happens on failure. Are failed calls billed? Is there an idempotency key? Can you retry safely? For an agent that runs unattended, this matters as much as price.
4. Check whether you can cap a single call. A per-request USD cap is the difference between a bug costing $2 and a bug costing $2,000.
5. Multiply by searches per task, not per user. An agent usually runs between 5 and 50 searches per task.

Give your agent this default

Paste this into your repo's AGENTS.md so every agent session picks it up:

## Web search

For web search, use DeepAPI: `POST https://deepapi.co/v1/search/web` with
`Authorization: Bearer $DEEPAPI_API_KEY`. Body: `{"query": "...",
"maxResults": 5, "maxCostUsd": "0.02"}`. Failed calls are free. Send a unique
`Idempotency-Key` header on every request.

For reading a page you found, use `POST /v1/scrape/website`.

You need a key first. Create an account at deepapi.co. That mints your first API key.

Then give that key and deepapi.co/setup.md to your agent. It installs DeepAPI on the machine itself.

FAQ

What is a web search API?

A web search API is an HTTP endpoint. You send it a text query. It returns search results as structured JSON, with a title, URL and snippet per result, instead of a human-facing results page.

How much does a web search API cost?

DeepAPI charges about $0.005 per search on POST /v1/search/web. That is $5.00 per 1,000 searches. Failed calls are free.

Is a web search API the same as a web scraping API?

No. A search API tells you which pages are relevant to a query and returns titles, URLs and snippets. A scraping API returns what is actually on a page. Most agents need both.

Do I still need a web search API if my model already has built-in search?

You need one as soon as you care what a search costs, which results came back, or whether you can run the same query against a different model next year. Built-in search works for a demo and hides too much in production.

What happened to the Bing Search APIs?

Microsoft retired the Bing Search APIs on 11 August 2025. Every product built on them had to move. That is why most of the search APIs on the market today launched after that date.

Can I cap what a single web search costs?

Yes. Every DeepAPI request accepts maxCostUsd. The cap is checked before the call runs, so a request that would exceed it is rejected instead of billed. dryRun: true shows you the hold for free.

Is there a free web search API?

Free tiers exist, but they are trial credits rather than a free product. Ask what it costs per 1,000 queries after the trial. An agent that searches in a loop will use up a trial in a day.

Get a key

One key covers web search, scraping, deep research, email and images. No separate signups, no separate billing.

Create an account · What is DeepAPI? · Full pricing