Google does not sell a search volume API, so every “volume” number you can buy is an estimate — but most questions people ask of volume are answered better by data you can actually get. Before wiring an estimate vendor into a pipeline, it is worth being precise about which question you are asking, because comparison, timing, geography and surface questions have exact programmatic answers.
Why is there no official search volume API?
The two official sources both stop short. Keyword Planner shows volume as wide ranges, requires an active ads context, and buckets aggressively. Google Trends publishes a relative index — every series is scaled so its peak equals 100 — and offers no public API at all. Everything else on the market is modeled from clickstream panels or ad data, which is why two vendors quote volumes that disagree by 3x for the same term.
The practical consequence: any pipeline that treats a purchased volume number as ground truth inherits an estimate’s error bars without seeing them. The relative index, by contrast, is Google’s own measurement — it just answers a different question.
Which keyword questions have exact answers?
Four of the most common ones, and all four are programmatically available today:
“Which of these terms is bigger?” A comparison call returns up to five terms on one scale — the Google Keyword Trends API returns 15 fields per term including the full interest timeline, so “python vs javascript” is one request, not a spreadsheet of vendor estimates. A ready-made comparison setup runs it with one click.
“Is this growing or fading?” The interest timeline answers timing directly, with windows from the past hour to 2004-present. The window also sets the bucket size, so a 12-month window reads weekly cycles and a 5-year window reads seasonality.
“Where is the demand?” The regional breakdown ranks countries or subregions per term — which matters when the same word means different things in different markets, and the category filter pins the meaning you intend.
“What is rising right now?” Trending-now data is a separate surface: one row per breakout term with growth percent, measured per country over 4-hour to 7-day windows. A seven-day US window is a one-click starting point, and Google Trends Explore covers the compare side with the same field shape.
What does per-surface demand add?
The single most underused axis. Web, Image, News, Shopping and YouTube search are independent measurements of the same term, and they disagree in useful ways: a product term can be flat on web search while climbing on Shopping; a tutorial topic can be modest on web and large on YouTube search. If the budget decision is “make videos or write pages,” the surface split answers it and a blended volume number cannot.
When do you still need a volume estimate?
When the question is genuinely absolute: sizing a market in monthly searches for a board deck, or ranking ten thousand long-tail terms where relative comparison five-at-a-time does not scale. Then a vendor estimate is the only option — treat it as one, use a single vendor consistently so errors at least stay comparable, and calibrate it against the relative index on terms where you know the ordering.
The failure mode to avoid is the mixed pipeline: vendor volume for some terms, Trends index for others, both labeled “volume” in the same dashboard. The two numbers are not on the same scale, and every downstream average of them is meaningless.
What does a working setup look like?
Start from the question, not the vendor list. Comparison, timing, geography and surface questions go straight to Trends-backed APIs — each call returns typed rows you can store, join and re-run on a schedule, and the example tasks above are cloneable configurations that ran successfully before publication. Absolute-volume questions get a vendor estimate with its error bars acknowledged. Most keyword pipelines we see need the first kind far more often than they think, and the second kind far less.
Continue in the directory
Turn the guide into a real sample run.
Open the current AgentX contract, check pricing and fields, then validate a narrow output.