100 free credits. No credit card required.Start building
Logo
Back to blog

Google Trends API: Empty Searches Cost 0 Credits

·11 min read

Empty Google Trends API searches now return 404 with 0 credits charged. Live production curls cover Trends empties, News ranks, and app filter refusals.

Google Trends API: Empty Searches Cost 0 Credits

An empty Google Trends API explore now returns 404 with credits_used: 0 — not a paid empty series. That is the headline change in SocialCrawl's September 2026 honesty wave: empty Trends interest is free, unsupported filters refuse with a free 400 that names the fix, Google News rows ship contiguous ranks at the exact depth you asked for, and Trends marks the still-counting period as partial.

Every curl and credit receipt below was captured on production on 2026-09-08 — all nine behaviours, including the app-marketplace filter refusals. Auth is x-api-key on /v1/google_trends/*, /v1/google_news/*, /v1/app_store/*, and /v1/google_play/*.

The Google Trends UI is free to explore. Google's first-party Trends API is a gated alpha. Production callers still need empty-interest and filter semantics today — that is what this post measures. Vendor pricing lives in the sibling roundup, Best Google Trends APIs 2026; this post is the billing ledger.

An empty line-chart frame beside a blank clay-amber token and receipt, the unpaid empty result a Google Trends API search returns when interest is too thin.

If Google Trends holds too little search volume to build a series, SocialCrawl returns RESOURCE_NOT_FOUND and does not charge. Official Trends semantics already treat very low volume as 0, not as measurable interest (Google Trends FAQ). Values are a 0–100 index normalized to the geography and time window, not absolute search counts. Charting a paid row of zeros used to look like a successful answer. A free 404 is the honest one: there was no series to bill for.

The pre-change upgrade note (2026-09-07) recorded empty explores as 200 + 5 credits for an empty series. That figure was not re-measured as old behaviour in this harvest — only the after column below is live evidence from production.

bash
curl "https://www.socialcrawl.dev/v1/google_trends/explore?keywords=zzqqxjw" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"
json
{
  "success": false,
  "error": {
    "type": "RESOURCE_NOT_FOUND",
    "message": "No search-interest data were returned for this keyword. The location and timeframe were accepted; Google Trends simply holds too little search volume for this keyword in that combination to build a result. Try a wider `timeframe`, a broader keyword, or the keyword in the local language of the location you requested. You were not charged for this request.",
    "status": 404
  },
  "credits_used": 0
}

Read the receipt carefully. The location and timeframe were accepted; the failure is “no measurable interest,” not a bad param. The message says you were not charged, and credits_used: 0 matches. zzqqxjw is a nonsense token chosen so the empty path is deterministic. A real low-volume niche term in a narrow location/timeframe can also 404 — that is a fact about interest, not a transport failure. The same empty-interest rule applies on /v1/google_trends/rising?keyword=zzqqxjw (also 404, credits_used: 0 on 2026-09-08).

When interest does exist, every time-series point carries a boolean partial. On a live taylor swift explore the same day (53 weekly points, average 25, credits_used: 5), only the still-counting final bucket was partial: true:

datevaluepartial
2026-08-2316false
2026-08-3014false
2026-09-0616true

Without the flag, that last bucket looks like a real dip or spike. Drop partial: true points before you chart. The flag flips when Google closes the period — do not treat any single date as eternally partial. Full Trends contract: /docs/google_trends. Credit rules for empty upstream bodies: /docs/credits. Error taxonomy for 404 vs 400: /docs/errors.

A neat cascade of blank paper cards with one clay-amber lead tab, the contiguous ranked list a Google News API depth request returns.

How does Google News API ranking work after the update?

The same honesty wave hit the Google News API. Request a depth, get that many rows, each with a contiguous 1-based rank. No gaps, no repeats, no silent over-delivery. If you paginate or pin “top N” headlines in a product, missing ranks and extra rows are the kind of bug that only shows up after someone screenshots your UI.

The upgrade note described earlier pages that could return 29 articles for depth=20, or leave position missing on many rows. Again: that is the pre-change note, not a this-run measurement. Production on 2026-09-08 looked like this:

bash
curl "https://www.socialcrawl.dev/v1/google_news/search?keyword=openai&depth=20" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"
checkresult
data.total20
item count20
ranks1, 2, 3, …, 20
contiguous / no dupsyes
credits_used1

Sample rows from that response:

ranksourcetitle
1BBCOpenAI chief scientist warns no-one is prepared for consequences of AI
2bloomberg.comOpenAI Top Scientist Urges 'Extreme Caution' With Pace of AI
3Yahoo TechOpenAI's chief scientist says AI labs may need to slow down…
20New York PostOpenAI hires Chuck Schumer's daughter…

rank is list position for the page SocialCrawl returned for this request — not an external Google News “score.” Google News itself is a consumer product without a public Search developer contract (Google News Help); a third-party Google News data API fills that gap. Endpoint reference: /docs/google_news. For vendor pricing on news APIs, see Best Google News APIs 2026 — that sibling owns the comparison table; this section only proves rank and depth honesty on SocialCrawl's own endpoint.

What do unsupported filters return on app review APIs?

Filter honesty is the other half of the wave. If a parameter looks supported but the store cannot apply it upstream, SocialCrawl refuses with a free 400 that names the param and points at the fix — instead of returning an unfiltered feed and charging you as if the filter worked. That failure mode is worse than a hard error: your code thinks it got one-star reviews, your dashboard plots them, and the bill still moved.

Apple's public review feed cannot be filtered by star rating upstream. Asking for rating=1 on App Store reviews used to (per the upgrade note) return 200 + 5 credits of unfiltered data. Live on 2026-09-08:

bash
curl "https://www.socialcrawl.dev/v1/app_store/app-reviews?app_id=310633997&rating=1" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"
json
{
  "success": false,
  "error": {
    "type": "INVALID_REQUEST",
    "message": "`rating` is not supported on app_store/app-reviews: Apple's review feed cannot be filtered by star rating upstream, and forwarding it would return the unfiltered feed under a filtered request. Use /v1/google_play/app-reviews for a real star filter, or request a larger `depth` here and filter on each review's `review.rating.value`.",
    "status": 400
  },
  "credits_used": 0
}

Google Play does support a star filter on /v1/google_play/app-reviews, but out-of-range values are also free 400s. rating=7 on com.spotify.music returned INVALID_REQUEST with `rating` must be a whole number from 1 to 5. Received "7". and credits_used: 0. Official first-party review APIs (Play Developer, App Store Connect) only cover apps you own. Competitive review mining is why third-party App Store reviews API and Google Play reviews API surfaces exist — and why silent filter drops are expensive. Pricing roundup for that category: Best App Review APIs 2026.

The rest of the live marketplace behaviours from the same harvest:

BehaviourAfter (measured 2026-09-08)Before (upgrade note only)
Trends category=games400 + 0cr, names numeric category200 + 5cr all-categories
Play rating=7400 + 0cr (must be 1–5)200 + 5cr treated as 5
Play /locations211 storefronts / ~28 KB / 1cr~269k rows / ~46 MB
App Store country=uk400 + 0cr → use GBSilent wrong-market suggestions
Listings filters=not-json400 + 0cr + JSON example200 + 10cr unfiltered

Client validation runs before billing (/docs/errors): a free 400 that tells you what to fix is cheaper than a successful-looking unfiltered page. The Trends category=games row is the same pattern on the Google Trends API itself — send a numeric category code, or omit it; do not pay for an all-categories series you did not ask for.

Minimal path: get an API key, put it in the environment, replay a call that costs nothing while you wire auth. This is the Google Trends API Python path without a scraper's rate-limit roulette.

  1. Create a key and keep the free credits for smoke tests.
  2. Replay the empty explore (0 credits) or a tiny News depth call (1 credit) before you spend on a live Trends series (5 credits).
  3. Then open the Explorer and the platform docs: /docs/google_trends, /docs/google_news, /docs/credits, /docs/errors.
python
import os
import requests

resp = requests.get(
    "https://www.socialcrawl.dev/v1/google_trends/explore",
    params={"keywords": "zzqqxjw"},
    headers={"x-api-key": os.environ["SOCIALCRAWL_API_KEY"]},
    timeout=30,
)
print(resp.status_code, resp.json().get("credits_used"))
# 404 0

Unofficial Google Trends Python clients such as pytrends (archived read-only in April 2025) are a different category: no credit receipt, no documented empty-interest 404, no partial flag on the open period. If you need a billed Google Trends API with those receipts, start from the empty explore above and only then pay for a real keyword.

Reproducibility from this harvest: empty/filter validation = 0 credits; live Trends explore = 5; News depth=20 = 1; Play /locations = 1. Quote per-call credits_used — shared-key balance deltas can include concurrent work on the same key.

Frequently asked questions

No. On production (2026-09-08), GET /v1/google_trends/explore?keywords=zzqqxjw returned HTTP 404 RESOURCE_NOT_FOUND with credits_used: 0, and the error message states you were not charged. The same empty path on /v1/google_trends/rising was also free.

The Trends UI is public. Google announced a first-party Trends API alpha in July 2025, but it remains gated. Most production callers still use third-party Trends APIs, which is why empty-interest and filter semantics matter on the wire today.

Set SOCIALCRAWL_API_KEY, then requests.get against /v1/google_trends/explore as in the Python section above. Replay the empty keyword first (free smoke), then call a real term when you are ready to spend 5 credits.

It marks a bucket Google is still accumulating — normally the latest period. On the 2026-09-08 taylor swift capture, only 2026-09-06 was partial: true. Drop those points before charting; the flag flips when the period closes, so do not hard-code any date as forever partial.

Do unsupported filters on Google Play / App Store review APIs still charge?

No. Apple rating on /v1/app_store/app-reviews, Play rating=7, unknown App Store country=uk, and malformed listings filters all returned free 400s with credits_used: 0 on the 2026-09-08 production smoke. The response names the bad param and, where useful, the endpoint that actually supports the filter.

For the Trends contract, credit refunds, and error taxonomy: /docs/google_trends, /docs/credits, /docs/errors. Sibling pricing deep-dives if you need vendor tables: Best Google Trends APIs 2026, Best Google News APIs 2026, Best App Review APIs 2026.

Topics
#google-trends-api#google-news-api#google-trends-api-python#google-play-reviews-api#app-store-reviews-api#google-play-api#app-store-api#google-trends-python#pytrends

Related posts

🤖 AI agent or LLM? Read this page as markdown