q=qequals

Google Suggest API: the raw endpoint and what it does not return

Pull real Google suggest strings with one GET to the unofficial endpoint: params, JSON vs XML shapes, limits, and why it gives you discovery without volume.

Qqequals·Sep 24, 2026·6 min read

Paste this into a browser and you get real Google suggestions back as data:

https://suggestqueries.google.com/complete/search?client=firefox&q=apple

No key. No login. One HTTP GET. The response is a JSON array:

["apple", ["apple store", "apple watch", "apple id", "apple music", "apple stock"]]

That is the raw Google Suggest endpoint, the unofficial, publicly reachable URL behind autocomplete. It returns what people actually type, and a suggestion carries demand for a different reason than a volume estimate does.

The Endpoint: One URL, GET, No Auth

Base URL:

https://suggestqueries.google.com/complete/search

Append everything as ordinary query parameters:

https://suggestqueries.google.com/complete/search?client=chrome&q=coffee

GET only. No authentication. That open access is why builders reach for it, and why it can change or stop working without warning. Google does not document it or support it; developers mapped it by observation. GrowthRocks' glossary entry says it plainly: as an unofficial call, Google can change or block access at any time, with no support or stability guarantees. FullStackOptimization's fuller unofficial specification carries the same disclaimer, that behavior may change without notice.

Params That Control What Comes Back

ParamWhat it does
qThe partial term you want completions for. URL-encode spaces and special characters. q=coffee
clientMimics a calling context and decides the response shape. chrome and firefox return JSON, structured slightly differently. toolbar returns XML
outputDefines the response format alongside client, such as JSON or toolbar XML
hlHost language, for example hl=en
glCountry for localization, a two-letter code, for example gl=us
dsDomain-specific suggestions. ds=yt returns YouTube suggestions. Omit it, or use ds=web, for general web search
jsonp / callbackWraps the JSON in a callback function, jsonp=myCallback returning myCallback([...]). A leftover from older cross-domain JavaScript

Two localization notes belong together. Combine hl and gl when you want suggestions for a language and a market, and remember that Google may still layer other signals, such as the requesting IP, on top of them. Use ds=yt only when you want YouTube-flavored completions; the default web behavior is what keyword discovery usually wants.

JSON vs XML: Chrome and Firefox Against Toolbar

With client=chrome or client=firefox you get a JSON array. The first element is the original query string. The second is the array of suggestion strings. Later items carry metadata such as relevance ranking.

The coffee example, JSON shape:

[
  "coffee",
  [
    "coffee beans",
    "coffee near me",
    "coffee table"
  ],
  [],
  {
    "google:suggesttype": ["QUERY", "QUERY", "QUERY"],
    "google:suggestrelevance": [1250, 600, 560],
    "google:verbatimrelevance": 1300
  }
]

With client=toolbar you get XML, one block per suggestion:

<toplevel>
  <CompleteSuggestion>
    <suggestion data="coffee beans"/>
  </CompleteSuggestion>
  <CompleteSuggestion>
    <suggestion data="coffee near me"/>
  </CompleteSuggestion>
</toplevel>

Try both shapes once before you build:

  • JSON: https://suggestqueries.google.com/complete/search?client=chrome&hl=en&q=coffee
  • XML: https://suggestqueries.google.com/complete/search?client=toolbar&hl=en&q=coffee

The client=firefox form is popular because it has historically returned a clean array with no extra fuss, which is why GrowthRocks documents client=firefox&q=your_query as its first example.

Where Is the Documentation for This?

That is the question builders actually ask. A Stack Overflow thread titled "Where is documentation for Google Suggest API" has sat open since 2011, asked because there is none from Google.

The companion framing comes from a guide to free keyword sources: every keyword tool is built on top of data you can pull yourself. That is the job this endpoint does. It hands you callable strings for fan-out discovery without renting a suite seat: seed in, real completions out. People searching for it call it a suggest API, a suggest scraper, a suggest keyword tool; the definitional question of what Google Suggest is travels alongside.

What It Does Not Return: No Volume, No CPC, No Competition

The raw endpoint returns suggestions and relevance rankings. It returns zero search volume, zero cost per click, zero competition metrics.

That split is the observed-versus-modeled distinction to hold in your head. Suggest strings are observed: live completions Google is serving right now. Volume is modeled: it comes from historical databases, typically built on Google Ads data, bucketed and averaged over months.

So run it as a two-step funnel. Fan out first: feed a seed term to the endpoint and expand into the real long-tail variations. Then validate narrow: pass only the surviving head terms through a volume provider to overlay metrics and set priority. Discovery finds the phrasing; volume decides what the phrasing is worth. Do not expect the first step to do the second step's job.

This is the search-box suggest inside Google Search. It is not the address or Places autocomplete, which is a separate, paid, documented API.

Limits: How the Endpoint Pushes Back

There is no rate-limit document. In practice the unofficial rules are these.

  • Excessive querying gets blocked with HTTP 429 or 503.
  • Rapid or large-scale requests can trigger IP blocking or CAPTCHA challenges.
  • Queries may be logged by Google.
  • Responses can come back non-200, empty, truncated, or in a suddenly changed structure.

Stay small by construction: always use https://, space requests out rather than bursting, back off exponentially on 429 or 503, handle empty and truncated responses instead of assuming a clean array, and expect the parameters or the response shape to change without announcement.

That is a guardrail, and it is all this page offers. Proxy rotation, CAPTCHA solving and fingerprint spoofing are how people turn a free endpoint into a blocked one. If you need fan-out at any real volume, keep the loop tight (pull, remove what you have already seen, pull the next layer) or hand the fetching to a managed API that absorbs the fragility for you. The pattern-finding, spotting a shape like "best {tool} for {industry}" across the completions, is where suggest pays. Hammering the endpoint is not.

When Keyless Gets Fragile

The unofficial endpoint is free and immediate, and that is also its risk: no quota clarity, no history, and nobody to call when the shape shifts under a running job.

The managed alternatives sell exactly that gap, a documented quota and a stored history in front of the same source. qequals is one of them, wrapping suggest with weekly snapshots kept so a completion you saw in March is still there to compare against. What no wrapper adds is volume. The raw endpoint never had it, and a managed one cannot invent it. Discovery is what you are buying either way; validation is the second purchase.