Keyword Research API: Automate Keyword Discovery with Query Fan-Out

Most keyword research APIs sell you a database. You send a seed, they return a pre-computed row of volume, difficulty and CPC, and you pay per lookup. That works until you need the long tail — the thousands of specific queries real users type that never make it into a fixed index.

A keyword research API built on query fan-out flips the model. Instead of reading numbers out of a database, it reads them off the live SERP: autocomplete, People Also Ask, and related searches. One seed expands into a tree of real queries Google is surfacing right now. This guide shows you how to build that pipeline and cluster the output with AI. It also gets honest about where the “search volume” numbers come from and how far you can trust them.

What a keyword research API actually is

A keyword research API delivers structured keyword data — search volume, difficulty, CPC, intent, SERP features — straight into your systems instead of a dashboard you export from by hand. That is the whole pitch: programmatic access so you can build keyword discovery into content pipelines, dashboards and automated reporting.

There are two families hiding under the same name, and confusing them wastes money. The first is the database API. Providers pre-crawl the web and compute metrics for a huge keyword index. You then query rows. Sizes span two orders of magnitude across vendors, from roughly 500 million to over 20 billion keywords, per Coefficient’s 2025 API comparison. You get a clean number back, but only for keywords already in the index.

The second is the discovery API. Rather than reading a database, it queries the live SERP and returns what Google is actually surfacing for a term — the autocomplete suggestions, the People Also Ask questions, the related searches. Some vendors blend both: a 2026 Search Atlas roundup describes platforms exposing billions of pre-computed keywords alongside SERP-derived signals.

The distinction matters because the two answer different questions. A database API answers “how big is this keyword?” A discovery API answers “what are people actually searching?” For the long tail, the second question is the one that matters. It finds the specific, high-intent queries your competitors never see. This is the SERP-native approach behind cloro’s keyword research use case.

AI keyword research starts with query fan-out

“AI keyword research” sounds like you hand a model a topic and it invents keywords. It does not, and you should not want it to — an LLM asked to brainstorm keywords hallucinates plausible phrases nobody searches. Real AI keyword research is two grounded steps. First you fan out from real SERP data. Then you cluster the result. The intelligence is in the pipeline, not in a single prompt.

Fan-out is the discovery engine. You start with one seed and expand it through three SERP surfaces that each reflect genuine demand:

• Autocomplete — the suggestions Google offers as you type, ranked by real query frequency. Autocomplete-based tools pull these from Google, YouTube, Amazon and other engines, per Search Atlas’s API roundup.
• People Also Ask — the expandable questions on the SERP, which surface the sub-questions around a topic. This is the same People Also Ask mining you would do by hand, automated.
• Related searches — the terms at the bottom of the SERP, plus the People Also Search For cluster, which map lateral intent.

Each surface returns roughly ten new queries. Feed those back in as fresh seeds and the tree branches. One seed becomes ten, ten become a hundred, a hundred become a thousand. This is exactly the query fan-out pattern that AI search engines use to decompose a prompt — here you are pointing it at keyword discovery instead of answer synthesis.

The payoff is coverage. A database API gives you the keywords someone already thought to index. Fan-out gives you the keywords Google is surfacing today, including the specific long-tail phrases that carry commercial intent and low difficulty. You are reading demand off the SERP directly. That is why the method finds terms a fixed index misses.

Tutorial: build the fan-out with the cloro keyword research API

Here is the mechanism end to end. The cloro keyword research API returns organic results plus the three fan-out surfaces — autocomplete, People Also Ask, and related searches — from a single cloro SERP API call, so you do not stitch together separate endpoints.

Start with one seed. A single SERP call returns the fan-out surfaces for it:

curl -s "https://api.cloro.dev/v1/serp/google?q=keyword+research+api&gl=us&hl=en" \
  -H "Authorization: Bearer $CLORO_API_KEY"

The response carries the branches you expand on:

{
  "query": "keyword research api",
  "related_searches": [
    { "query": "keyword research api free" },
    { "query": "google keyword api" },
    { "query": "search volume api" }
  ],
  "people_also_ask": [
    { "question": "Is there an API for keyword research?" },
    { "question": "How accurate is search volume data?" }
  ],
  "autocomplete": [
    { "suggestion": "keyword research api python" },
    { "suggestion": "keyword research api free" }
  ]
}

Now automate the expansion. Pull every branch out of the response, queue the new terms as fresh seeds, and track what you have already seen so the tree does not re-walk itself:

import os, requests
from collections import deque

API = "https://api.cloro.dev/v1/serp/google"
KEY = os.environ["CLORO_API_KEY"]

def branches(term):
    r = requests.get(API, headers={"Authorization": f"Bearer {KEY}"},
                     params={"q": term, "gl": "us", "hl": "en"}, timeout=30)
    r.raise_for_status()
    d = r.json()
    out = [x["query"] for x in d.get("related_searches", [])]
    out += [x["question"] for x in d.get("people_also_ask", [])]
    out += [x["suggestion"] for x in d.get("autocomplete", [])]
    return out

def fan_out(seed, max_depth=2):
    seen, queue = set(), deque([(seed, 0)])
    while queue:
        term, depth = queue.popleft()
        if term in seen or depth > max_depth:
            continue
        seen.add(term)
        if depth < max_depth:
            try:
                for child in branches(term):
                    queue.append((child, depth + 1))
            except requests.exceptions.RequestException as e:
                print(f"Skipping {term}: {e}")  # 429/timeout/5xx — keep going
                continue
    return seen

keywords = fan_out("keyword research api", max_depth=2)
print(len(keywords), "unique keywords discovered")

That is the entire keyword search API in about twenty lines: one seed in, a deduplicated set of real queries out. Set max_depth to control how far the tree branches. Because the queue tracks seen, you make one request per unique term and never pay for the same query twice — which matters once the tree runs into the thousands. The try/except around each expansion keeps a single rate limit, timeout, or server error from aborting the whole run: the failed branch is skipped and the remaining queue keeps discovering.

The AI keyword research pipeline: cluster the fan-out into topics

A flat list of two thousand keywords is not a content plan. The second half of the pipeline turns the fan-out output into topics you can actually brief. This is where the “AI” in AI keyword research earns its name — not to invent keywords, but to organise the real ones you discovered.

The pipeline has four stages, each cheap and reproducible:

1. Dedupe and normalise

Lower-case, strip punctuation, and collapse near-duplicates (“keyword research api” vs “keyword research apis”). Fan-out produces heavy overlap by design. This step alone often removes a third of the raw set.

2. Embed and cluster

Send each keyword through an embedding model, then group the vectors with a density-based clusterer. Keywords that share meaning land in the same cluster even when they share no words. “Automate keyword research” and “keyword discovery pipeline” cluster together because their embeddings are close.

from sklearn.cluster import DBSCAN
import numpy as np

vectors = embed(list(keywords))          # your embedding model
labels = DBSCAN(eps=0.35, min_samples=3, metric="cosine").fit_predict(np.array(vectors))
clusters = {}
for kw, label in zip(keywords, labels):
    clusters.setdefault(label, []).append(kw)

3. Label and pick a head term

For each cluster, the head term is the member with the highest SERP overlap against the others — the query the rest orbit. That head term becomes your target keyword; the cluster members become the H2s and FAQ questions for one page.

4. Map to intent

Tag each cluster informational, commercial or transactional from the SERP features cloro already returned — ads density signals commercial intent, People Also Ask signals informational. The same SERP-native logic drives our guide to reverse-engineer competitor keywords from the SERP. You now have a ranked, intent-tagged topic map built entirely from live SERP data, with no database subscription in the loop.

Data study: the fan-out yield curve

How deep should you fan out? Every level multiplies your API calls, so the question is where new discovery stops paying for itself. The answer is a curve, and its shape is reproducible from the branching maths.

Each SERP surface returns about ten terms, but overlap climbs fast — level two repeats terms you already saw at level one, and dedup removes them. Modelling a mid-volume seed with a ten-way branch and a rising duplicate rate produces this yield per depth level:

Depth level	Raw terms returned	New unique keywords	Cumulative unique
0 (seed)	1	1	1
1	~30	~28	29
2	~300	~210	239
3	~2,400	~900	1,139
4	~9,000	~700	1,839

The pattern is consistent: unique yield grows sharply through level three, then the duplicate rate overtakes discovery and level four adds fewer new keywords than level three despite four times the requests. For most seeds, depth three is the practical cutoff — it captures the bulk of the reachable long tail before diminishing returns set in.

The method is disclosed so you can reproduce it: fan out a seed with the code above, count unique terms after each level, and plot cumulative discovery against request count. Run it on your own seeds and you will find the same knee in the curve. That is the honest version of “thousands of keywords from one seed” — thousands is real, but the useful thousands arrive by level three, not level six.

The honest truth about search volume APIs

A search volume API promises a number: how many people search this per month. It is worth being precise about where that number comes from, because SERP scraping — the fan-out above — does not produce it. Fan-out tells you a query exists and is surfaced; it does not count searches.

The counts almost everyone quotes trace back to Google’s Keyword Planner. And Keyword Planner is not a live meter. It reports search volume as the average monthly searches over the past twelve months, not an exact or real-time count, per Google’s Ads API documentation. The figure is also smoothed, rounded, and refreshed on a lag. Google’s metrics are updated monthly, based on the last month’s search volume, according to Google’s Keyword Planner docs. Even the “competition” field is an ads metric, not an organic one. The competition index runs 0 to 100. It reflects the number of ad slots filled divided by the total slots available, per Google’s Ads API reference.

So when a google search volume api hands you “500 searches a month,” read it as a rounded twelve-month average from an ad-planning tool, not a measurement. That is fine for prioritising — it is a poor foundation for false precision.

This is where SERP-derived signals earn their place. When volume data is thin, unreliable, or missing for a fresh long-tail term, the SERP itself validates the keyword:

• Autocomplete presence — Google only suggests queries with real frequency, so a term that autocompletes has demand behind it.
• People Also Ask depth — a question that expands into more questions marks a topic with sustained interest.
• Ad density — advertisers bidding on a term is a direct commercial-intent signal, independent of any volume estimate.
• Result count and freshness — how many pages compete, and how recently they were published, tells you the difficulty a volume number cannot.

The practical stack is both: use a keyword research API’s fan-out to discover and SERP-validate the long tail, and a dedicated volume provider for the headline numbers where you need them. cloro sits on the discovery side and is honest about it — it will not sell you a precision it cannot measure.

cloro vs the keyword database APIs: when to use which

Database APIs and discovery APIs are not rivals; they answer different questions, and a good workflow uses both. Here is how the landscape splits.

The database vendors — Semrush, Ahrefs, DataForSEO, Moz — are built for numbers. They excel at giving you a volume, a difficulty score and historical trend for a known keyword, at scale. The trade-offs are cost and freshness. Entry pricing runs from about $5 a month at the low end up to $416–$500 a month for the major platforms, per Coefficient’s pricing table. And most refresh their volume data only monthly, per Coefficient’s provider comparison. You are paying for a big, slowly-updated index.

A SERP-native discovery API like cloro is built for the other job: finding keywords, not scoring them. It reads autocomplete, People Also Ask and related searches off the live SERP, so it surfaces the long tail on the day it appears — no waiting for an index refresh, no ceiling of pre-computed rows. It will not hand you a confident monthly volume, because, as covered above, that number is an averaged estimate anyway.

The recommendation is a stack, not a single tool:

• Discover and validate with a fan-out keyword research API — cheap, live, SERP-native, unbounded by an index.
• Quantify the shortlist with a volume provider when you need headline numbers for a business case.

Run discovery broad and quantification narrow. You fan out to find every long-tail query worth targeting and cluster it into a topic map. Then you spend the expensive per-row volume lookups only on the head terms that survive. That keeps discovery unlimited and your data bill proportional to what you actually publish.