How do you get Google Trends data via API?

Most Google Trends write-ups, including the one that used to sit on this page, are built around interest_over_time: pick a keyword, pick a timeframe, get a 0-100 curve. That surface is closed to API clients now. We call it live and Google refuses it, so the endpoint returns DISABLED with the reason spelled out rather than an empty series. The same applies to related_queries and interest_by_region. Five of the eight actions on this engine still work; three do not, and a library that returns an empty array instead of an error will quietly feed your dashboard a flat line.

The second thing to know before building on trends data is that the 'traffic' number is never a search volume. It is a bucket floor. trending_now returns it as a string with a plus sign - '200+', '2000+', '5000+' - and realtime_trending returns it as a rounded integer that only ever takes values like 50000, 100000, 200000, 500000 and 2000000. Ranking on it works. Summing it does not.

Third, 'apple' is not one thing. Google resolves keywords to entities, and until you know which entity you are asking about, two trend queries that look identical can be about a fruit and a phone company.

The three dead endpoints fail loudly. interest_over_time, related_queries and interest_by_region return ok:false with code DISABLED, meta.scope 'ENDPOINT_DISABLED', in about 1.5 ms and with no charge, and the message names the reason: Google now blocks that data for API clients. You find out in your first test run rather than three weeks into a product.

The related-query data itself is not gone, it just moved. realtime_trending returns story clusters, and each story carries a related_queries array - the 'tim curry' cluster in our US run had 127 of them, from 'tim curry movies' through 'tim curry cause of death' to plain misspellings like 'tm curry'. That is the same long-tail keyword material the closed endpoint used to serve, delivered as part of a live story instead of as a keyword lookup. Stories also carry started (epoch) with started_date, ended, active and article_count.

trending_now and realtime_trending look similar and are not. trending_now is the news feed: each row carries three linked articles with title, URL, source and image, a bucketed traffic string, and an RFC-822 pub_date. realtime_trending is the cluster feed: no article bodies, only article_count (44, 19, 51 on our first three stories), but the full related-query list and numeric category_ids. Use trending_now to show a reader what happened; use realtime_trending to mine what people typed.

One honest wart in trending_now: the link field is the same generic Trends RSS URL on every row, not a per-trend permalink. Do not store it as a deep link. The per-row articles carry the real destination URLs.

Timestamps come back in Google's own offset, not yours and not the region's. A German trending_now row was stamped 'Wed, 26 Aug 2026 14:30:00 -0700' - US Pacific, for a DE query. Parse the offset rather than assuming local time, or your 'trending in the last hour' window will be eight hours off.

suggest solves the entity problem in one call. Asking for 'apple' returns five candidates with a Knowledge Graph mid and a human-readable type: /m/04st9hr Topic, /m/014j1m Fruit, /m/0k8z Technology company, and so on. categories returns the full taxonomy - 1,426 entries - and is searchable: querying 'finance' returns id 7 Finance at depth 1 under All categories, id 1138 Business Finance at depth 2 under Business & Industrial, and id 1161 Public Finance at depth 3 under Government, each with parent_id and parent_name so you can walk the tree.

geo changes the feed as you would expect: US returned 'boy abandoned hiking mt fuji' and 'carabao cup draw'; DE returned 'philipp tuermer' with German-language articles from German publishers. trending_now answered in about 780 ms, realtime_trending in about 590 ms.