Research-backed calculator guide

Search API Billing Units: Compare Successful Requests, Queries and Fetch Calls

Learn how search, query, and fetch billing units differ across AI web-search APIs, then reconcile a realistic monthly workload with explicit success and grouping assumptions.

Why “per search” is an unsafe shortcut

A user may describe one research task as “a search,” but the API can see several events. Your application might submit one request containing five queries, retry once after a timeout, fetch three selected pages, and pass the fetched text to a model. A vendor that bills requests will see a different count from a vendor that bills individual queries. A vendor that charges fetch calls separately will produce a different invoice again.

Use four labels in your usage export:

1. Logical query: the question or search expression your workflow intended to run.
2. Search request: one HTTP request sent to a search endpoint.
3. Fetch request: one HTTP request sent to retrieve a selected page or document.
4. Downstream model call: the generation or reasoning request that consumes search or fetched content.

These labels are not synonyms. They are reconciliation dimensions. For example, five logical queries bundled into one successful Perplexity Search API request may be five queries but one request billing unit. In contrast, Google's documented grounding charge is based on each individual search query performed, so the same high-level task could create multiple billable query units. ^{[3] [5]}

A second distinction is attempt versus billable success. A timeout is an attempt in your application log. It may be non-billable under one provider's rule, but your retry can still create a later successful event. Never subtract all failures from a monthly counter unless the provider defines the same success predicate and your export exposes it.

A third distinction is retrieval price versus answer price. A search or fetch meter generally does not include the model tokens used in a later completion. Perplexity's Search API documentation says there is no token billing for Search API itself, but its Agent API tool calls and model usage have separate meters. Google's grounding prices sit beside model token rates. ^{[3] [5]}

Provider comparison: billing denominator and success rule

Use this table as the compact comparison layer. The rate, allowance, endpoint, and success predicate belong together; separating them prevents a headline price from being applied to the wrong event.

The first row deliberately keeps separate retrieval meters visible rather than adding Search and Fetch into one “search” price. The second row makes grouping a cost variable: five logical queries can occupy one successful request. The third row makes query fan-out the cost variable: one application prompt can produce more than one chargeable query. These are different denominators, not competing names for the same unit.

Perplexity: successful Search API requests, not query strings

Perplexity's pricing page separates Search API from its Orchestrator, Agent, Embeddings, and Decisions APIs. For Search API, the billing unit is each successful POST /search request. An array of up to five queries in one request counts as one billing unit. The page also says a successful response is billed even when it returns no results, while invalid, rate-limited, and upstream-failure requests are not billed. ^[3]

The grouping assumption is therefore decisive. If your application sends 12,000 logical queries one at a time, the standard Search API estimate is 12,000 successful requests. If it batches five queries per successful request and the API accepts every batch, the request count is 2,400. Those are not two interpretations of the same invoice; they are two different request designs.

The separate Agent API tool table should not be mixed into a Search API estimate. The pricing page lists web_search and fetch_url tool fees for Agent API calls, plus model-token charges. Use the Search API rate only when your integration actually calls the Search API endpoint. ^[3]

When reconciling Perplexity usage, retain both counters: perplexity_successful_requests and perplexity_logical_queries. The first supports the Search API invoice calculation; the second explains grouping efficiency and helps you compare the workflow with providers that count individual queries. If a batch is retried, record the original attempt, its status, the retry, and the final successful request rather than silently multiplying the logical-query count.

Google Gemini grounding: individual search queries

Google's Gemini API pricing page explicitly warns that a customer-submitted request may result in one or more queries to Google Search and that each individual search query is charged. This is the core reconciliation rule: a prompt is an input event, while a query is the documented billing event. You need an observed query count from usage data or a conservative estimate of queries per prompt.

The same page lists a paid-tier allowance of 5,000 free search requests per month shared across Gemini 3 and newer models, followed by $14 per 1,000 search queries. Because the allowance and pricing are time-sensitive, record the date, model family, tier, and whether your account shares the allowance across projects before comparing it with another provider. ^[5]

For Gemini, export or estimate gemini_search_queries independently from gemini_prompts. If telemetry shows an average of two search queries per prompt, multiplying prompts by two is a stated planning assumption; it is not proof that every prompt creates exactly two billable events. Apply the allowance once at the correct account or project scope, and do not subtract it separately for every model call unless the provider's billing scope says to do so.

Worked cost example: Perplexity grouping versus Gemini query billing

Assume a US-dollar planning scenario for one calendar month. The workflow intends 12,000 logical research queries. The comparison focuses on Perplexity grouping and Gemini's individual-query denominator. Ignore downstream model-token charges in the first pass so retrieval meters remain visible. Also assume no enterprise discount, no tax, no subscription fee, and no extra result or storage charge. These are planning assumptions, not vendor quotes beyond the rates cited above.

The first two rows show why grouping can change the Perplexity estimate from $60.00 to $12.00 without changing the number of logical questions. The third row changes only the selected Search API rate. The Gemini rows show a different pattern: whether 12,000 queries came from 12,000 prompts or 6,000 prompts, the chargeable denominator is still 12,000 individual queries before the allowance. If you only know prompt volume, the Gemini result remains uncertain until query fan-out is observed or stated as an assumption. ^{[3] [5]}

Now add retries without hiding them. Suppose 3% of intended Perplexity requests fail before a successful retry, and every retry later succeeds. For the grouped design, 2,400 initial requests plus 72 successful retry requests produces 2,472 billable requests, or $12.36 at the standard rate. If the failed attempts are excluded by the provider's billing rule and never produce a successful retry, they do not belong in the billable request counter. The export, not the application error log alone, decides which case applies. ^[3]

For Gemini, the analogous question is whether a failed application attempt generated a Google Search query and how the provider represents it in usage data. Do not force a request-based retry formula onto a query-based meter. Count documented query events, keep prompt and retry identifiers for auditability, and label any missing fan-out as an estimate. ^[5]

Finally add downstream model use. A search result or fetched page may become input tokens for a model call, and a search result may cause a second answer call. That spend belongs in a token ledger, not hidden inside the Search or grounding row. Use the AI token cost calculator for token assumptions and the LLM cost calculator when the retrieval workflow is part of a broader monthly agent budget.

A practical reconciliation workflow

Start by choosing one reporting period and one currency. Keep vendor prices in the unit the vendor publishes, normally USD per 1,000 requests or queries. If your finance system converts currencies, preserve the original USD calculation beside the converted amount and record the exchange-rate date separately.

Next, export provider usage with the smallest available dimensions: timestamp, project or key, endpoint, status, success predicate, query count if exposed, and any model or tool identifier. Map each row to search_request, logical_query, fetch_request, retry, or model_call. If the provider only reports aggregate requests, mark query counts and success splits as estimated rather than inventing precision.

Then apply the provider rule. For a provider with separate Search and Fetch meters, count successful Search and Fetch events separately. For Perplexity Search API, count successful HTTP requests and track how many logical queries were grouped inside each. For Gemini grounding, count individual search queries and subtract only the documented free allowance that applies to your tier and model family. ^{[1] [3] [5]}

Finally, compare the estimate with the invoice line items. A clean reconciliation has three explanations for variance: volume variance, unit-price or tier variance, and event-definition variance. The third category catches the most common error: comparing your “number of research questions” with a vendor's “number of successful requests.” Put the reconciliation into the AI API invoice reconciliation calculator once the raw counters are stable.

What search results cover and the useful gap

The 2026-11-02 English-US result snapshot returned official rate cards, provider implementation guides, independent comparison articles, a vendor pricing page, and a practitioner discussion. Recurring coverage was provider-by-provider pricing, often normalized to dollars per 1,000. The more useful detail appeared lower in the pages: some providers separate Search from Fetch, Perplexity separates requests from bundled queries, and Google separates prompts from individual queries. ^{[1] [3] [5]}

The observed opportunity is a reconciliation view rather than another headline-price list. A reader can use one table to state what was attempted, what succeeded, what was bundled, what was fetched, what was retried, and what model tokens were added. That makes the method inspectable without claiming that any provider is universally cheaper or that a search ranking outcome is guaranteed.

FAQ

Is one search request the same as one search API billing unit?

No. It depends on the provider. Some providers document successful Search requests as units, Perplexity documents successful Search API HTTP requests as units even when a request contains multiple queries, and Google documents each individual grounding query as the unit. Use the provider's own success and grouping definition rather than the user-facing word “search.” ^{[1] [3] [5]}

How should I model a workflow with separate Search and Fetch events?

Keep Search and Fetch in separate ledger rows with separate status and success fields. Do not multiply a Search count by the number of returned results, and do not assume every selected result becomes a successful Fetch. Reconcile each endpoint against its own usage export, then add downstream token rows separately. If you need provider-specific arithmetic, use the linked provider guide in the comparison table rather than borrowing a generic request formula.

Does Perplexity charge per query inside a multi-query request?

The Search API pricing page says no: billing is per successful POST /search request, and a successful request containing an array of up to five queries is one billing unit. That rule applies to the Search API estimate, not automatically to every Perplexity product or Agent API tool. Verify the endpoint in your logs before applying the rate. ^{[3] [4]}

Can a Google Gemini prompt create more than one search charge?

Yes. Google states that one customer-submitted request may result in one or more queries to Google Search and that each individual query is charged. A prompt count is therefore only a proxy until you know the query fan-out. Record observed queries per prompt, apply the applicable free allowance, and date the calculation because pricing and model-family allowances can change. ^[5]

Should model tokens be included in search API cost?

Include them in the total workflow cost, but keep them as separate ledger rows. Retrieval charges answer “what did the search or fetch service meter?” Model-token charges answer “what did the downstream model process?” Combining them into one unexplained rate makes invoice reconciliation harder and can hide a change in fetched content length.

What assumptions should I show in a monthly estimate?

Show the reporting period, currency, provider endpoint, logical queries, successful requests, successful fetches, grouping factor, retry policy, free-tier allowance, published rate, and exclusions. Label any estimated query fan-out or success rate as an assumption. Do not present a derived cost as a vendor quote, and do not include enterprise discounts unless your contract supplies them.