Web search API cost per query: credits, requests, pages, and tokens

Nobody sells web data in the same unit. Ask what a search costs and one vendor answers in requests, another in credits, another in pages, another in tokens, and another in gigabyte-hours of compute. Every one of those numbers is published and accurate. None of them can be compared to the others, which is why a pricing page tells you almost nothing about what your product will spend.

The unit that transfers is cost per resolved answer: total spend divided by the number of tasks your agent actually finished, including the ones it had to retry. It is the only figure that survives a vendor swap, because it absorbs the multipliers, the double-billed content calls, the token weight of whatever the API hands back, and the tail of retries. It is also the figure nobody publishes, because computing it requires knowing your loop.

The arithmetic below builds that number from public rates. The result is uncomfortable for anyone currently negotiating a per-thousand discount: in a normal retrieval loop, the web data vendor is a single-digit percentage of the bill, and the decision that moves cost most is how many tokens each returned result costs you downstream. For where price levels sit inside one category, see the cheapest SERP API comparison; this guide is about converting between categories.

Five billing units in one market

Sort the market by what the meter counts and five groups fall out. Each hides a different kind of cost.

Per request. You pay for a call and the response size is your problem. SerpApi is the clean example: its FAQ states that responses with 100 results and empty result sets both cost one search credit, and that cached, errored, and failed searches are not counted. This unit is honest and easy to forecast, and it gives you no incentive to ask for less data.

Per credit. A credit is an internal currency with a conversion table you have to go find. Firecrawl, ScrapingDog, and Tavily all bill this way. The plan price divided by the credit allowance is not your unit cost until you multiply by the feature rate.

Per page or per result. Exa separates the search from the content: its published rates are $7 per 1,000 searches plus $1 per 1,000 content pages returned. This is the most honest unit for a RAG pipeline, because it prices the thing that actually enters your context window.

Per token. Jina AI's Reader bills on the token count of the output it produces, and its Search endpoint charges a fixed block starting at 10,000 tokens per request. Perplexity Sonar mixes per-token pricing with a per-request search fee. Token billing is the only unit that scales with the thing you care about, and it is the hardest to forecast in advance.

Per compute unit. Apify defines one CU as 1 GB of RAM running for one hour, priced at $0.20 on the Free and Starter plans, $0.16 on Scale, and $0.13 on Business, with proxies, storage, and data transfer drawn from the same prepaid credit pool. Cost here is a function of how slow the target site is, which is not something you control or can quote in advance.

A pricing page comparison across these five groups is not a comparison. It is five different questions with five different answers printed next to each other.

Credits are not pages: the multiplier table

The single most common budgeting error is dividing plan price by credit allowance and calling the result a per-page cost. Here is what one unit buys at each vendor, from published rates as of July 2026.

Two rows deserve attention. ScrapingDog's Standard plan is $90 for 1M credits, which reads as $0.09 per 1,000. Run the same workload through JavaScript rendering and a premium proxy and you are at 10 credits per request, or $0.90 per 1,000, still cheap but ten times your first estimate. Apify's row has no per-page number at all, because a CU measures wall-clock time against a site you do not control.

Search calls that bill twice

A category of pricing surprise comes from APIs that charge separately for finding a result and for reading it. This is not hidden, but it is easy to miss when comparing headline rates.

Exa lists $7 per 1,000 searches and $1 per 1,000 content pages. A search returning 10 pages of content therefore costs $0.007 for the search plus $0.010 for the content, so the content is the larger half. Firecrawl charges 2 credits per 10 search results, and then 1 credit for every page you actually scrape from those results. Brave's Answers plan lists $4 per 1,000 requests plus $5 per million input and output tokens, so the token component grows with the length of what the answer had to read.

The pattern generalizes. Vendors that quote a low search price and a separate content price are usually cheaper for a workload that filters aggressively, because you pay full price only on the results you keep. Vendors that bundle content into a flat per-search price are cheaper for a workload that reads everything it retrieves. Neither is a better deal in the abstract, and you cannot tell which you are until you know your keep rate: the fraction of returned results your agent actually fetches and reads.

If your keep rate is under about a third, unbundled pricing wins and the gap widens with volume. If you read nearly everything, bundled wins and the second line item is pure overhead.

What a returned result costs you in context tokens

No vendor prices this line, because it arrives on someone else's invoice. Every page a web data API returns goes into a model context window, and that model bills per token. The API charges you a fraction of a cent to fetch the page. The model charges you considerably more to read it.

The number that governs this is tokens per returned page after cleaning, and it varies by more than an order of magnitude depending on what the extraction layer does. Raw HTML carries markup, navigation, scripts, and boilerplate. Cleaned markdown drops most of that. A summarized or field-extracted result drops nearly all of it. How far apart those three land depends on your target sites, so no published figure covers it. Measure it on a sample of your own corpus rather than taking a number from anyone's marketing page. For the extraction-quality side of this trade-off, see extracting clean markdown from web pages.

Once you have that number, the comparison becomes arithmetic. Suppose a fetched page is 5,000 tokens of cleaned markdown, and your model charges $3 per million input tokens. Reading that page costs $0.015. Firecrawl fetched it for roughly $0.0007 on the Growth plan. The model is spending about twenty times what the data vendor did on the same page.

This inverts the usual procurement instinct. The lever with the largest coefficient is not the price per thousand requests. It is how many tokens each retained result costs you, and that is a function of the extraction format you choose and how many results you keep.

A cost-per-resolved-answer model for a single agent loop

Write the loop as an equation with five terms, all per task:

cost_per_answer = ( S·p_search + P·p_fetch + T_in·p_in + T_out·p_out ) / success_rate

where S is search calls per task, P is pages fetched per task, T_in is total input tokens (fetched content plus snippets plus your prompt scaffolding), T_out is generated tokens, and each p is the real unit price after multipliers. Dividing by success rate is what turns cost per attempt into cost per answer.

Every term is measurable in an afternoon of instrumentation. The volumes and the success rate are yours to change; the unit prices belong to your vendors, and only p_search and p_fetch move in a pricing negotiation.

Two failure modes to watch when you fill this in. First, teams count S as one because the product spec says "search the web," when the agent actually issues three or four queries per task after reformulation. Second, teams set T_in from the pages fetched and forget that a multi-turn loop resends the accumulated context on every turn, so a four-turn loop can carry the same 20,000 tokens three or four times unless you are pruning or caching. Both errors push the estimate low by a factor of several.

Fan-out, retries, and the tail that wrecks the estimate

Averages hide the part of the bill that grows fastest. Three tail effects matter.

Query fan-out. Agents that reformulate on a weak first result issue more searches than the happy path implies. This is usually a good product decision and a bad budgeting surprise. Instrument the distribution of searches per task, not the mean.

Retries on transient failure. Some vendors soften this: ScrapingDog states that failed requests are never charged, and SerpApi counts only successful searches against quota. That is real protection on the data line and none at all on the model line, because the loop still paid to decide to make the call and to decide what to do about the failure. Retries are cheap in data terms and expensive in token terms.

Hard failures that consume a full loop. A task that runs to completion and returns a wrong or unusable answer costs the same as a correct one, plus whatever the second attempt costs. If 5% of tasks are restarted from scratch and 15% need one extra retrieval pass, your effective multiplier is around 1.25.

Treat that multiplier as a first-class number. Applied to a $10,000 monthly bill it is $2,500, which is larger than any discount you will negotiate on the search line.

Where free tiers hide the number you will actually pay

Free tiers are sized to a demo, and a demo does not exercise the expensive paths. Firecrawl's free plan includes 1,000 credits a month, SerpApi's includes 250 searches, Serper gives 2,500 credits, Tavily gives 1,000 credits a month with no card, Brave applies $5 in monthly credit automatically, and Jina gives 10 million tokens on signup.

Three things stay invisible at that scale. Feature multipliers, because a hundred trial calls rarely need premium proxies or rendering. Concurrency ceilings: SerpApi documents hourly throughput at 20% of plan volume for plans under 1M searches a month, Brave lists 50 QPS on Search and 2 QPS on Answers, and Jina's Reader runs 20 requests per minute without a key against 500 with one. And the tail, because a hundred calls will not produce a representative failure rate.

The test that produces a usable number is a single day of production-shaped traffic against your real target sites, with the vendor's dashboard open. Anything less measures the vendor's demo rather than your workload.

Committed spend, overage, and repricing risk

The unit rate is not the whole contract. Three commitment structures show up in this market and they behave differently under a volume change.

Expiring prepaid credits. Serper sells top-ups rather than subscriptions, and its pricing page states credits are valid for 6 months. The $0.30 per 1,000 headline requires buying 12.5M credits for $3,750 up front. If you burn 250,000 a month, you will not consume that block within its validity window, so your effective rate is the tier you can actually finish, not the one on the poster.

Monthly credits with no rollover. Apify's plans include prepaid platform credits that expire at the end of the month, with overage charged above the allowance. A workload with weekly spikes pays twice for the same variance: unused credit in quiet weeks, overage in busy ones.

Subscription with throughput caps. SerpApi's plans bundle a monthly search count with an hourly throughput limit derived from it. Buying for average volume leaves you rate-limited at peak.

Repricing risk cuts both ways and has mostly cut in the buyer's favor. Over the first half of 2026 several vendors in this space restructured pricing downward or split search from content billing, which is why directory listings and blog posts citing 2025 rates are frequently wrong in both directions. Anything in this guide is a July 2026 snapshot from vendor pricing pages, and the correct habit is to re-derive your cost per answer quarterly rather than to trust a table, including this one.

A worked example at 100,000 tasks a month

Assume an agent that answers 100,000 tasks a month. Per task it issues 2 searches, fetches 4 pages, carries 22,000 input tokens (four 5,000-token pages plus about 2,000 tokens of snippets and prompt), and generates 800 output tokens. Assume a 1.25x tail multiplier, so 125,000 loop executions produce 100,000 resolved answers. Model rates are stand-ins at $3 per million input and $15 per million output; substitute your own.

That is $0.103 per resolved answer, of which web data is $520.50, about 5% of the bill.

Now run the two available optimizations against it.

Renegotiate the search line. Moving from Serper Standard at $0.75 per 1,000 to Ultimate at $0.30 saves $112.50 a month, roughly 1.1% of total spend, and requires committing $3,750 to credits that expire in six months. Not worth the meeting.

Cut the token weight. Swap the fetch layer for one that returns a trimmed extract at about 1,200 tokens per page instead of 5,000 full-markdown tokens. Input per loop falls from 22,000 to 6,800, model input cost falls from $8,250 to $2,550, and the total lands near $4,570 a month. That is a 55% cut from a decision that never touched a price list.

One caveat on direction: the search-line arithmetic flips at the top of the range. Those same 250,000 monthly queries at SerpApi's Production list rate of $10 per 1,000 would be $2,500 a month rather than $187.50, at which point the vendor choice is the largest single lever in the table. At that volume you would be in custom-quote territory with SerpApi anyway, but the shape holds: the 12x gap between price tiers is material, and the 2.5x gap inside the cheap tier is noise next to the token line. See SerpApi vs Serper.dev for what the price difference buys.

What to do with this

Instrument the loop before you shop. Count searches per task, pages fetched per task, tokens per fetched page, and the retry multiplier, then price them at your plan's post-multiplier rates. That gives you a cost per resolved answer you can carry across vendors.

Then optimize in this order: cut tokens per retained result, cut results retained, fix the retry rate, and only then negotiate the per-thousand rate. Most teams do it backwards, because the per-thousand rate is the only number printed on a pricing page. If the exercise tells you the whole data line is a rounding error against your model bill, that is also an argument about where your engineering time should go, which is the same question addressed in build vs buy for web data.