DEV Community: Reliable Apps by Vasilis Linakis

Google Trends API alternatives in 2026: getting Trends data as JSON (and what to do about 429s)

Reliable Apps by Vasilis Linakis — Sat, 14 Nov 2026 21:16:45 +0000

You want Google Trends numbers in a script, not in a browser tab. Maybe it's a weekly check on demand for a product category, maybe it's comparing five brand names before a campaign. The first attempt usually ends with HTTP 429 Too Many Requests.

This post covers what your options actually are in late 2026, where each one falls short, and a working Python example. One of the options is a tool we built, so read the "when not to use it" section too.

The landscape, checked on 2026-10-31

1. The official Google Trends API (alpha)

Google announced a Trends API on 24 July 2025 (Search Central blog). As of 31 October 2026 its developer page still describes it as an alpha that is "accepting applications for alpha testers", with access limited to a selected group. Google says it prioritises applicants who know what they want to build, can start soon and will give feedback.

What it offers is interesting: a rolling five-year window, daily to yearly aggregation, region and sub-region breakdowns, and values that are not rescaled 0-100 per request, so you can compare more than five terms consistently.

Use it if you get in. It is the first-party source. If you need something today and you are not in the alpha, read on.

2. pytrends

pytrends was the default unofficial Python library for years. The repository was archived by its owner on 17 April 2025 and is now read-only. It still installs, and forks exist, but nobody is fixing the upstream package when Google changes the endpoints it relies on. If it works for you today, pin the version and expect to own the maintenance.

3. Hosted scraping services

Several services return Trends data over an HTTP API. Two families:

SERP API providers, for example SerpApi's Google Trends API (interest over time, by region, related queries and topics).
Apify Store Actors. A Store search for "google trends" returns several. On 2026-10-26, the two most-used ones listed a lower price per result than ours on their Store pages, and one also covers daily trending searches. Check each page; prices change.

Ours is Google Trends API & Scraper. It is built for a narrower job, described next.

What our Actor does, and does not do

One result is one search term, or one comparison group of up to 5 terms, with every section you asked for in a single record: interest over time, interest by region, related queries, and optionally related topics.

On rate limits, to be precise: it does not make 429s go away. Google limits how often Trends can be queried, and it limits shared cloud IPs most. When the Actor gets a 429, it waits as long as Google's Retry-After header asks, or backs off exponentially, up to 3 tries per term. If a term still fails, you get an error record with error_code: "rate_limited" and the HTTP status, and the run moves on. If two terms in a row are rate-limited, it stops asking and marks the rest as skipped. It does not rotate proxies or IPs.

Error records are free. You pay $5 per 1,000 results ($0.005 per result record) on every Apify plan, plus a $0.00005 start fee per run. error and summary records are not charged, and platform usage is included.

Hands-on: compare terms, export to CSV, pull related queries

You need an Apify account and an API token (Settings → API & Integrations). The code uses apify-client 3.x, where runs come back as objects (run.default_dataset_id); in older 1.x/2.x versions they were dicts (run["defaultDatasetId"]).

pip install "apify-client>=3"
export APIFY_TOKEN=your_token_here

Step 1: run a comparison

import os
from decimal import Decimal

from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

run_input = {
    "searchTerms": ["python", "javascript", "rust"],
    "compareMode": True,          # one record, values scaled together
    "timeRange": "today 12-m",
    "geo": "US",
    "interestOverTime": True,
    "interestByRegion": True,
    "relatedQueries": True,
}

run = client.actor("reliable-apps/google-trends-reliable").call(
    run_input=run_input,
    max_total_charge_usd=Decimal("0.10"),  # hard cap for this run
)
if run is None:
    raise SystemExit("Run did not finish")

items = list(client.dataset(run.default_dataset_id).iterate_items())
results = [i for i in items if i["type"] == "result"]
errors = [i for i in items if i["type"] == "error"]

for err in errors:
    print(f"{err['searchTerm']}: {err['error_code']} ({err.get('http_status')})")

Every item has a type: result, error or summary. Always check errors before you trust a chart. A missing term is a visible record, not a silent gap.

Step 2: interest over time to CSV

In a comparison, each point holds one value per term under values, keyed by the term. That maps cleanly to a long-format CSV, which pandas, Sheets and most BI tools read without fuss.

import csv

with open("interest_over_time.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerow(["group", "time", "term", "value", "is_partial"])
    for rec in results:
        iot = rec.get("interestOverTime") or {}
        for point in iot.get("points", []):
            for term, value in point["values"].items():
                writer.writerow([
                    rec["searchTerm"],
                    point["time"],
                    term,
                    value,          # None means Google has no data for that point
                    point["isPartial"],
                ])

Two details worth knowing. The last point can have isPartial: true while the period is still running, so drop it before computing week-on-week changes. And values are Google's relative 0-100 index, not search counts.

Step 3: related queries

relatedQueries is keyed by term, each with a top and a rising list.

for rec in results:
    for term, lists in (rec.get("relatedQueries") or {}).items():
        print(f"\nRising for {term!r}:")
        for q in lists.get("rising", [])[:5]:
            print(f"  {q['query']:<40} {q['formattedValue']}")
    for warning in rec.get("warnings", []):
        print("warning:", warning)

If Google does not return a section, the record says so in warnings instead of handing you an empty list that looks like real data.

Step 4: schedule it

For a weekly time series, create a Schedule in the Apify Console with the same input, and read the latest run's dataset from your pipeline. Keep batches small: a handful of terms per run is far less likely to hit rate limits than a few hundred.

When not to use it

You need hundreds or thousands of terms per day. The Actor sends at most one request per second and stops on repeated 429s. It is built for tracking a known list, not bulk research. A provider that sells volume will suit you better.
You are in the official alpha. Use Google's API. It is first-party and avoids the 0-100 rescaling problem.
You need daily trending searches ("Trending Now"). We do not collect them.
You want the cheapest price per result. On 2026-10-26 other Store Actors listed lower prices. Ours trades price for one-record-per-term output and explicit, free error records.
You need absolute search volume. Trends data is relative. No Trends tool gives you volume, whatever the label says.

Responsible use

The Actor checks Google's robots.txt on every run and only calls the Trends data paths it allows (/trends/api/...), never the /explore pages.
No proxy rotation, no headless browser, no faked fingerprints. A captcha, a consent wall, a 401 or a 403 stops that term with no retry, and the run skips the rest.
Trends data is aggregated and anonymised. It contains no personal data.
You are still responsible for complying with Google's terms and the law where you work. Treat Trends as a sampled, relative signal.

How to get Greenhouse, Lever and Ashby job postings as JSON (and track new roles weekly)

Reliable Apps by Vasilis Linakis — Thu, 12 Nov 2026 16:13:39 +0000

When a competitor opens three sales roles in Berlin, that tells you something before any press release does. The same goes for a prospect that starts hiring data engineers, or a portfolio company that quietly stops hiring.

Most of that signal sits on careers pages hosted by three applicant tracking systems: Greenhouse, Lever and Ashby. The good news is that all three publish their job boards through public, documented endpoints. No scraping of HTML is needed.

This post shows the raw endpoints, where they get awkward at scale, and a short Python script that tracks new roles across a list of companies every week. One option in it is a tool we built; you can do all of this without it.

The endpoints are public and documented

Employers publish job boards so their openings can be displayed on their own sites. The providers document the read endpoints, and none of them need an API key to list jobs (checked 2026-10-31):

Provider	List endpoint	Docs
Greenhouse	`GET https://boards-api.greenhouse.io/v1/boards/{board_token}/jobs`	Job Board API
Lever	`GET https://api.lever.co/v0/postings/{site}?mode=json` (EU: `api.eu.lever.co`)	Postings API
Ashby	`GET https://api.ashbyhq.com/posting-api/job-board/{board_name}`	Public job posting API

The token is the last part of the board URL: boards.greenhouse.io/airbnb → airbnb, jobs.lever.co/palantir → palantir, jobs.ashbyhq.com/openai → openai.

Raw example: Greenhouse

Standard library only:

import json
import urllib.request

BOARD = "airbnb"
url = f"https://boards-api.greenhouse.io/v1/boards/{BOARD}/jobs"

req = urllib.request.Request(url, headers={"User-Agent": "job-tracker/0.1 (you@example.com)"})
with urllib.request.urlopen(req, timeout=30) as resp:
    data = json.load(resp)

print(data["meta"]["total"], "open jobs")
for job in data["jobs"][:5]:
    print(job["id"], job["title"], "|", job["location"]["name"], "|", job["absolute_url"])

That's the whole thing for one board. Add ?content=true and Greenhouse also returns the description, departments and offices.

Why it gets messy with more than a few boards

Fetching one board is easy. Tracking forty across three providers is where the time goes:

Three schemas. Greenhouse has title and location.name. Lever has text, categories.location, categories.team and workplaceType. Ashby has title, location, isRemote, workplaceType and employmentType, with compensation only if you pass includeCompensation=true. Dates come in different formats. You end up writing three parsers and a mapping layer.
Errors. Tokens change when a company rebrands, boards move to another provider, and you get 404s, 429s and the occasional 5xx. A loop that dies on the first exception loses the other 39 companies.
Dedupe and diff. To see new roles you need a stable key per posting and the previous run's keys.
Personal data. Some board payloads and descriptions name recruiters or hiring managers, with emails or booking links. If you only want hiring signals, you should not be storing those.

If that list doesn't bother you, the raw endpoints above are a fine answer. If it does, a normalised feed saves the mapping work.

Hands-on: one feed, CSV export, weekly diff

Company Job Board Feeds is an Apify Actor that reads the boards you list, maps all three providers to one schema (title, department, team, locations, workplace_type, employment_type, salary fields when published, ISO 8601 dates, job_url), and returns one error record per board that fails instead of failing the run. Retryable responses (429 and 5xx) are retried with exponential backoff and jitter, up to 4 times.

You need an Apify account and an API token. The code uses apify-client 3.x, where runs come back as objects (run.default_dataset_id); older versions returned dicts (run["defaultDatasetId"]).

pip install "apify-client>=3"
export APIFY_TOKEN=your_token_here

The script

import csv
import json
import os
from decimal import Decimal
from pathlib import Path

from apify_client import ApifyClient

STATE = Path("seen_jobs.json")

run_input = {
    "companies": [
        "https://boards.greenhouse.io/airbnb",                  # board URL
        "lever:palantir",                                       # provider:token
        {"provider": "ashby", "token": "openai", "name": "OpenAI"},  # object
    ],
    "titleKeywords": ["engineer", "sales"],
    "postedWithinDays": 30,
    "includeDescription": False,
}

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("reliable-apps/company-job-board-feeds").call(
    run_input=run_input,
    max_total_charge_usd=Decimal("0.50"),  # hard cap for this run
)
if run is None:
    raise SystemExit("Run did not finish")

items = list(client.dataset(run.default_dataset_id).iterate_items())
jobs = [i for i in items if i["type"] == "job"]
errors = [i for i in items if i["type"] == "error"]

for err in errors:
    print(f"FAILED {err['input']}: {err['error_code']} - {err['message']}")

# 1. Full snapshot to CSV
fields = ["provider", "company", "job_id", "title", "department", "team",
          "locations", "workplace_type", "employment_type", "posted_at", "job_url"]
with open("jobs.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=fields, extrasaction="ignore")
    writer.writeheader()
    for job in jobs:
        writer.writerow({**job, "locations": "; ".join(job.get("locations") or [])})

# 2. Diff against the previous run
seen = set(json.loads(STATE.read_text())) if STATE.exists() else set()
current = {f"{j['provider']}:{j['job_id']}" for j in jobs}
new_jobs = [j for j in jobs if f"{j['provider']}:{j['job_id']}" not in seen]
closed = seen - current

print(f"{len(jobs)} open, {len(new_jobs)} new, {len(closed)} closed since last run")
for job in new_jobs:
    print(f"NEW  {job['company']:<12} {job['title']}  {job['job_url']}")

STATE.write_text(json.dumps(sorted(current)))

What to notice:

provider + job_id is the key. The Actor already dedupes on it within a run, so it is safe to diff on.
Failed boards are records, not exceptions. A wrong token shows up as error_code: "not_found" with the HTTP status, and the other companies still come back.
Closed roles count too. A key that disappears from one week to the next is often a better signal than a new one.
The first run reports everything as new. That's expected; the diff starts working from run two.

Running it weekly

Two easy ways:

Put the script on a cron job or a GitHub Actions schedule and keep seen_jobs.json as an artifact or in a small database.
Create an Apify Schedule with the same input, and have your script read the latest run's dataset instead of starting a new run.

What it costs

$2 per 1,000 jobs ($0.002 per job record) on every Apify plan, plus a $0.00005 start fee per run. A board that fails returns a free error record, the closing summary record is free, and platform usage is included. Tracking 40 companies with about 25 matching roles each is roughly 1,000 jobs, or $2 per run. Filters (titleKeywords, locationContains, postedWithinDays, maxJobsPerCompany) are applied before records are written, so tight filters cost less.

Use case: hiring signals and competitor hiring

A weekly diff answers questions like:

Which competitors opened roles in a new country this month?
Did a prospect just post its first data or security role? That's often a buying moment.
Which companies in a portfolio stopped posting entirely?

Group new_jobs by company and department, and send yourself the counts. You don't need the descriptions for any of this, which is why they are off by default.

Responsible use

Only boards you choose. The Actor fetches the boards in your list. It never discovers or enumerates companies.
No personal data. Recruiter, owner and hiring-manager fields are never read; the parser keeps a fixed allow-list of fields. If you turn on descriptions, emails, phone numbers, LinkedIn and Calendly links and "reports to Name" phrases are stripped. That scrubbing is best-effort pattern matching, so treat descriptions with care.
Public endpoints, politely. robots.txt is honoured, there is at most one request per second per host, and a 401, 403 or captcha ends the attempt for that board with no retry.
Don't rebuild a job board. Link to the canonical job_url rather than republishing postings, and don't use the output for AI training where a provider's terms forbid it.

DEV Community: Reliable Apps by Vasilis Linakis

Google Trends API alternatives in 2026: getting Trends data as JSON (and what to do about 429s)

The landscape, checked on 2026-10-31

1. The official Google Trends API (alpha)

2. pytrends

3. Hosted scraping services

What our Actor does, and does not do

Hands-on: compare terms, export to CSV, pull related queries

Step 1: run a comparison

Step 2: interest over time to CSV

Step 3: related queries

Step 4: schedule it

When not to use it

Responsible use

Links

How to get Greenhouse, Lever and Ashby job postings as JSON (and track new roles weekly)

The endpoints are public and documented

Raw example: Greenhouse

Why it gets messy with more than a few boards

Hands-on: one feed, CSV export, weekly diff

The script

Running it weekly

What it costs

Use case: hiring signals and competitor hiring

Responsible use

Links