The direct answer: the official search.listendpoint is the right tool for light, precisely filtered search — it works with a plain API key, offers a filter surface far richer than this actor's, and Google documents no fees for it. Its constraint is the quota bucket: 100 calls per project per day by default, at most 50 results per call, and every pagination page is another call, so a default project tops out at 5,000 search result items per day and going deeper on one query drains the same bucket. Raising the limit requires a compliance audit. For search at dataset scale — many keywords, results with audience counts attached, no Google Cloud project — the working route is the YouTube Search Scraper at $0.20 per 1,000 delivered results.
Every claim about the Data API below links Google's own documentation, all verified on 2026-07-22. The actor side was run first-hand on 2026-07-21 — the run and its evidence file are below.
The quota bucket, per Google's current docs
As of the June 2026 revision of Google's quota documentation, search.listno longer draws from the shared 10,000-unit pool. It has its own bucket: "The search.list and videos.insertmethods have their own quota buckets. Each of these methods has a default daily limit of 100 per day." The search.list reference states it the same way: 100 calls per day, each call costing 1 unit in the Search Queries bucket. If you have read that a search costs "100 units out of 10,000" — a number older articles may still cite — that was the previous accounting. The practical ceiling is unchanged (100 search.list calls per project per day) but the bookkeeping is separate now, and the other endpoints' 10,000 daily units are no longer consumed by searching.
Three documented details complete the arithmetic. Each call returns at most 50 results (maxResults accepts 0–50, default 5). Each additional page of results is another search.list call against the same bucket. And daily quotas reset at midnight Pacific Time. So a default project can retrieve at most 100 × 50 = 5,000 search result items per day — and only by spending its entire search budget. More requires the audit and quota-extension process: "you must first complete an audit to show that your project is in compliance with the YouTube API Services Terms of Service."
What a search result contains — and what it doesn't
Per the search resource representation, a search.list item carries an id and a snippet — title, description, channel, publish date, thumbnails. There is no statistics part: view counts are not in the resource schema. Getting them means a follow-up call to videos.batchGetStats, which returns public-video statistics and duration at 1 unit per call from its own granular quota bucket, 10,000 units per day by default (no OAuth needed for public videos), or to videos.list from the general pool for full video resources — cheap in quota either way; the cost is the extra round-trip and the ID plumbing, not the units. Also documented plainly: the totalResultsfield "is an approximation and may not represent an exact value," is capped at 1,000,000, and should not be used to build pagination. Google documents no overall pagination cap for a general keyword query; it separately documents a 500-video cap for channel-scoped searches (channelId set with type: video and no owner filter). The ~500-result ceiling reported in older articles for keyword queries is observed behavior, not documentation, and this page does not rely on it.
The decision, by dimension
| Dimension | Data API search.list | YouTube Search Scraper |
|---|---|---|
| search.list calls per day | 100 calls per project per day by default; each pagination page is a call; more requires a compliance audit. Google documentation. | No per-day cap on runs or queries; each run takes a batch of keywords. apihq documentation. |
| Results per call | At most 50 (maxResults 0–50, default 5). Google documentation. | One run pages until YouTube stops serving results or your maxResults cap; the run below delivered 199 unique videos (200 billed rows) for one query. First-hand run below. |
| Result depth per query | Not documented; totalResults is an approximation not meant for pagination. Google documentation. | Finite and set by YouTube — paging stops when relevance runs out, for most queries in the low hundreds; maxResults is a ceiling, not a guarantee. apihq documentation. |
| Fields per result | id + snippet (title, channel, publish date, thumbnails); statistics require a follow-up videos.batchGetStats (or videos.list) call at 1 unit. Google documentation. | Title, URL, audience count, duration, and channel on each video row, in one pass (lifetime views, or the concurrent audience on live rows). apihq documentation; shown on all 200 rows in the run below — 188 view counts, 12 live watching counts. |
| Filters | The richest surface in this comparison: order, publish window, region, language, duration, category, safe search, location radius, and more. Google documentation. | Result type, sort, upload window, and duration; narrower by design. apihq documentation. |
| Auth required | Google Cloud project + API key for public search (OAuth only for owner-scoped parameters). Google documentation. | Apify API token. By design — Apify platform auth. |
| Cost | No fees documented; usage is governed by quota. Google documentation. | $0.20 per 1,000 delivered results; queries that return nothing are unbilled. apihq list pricing. |
| Terms-of-service posture | Official API under the YouTube API Services Terms of Service. First-party assessment. | Reads public search results outside the official API; not affiliated with or endorsed by YouTube. First-party assessment. |
When search.list is the better choice
- Precisely filtered queries — publish windows, regions, languages, categories, safe-search levels, location radius. Nothing else in this comparison filters that finely.
- Up to 100
search.listcalls a day at no documented fee: for a dashboard, an alert, or a daily check, the default bucket is plenty and the official surface is the simplest compliant answer. - Workflows that must stay inside Google's official API surface for compliance reasons.
When the actor is the better choice
- Keyword sets larger than the bucket: market scans and rank tracking across dozens of terms exhaust 100 calls per day quickly, and each deep query spends pages from the same budget. The actor prices per delivered result instead — 1,000 results cost $0.20 regardless of how many queries or pages produced them.
- Results with audience counts attached in one pass: one actor row carries title, URL, audience display (lifetime views, or the concurrent watching count on live rows), duration, and channel, where the official route needs a second endpoint (
videos.batchGetStats) and the ID plumbing between the two calls. - Pipelines without a Google Cloud project: one HTTP call with an Apify token from n8n, Make, or a scheduled workflow, and typed, unbilled failure rows (a query that finds nothing is a free
success: falserecord, not an exception to catch). - Feeding the sibling actors: search collects video IDs for transcripts and comments at dataset scale.
The first-hand actor run, as evidence
On 2026-07-21 at 19:34 UTC we ran the YouTube Search Scraper (build 0.1.2) once with a single query, lofi hip hop, type: video, and maxResults: 200 (Apify run 60xNK4XVfr5o4Qgnf). The run finished SUCCEEDED in 23 seconds and delivered 200 billed success: truerows containing 199 unique videos for that one query — one video surfaced on two different result pages and was billed twice, disclosed in the artifact rather than rounded away. Every row carried a non-empty audience string: 188 lifetime view-count strings ("… views") and 12 live rows carrying the concurrent audience instead ("… watching"). The run's charge events correspond to $0.04 at the public list price of $0.20 per 1,000 (we ran our own actor, so this is a list-price value, not an observed customer charge).
Two limits on that reading. The 199 unique videos demonstrate delivery well beyond search.list's documented 50-per-call maximum for one query on one date — they are not a depth guarantee; YouTube sets search depth, and for most queries paging ends in the low hundreds. And that comparison is arithmetic against Google's documented limit, not a side-by-side run of the Data API, which we did not execute. The sanitized run output — result IDs, URLs, audience strings, durations, and channel IDs; titles and channel names removed — is published with full run metadata at /evidence/youtube-search-run-2026-07-21.json; any row can be checked against its public YouTube URL.
Methodology and sources
- No first-hand Data API run:search.list rows rest on Google's documentation — linked at every claim and re-checked on the last-verified date above. Note that the quota model changed in Google's June 2026 docs revision; this page cites the current model, not the older model.
- Actor rows: pricing, output fields, and failure behavior come from the actor's documentation, the canonical copy for this site — it currently includes corrections not yet synced to the Apify listing; the sync is queued. Delivery of 199 unique videos (200 billed rows) for one query, with an audience string on every row, is demonstrated by the first-hand run above; the remaining actor rows are documentation claims, reproducible with one run.
- Corrections:if Google's documented behavior changes or a row is wrong, use the support and corrections route; the page carries its last-verified date at the top.