# Google Trends Scraper & Breakout Monitor (`automa-flow/google-trends-monitor`) Actor

Google Trends scraper API for interest over time, regions, related queries, rising searches, Breakouts, and Trending Now. Export keyword snapshots or schedule watchlists that return only new signals—no Google account, API key, or browser.

- **URL**: https://apify.com/automa-flow/google-trends-monitor.md
- **Developed by:** [Vadim Bezrukov](https://apify.com/automa-flow) (community)
- **Categories:** SEO tools, Marketing, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $4.00 / 1,000 completed keyword groups

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Google Trends Scraper & Breakout Monitor

Scrape Google Trends interest over time, regional demand, related queries,
**Breakouts**, and Trending Now. Use snapshot mode for one-off research, or
schedule a watchlist and receive only new trend signals instead of diffing a
full export after every run.

Use the structured output from the Apify Console, API, schedules, webhooks, Make,
Zapier, dashboards, or AI agents. No Google account, Google API key, browser, or
CAPTCHA solving is required.

- Up to **200 comparison groups** per run, with 1-5 jointly normalized keywords
  in each group.
- **$0.004 per completed keyword group** or **$0.002 per completed Trending Now
  country**; failed and partial checks are not charged.
- Every group gets an explicit `SUCCESS`, `NOT_FOUND`, `PARTIAL`, or `FAILED`
  status, so a source failure never looks like zero demand.

***

### Choose a workflow

| Goal | Recommended setup | Result |
| --- | --- | --- |
| Discover rising SEO keywords | `snapshot` + `all`, collect `related_queries` | Top, rising, and Breakout related searches with Google's growth labels |
| Monitor AI or market breakouts | `monitor` + `changesOnly`, keep a stable `monitorId` | Only newly rising queries, new Breakouts, and meaningful growth-band changes |
| Compare ecommerce demand | `snapshot` + `all`, use `property: shopping` | Jointly normalized timelines, related searches, and regional demand |
| Track Trending Now | collect `trending_now` and set `trendingGeos` | Newly appearing topics by country with approximate traffic and related news |

### Start in 2 minutes

1. Replace `meal prep` with a topic your audience searches for.
2. Keep **Snapshot** + **All records** to get useful rows on the first run.
3. Keep the default Apify proxy for keyword data.
4. Click **Start** and open the **Related queries** dataset view.

The Store form is prefilled with `meal prep`; replace it with your own keyword.
The equivalent copy-paste input is:

```json
{
  "keywords": ["meal prep"],
  "geo": "US",
  "timeframe": "today 3-m",
  "dataTypes": ["related_queries"],
  "mode": "snapshot",
  "outputMode": "all",
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"], "apifyProxyCountry": "US" }
}
```

This returns Google's current top, rising, and Breakout related searches. To
turn the same configuration into an alerting workflow, switch to `monitor` +
`changesOnly`. The first successful monitor run creates a baseline; later runs
emit newly rising queries, new Breakouts, meaningful growth-band changes, and
new Trending Now topics.

***

### What makes this different

Most Google Trends scrapers hand you a fresh full export every run and leave you
to diff it. This one is built to be **scheduled**:

- **Bulk keyword groups.** Up to 200 comparison groups per run, each with up to
  5 keywords, each with your own `externalId`.
- **Breakout and rising detection.** Repeat runs return only the queries that
  newly joined Google's rising list, became a **Breakout**, or crossed a
  growth band.
- **Deterministic monitoring state.** The diff is always last *successful*
  check against this *successful* check.
- **Explicit failure semantics.** `NO_RESULTS` and `SOURCE_FAILED` are
  different, always. A throttled request can never come back as "interest = 0".
- **Predictable pricing.** You are charged per keyword group Google answered,
  not per data point. A group costs the same whether it returns 90 timeline
  points or 9,000.

***

### One important rule about Google Trends numbers

Google Trends values are **relative, not absolute search volume**. A value of
100 means "the highest point on this chart", and the chart is renormalized for
every request.

**A score of 70 in one group is not comparable to a score of 70 in another.**

This is the most common way Trends data gets misreported. Every row therefore
carries a `source_scaling_context` that says exactly which values are comparable:

```json
{
  "id": "c6643ad8bb7bb5ad",
  "scope": "within_comparison_group",
  "comparison_group": ["chatgpt", "claude ai"],
  "geo": "US",
  "timeframe": "today 3-m",
  "category": 0,
  "property": "web",
  "data_type": "interest_over_time",
  "resolution": "DAY"
}
```

**Two values are comparable if and only if their `source_scaling_context.id`
matches.** The id changes whenever the keywords, location, timeframe, category,
property or bucket size changes.

What follows from that, and what this Actor therefore refuses to do:

| | |
| --- | --- |
| Compare keywords **inside** one group | Valid - Google normalizes them jointly. That is what a comparison group is for. |
| Compare values **across** groups | Not valid. Different scaling basis. |
| Compare US against DE, or 7d against 12m | Not valid. Different scaling basis. |
| Claim absolute search volume | Never. Google does not publish it. |
| Report "interest up 34% since last week" | Not emitted. Two independently normalized 0-100 series cannot be subtracted. |

#### Partial periods

The newest bucket in any timeline is usually still accumulating, and Google
flags it `isPartial`. It looks exactly like a collapse in interest, and it is
the classic source of fake "traffic is crashing" alerts. Rows carry
`is_partial: true`, and **partial buckets are excluded from every signal this
Actor emits**.

#### Missing data is not zero

Where Google has too little data it returns a 0 alongside `hasData: false`.
Those rows are published as `value: null` with `has_data: false`, never as `0`.

***

### Data returned

| Data type | What you get |
| --- | --- |
| `interest_over_time` | Relative interest per keyword per time bucket, with `is_partial` |
| `related_queries` | Top and rising queries, including **Breakout** entries |
| `interest_by_region` | Relative interest per region, with `has_data` |
| `trending_now` | Today's trending searches per country, with news headlines |

Use the purpose-built dataset views to inspect **New signals**, **Related
queries**, **Interest over time**, **Trending now**, or **Group status** without
manually selecting fields.

**Related topics is deliberately not offered.** Google currently answers that
endpoint with HTTP 200 and an empty list for every keyword tested, including
high-volume ones. Shipping it would report "no related topics" for every keyword
on earth, which is exactly the kind of confident-looking false zero this Actor
exists to prevent. If Google starts serving it again, it will be added.

***

### Input reference

```json
{
  "queries": [
    { "keywords": ["chatgpt", "claude ai", "gemini"], "externalId": "ai-assistants" },
    { "keywords": ["electric bike"], "externalId": "ebikes" }
  ],
  "geo": "US",
  "timeframe": "today 3-m",
  "category": 0,
  "property": "web",
  "dataTypes": ["interest_over_time", "related_queries", "interest_by_region"],
  "mode": "monitor",
  "outputMode": "changesOnly",
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"], "apifyProxyCountry": "US" }
}
```

| Field | Default | Notes |
| --- | --- | --- |
| `queries` | - | Up to 200 groups, 1-5 keywords each (5 is Google's limit) |
| `geo` | `US` | `US`, `DE`, `US-CA`, … Empty string for worldwide |
| `timeframe` | `today 3-m` | `now 1-H` … `today 5-y`, `all` |
| `category` | `0` | Google Trends category ID; 0 is all |
| `property` | `web` | `web`, `images`, `news`, `shopping`, `youtube` |
| `dataTypes` | timeline + related + region | Fewer types means fewer requests and less throttling |
| `mode` | `monitor` | `snapshot` stores nothing |
| `outputMode` | `changesOnly` | `all` also returns timelines and regions |
| `trendingGeos` | run's `geo` | Countries for `trending_now` |
| `monitorId` | - | Separates independent watchlist histories |

#### Modes

- **`snapshot`** - what Google says right now. Nothing is stored, nothing is
  diffed.
- **`monitor`** - remembers the last successful check per configuration.

#### Output modes

- **`changesOnly`** - new and changed rising/breakout queries, new trending
  topics, plus a status row per group. This is the alerting shape.
- **`all`** - additionally every timeline point and region score. Timelines are
  measurements rather than events, so `changesOnly` does not include them.

***

### Monitoring semantics

The first successful check of a configuration is a **`BASELINE`** - it records
what is already there without alerting on the whole backlog. From then on:

| `change_type` | Meaning |
| --- | --- |
| `BASELINE` | First successful check of this configuration |
| `RISING_QUERY_NEW` | A query joined Google's rising list |
| `BREAKOUT_NEW` | A query became a **Breakout** (rising past Google's reportable ceiling) |
| `RISING_QUERY_CHANGED` | A rising query's growth crossed a band |
| `TRENDING_TOPIC_NEW` | A new topic in the Trending Now feed |
| `UNCHANGED` | Already reported; suppressed in `changesOnly` |
| `OBSERVATION` | A timeline point or region score - a measurement, not an event |

**Growth bands.** Google's rising percentages jitter run to run, so a change is
reported only when growth crosses a band: `<100%`, `100-249%`, `250-499%`,
`500-999%`, `1000%+`, `breakout`. Without this, every run would alert that
+240% became +250%.

**There is no "breakout ended" event.** Related queries are a **top-N ranked
list**, not an inventory. A query dropping off it means something else outranked
it - Google never says the rise ended. Reporting that as an event would be
inventing information, so this Actor does not.

**Monitor identity** includes the full normalized configuration: keywords,
location, timeframe, category, property and data type. `chatgpt` in `US` over
`today 3-m` and `chatgpt` in `DE` over `today 12-m` are separate monitors and
never share state.

**State is only advanced by runs that can stand behind it.** A run that was
throttled, whose payloads stopped parsing, or that was cut short by a charging
limit leaves the previous state untouched. A verified `NOT_FOUND` answer is
valid state, never a source failure. Overwriting state after a failed check
would record signals as delivered that you never received, and silence them
forever.

***

### Output

One flat row shape, discriminated by `record_type` and `data_type`, so the whole
run exports as one CSV.

A breakout signal:

```json
{
  "record_type": "observation",
  "source": "Google Trends",
  "source_id": "trends:c6643ad8bb7bb5ad:rel:rising:chatgpt atlas browser",
  "scraped_at": "2026-08-31T08:00:00Z",
  "schema_version": 1,
  "fingerprint": "9f1c2b7a4d…",
  "external_id": "ai-assistants",
  "status": "SUCCESS",
  "data_type": "related_queries",
  "keyword": "chatgpt",
  "related_query": "chatgpt atlas browser",
  "related_type": "rising",
  "related_value": null,
  "formatted_value": "Breakout",
  "change_type": "BREAKOUT_NEW",
  "source_scaling_context": { "id": "c6643ad8bb7bb5ad", "…": "…" },
  "source_metadata": { "is_breakout": true, "growth_band": "breakout" }
}
```

Every requested group also gets exactly one `group_status` row, including the
ones that failed - 200 groups in always means 200 status rows out:

```json
{
  "record_type": "group_status",
  "status": "PARTIAL",
  "comparison_group": "chatgpt vs claude ai",
  "external_id": "ai-assistants",
  "source_metadata": {
    "data_type_statuses": {
      "interest_over_time": "SUCCESS",
      "related_queries": "FAILED",
      "interest_by_region": "SUCCESS"
    }
  },
  "error": { "code": "THROTTLED", "message": "…" }
}
```

#### Statuses

| `status` | Meaning |
| --- | --- |
| `SUCCESS` | Google answered with data |
| `NOT_FOUND` | Google answered and genuinely had nothing. A real, verified absence |
| `PARTIAL` | Some requested data types succeeded, others did not |
| `FAILED` | We could not find out. **Never** means zero interest |

Run metrics land in the key-value store under `RUN_SUMMARY`: group counts by
status, requests, retries, 429s, session bootstraps, proxy bytes, rows by type,
new breakouts, source health, and whether state was saved.

***

### Proxy is required for keyword data

> This Actor is not affiliated with, endorsed by, or connected to Google.
> "Google" and "Google Trends" are trademarks of Google LLC. It reads publicly
> available Google Trends data.

Google Trends rate-limits its data endpoints **per IP address**, and it is
tight. Measured on 2026-08-31 from a single clean address:

- roughly a handful of widget requests before refusal;
- a fresh cookie and a freshly-minted widget token from the same address are
  **still refused**, so the block is on the IP, not the session;
- once blocked, the address stayed blocked for **over 33 minutes** of
  once-a-minute polling, and had still not recovered when we stopped watching;
- a 5-group run direct from one address: **0% success, 50% of requests 429**.

So the Actor rotates proxy sessions rather than repeatedly using a refused IP,
and `proxyConfiguration` is required when you request keyword data.

The default is Apify's Residential pool. On 2026-09-01, both Residential and
datacenter completed 10/10 benchmarks, but a later production run through the
default auto pool exhausted four rotated sessions with HTTP 429. A later
production check also exhausted four Residential sessions when country selection
was automatic, while `RESIDENTIAL@US` succeeded immediately. US-targeted
Residential therefore became the reliability-first default; a custom proxy
remains available for controlled deployments. Saved inputs that still contain
only `{"useApifyProxy": true}` are automatically migrated at runtime.

Trending Now alone works without a proxy. For a Trending Now-only run, the Actor
ignores the proxy setting so the public RSS feed does not incur proxy traffic.

No CAPTCHA solving, no Google login, no browser, and no access-control
circumvention is involved. The Actor uses plain HTTPS against publicly
available endpoints and honours Google's robots.txt: it never requests
`/trends/explore` or `/explore`, the two paths
[trends.google.com/robots.txt](https://trends.google.com/robots.txt) disallows.
That constraint is enforced in code, not by convention.

***

### Pricing

Pay per event:

| Event | Price | What it covers |
| --- | ---: | --- |
| **Completed keyword group** | **$0.004** | One comparison group Google fully answered - all its timeline points, region scores and related queries included |
| **Completed Trending Now feed** | **$0.002** | One country's trending feed and its topics |

These prices include Apify platform usage, including compute and the default
Residential proxy traffic. You do not receive a separate platform-usage charge
for a standard pay-per-event run.

You are **never** charged for retries, `PARTIAL` groups, throttled requests,
failed groups, or input rows rejected as invalid. A group that Google fully
answered with no data is charged, because checking it was the work.

100 fully completed groups cost $0.40. A partial or failed check costs no event
charge, so the watchlist size is the maximum number of charges.

***

### Schedule alerts

The reason to run this twice: with `mode: monitor` and
`outputMode: changesOnly`, a repeat run returns only signals that are new since
the last successful check.

For example, run it daily and send new Breakouts to Slack, Make, Zapier, or your
own webhook:

1. Actor -> **Schedule** -> daily.
2. Actor -> **Integrations** -> **Webhook** on `ACTOR.RUN.SUCCEEDED`.
3. Filter the dataset for `change_type` in `BREAKOUT_NEW`, `RISING_QUERY_NEW`.

```bash
## Only this run's new breakouts
curl "https://api.apify.com/v2/datasets/<DATASET_ID>/items?clean=true&format=json" \
  | jq '[.[] | select(.change_type == "BREAKOUT_NEW")]'
```

```bash
## Start a run from the API
curl -X POST "https://api.apify.com/v2/acts/automa-flow~google-trends-monitor/runs" \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
        "queries": [{"keywords": ["electric bike"], "externalId": "ebikes"}],
        "geo": "US",
        "timeframe": "today 3-m",
        "mode": "monitor",
        "outputMode": "changesOnly"
      }'
```

Python:

```python
from apify_client import ApifyClient

client = ApifyClient("<YOUR_TOKEN>")
run = client.actor("automa-flow/google-trends-monitor").call(
    run_input={
        "queries": [{"keywords": ["electric bike"], "externalId": "ebikes"}],
        "geo": "US",
        "mode": "monitor",
        "outputMode": "changesOnly",
        "proxyConfiguration": {
            "useApifyProxy": True,
            "apifyProxyGroups": ["RESIDENTIAL"],
            "apifyProxyCountry": "US",
        },
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)
```

#### Webhook-friendly output

Filter observation rows by `change_type`. The most useful alert values are
`BREAKOUT_NEW`, `RISING_QUERY_NEW`, `RISING_QUERY_CHANGED`, and
`TRENDING_TOPIC_NEW`. Keep the `group_status` rows in operational workflows so
that a failed check is visible instead of looking like “nothing changed”.

### Use with AI agents through Apify MCP

Expose this Actor as a typed tool in any MCP-compatible client:

```text
https://mcp.apify.com?tools=automa-flow/google-trends-monitor
```

Example prompt:

```text
Run automa-flow/google-trends-monitor for one comparison group containing
"chatgpt", "claude ai", "gemini", and "perplexity ai" in the US over the
past 90 days. Return rising and Breakout related queries, keep group_status
rows visible, and cite each signal's source_url.
```

For a scheduled agent, use `mode: monitor`, `outputMode: changesOnly`, and a
stable `monitorId`. Values from different comparison groups, locations,
properties, or timeframes are not directly comparable.

***

### Limitations

- Values are relative and unitless. Google does not publish absolute volume.
- Google decides the bucket size from the timeframe; it is reported per row, and
  daily and weekly series are not comparable.
- Maximum 5 keywords per comparison group. That is Google's limit, not ours.
- Related topics is not returned (see above).
- Trending Now is per country; there is no worldwide feed.
- Rising and breakout lists are top-N rankings, so absence from them carries no
  information and is not reported as an event.
- Throughput is bounded by Google's per-IP rate limit, not by this Actor.

***

### Support

When reporting an issue, include the run ID and the affected group status. Do
not paste API tokens, proxy URLs, cookies, or other credentials. Source changes
are handled as explicit failures so a broken response cannot silently become a
zero-interest result.

# Actor input Schema

## `keywords` (type: `array`):

Fast start: paste up to 200 search terms, one per line. Each term becomes its own independently scaled Google Trends group. Use Comparison groups below only when you need 2-5 keywords normalized against each other.

## `queries` (type: `array`):

Optional groups of 1-5 keywords that Google normalizes together, making values inside a group directly comparable. Keywords in different groups are NOT comparable. externalId is echoed onto every result and never sent to Google. The combined limit with Keywords is 200 groups.

## `geo` (type: `string`):

ISO code deciding which country or subregion Google measures, for example US, DE, GB, or a subregion such as US-CA. Leave empty for worldwide. Changing this changes the scaling basis, so values are not comparable across locations.

## `timeframe` (type: `string`):

How far back Google measures. Google picks the bucket size from this (hourly, daily, weekly or monthly) and reports it on every row. Values are not comparable across different timeframes.

## `category` (type: `integer`):

Google Trends category ID to restrict the search to. 0 means all categories. Changing this changes the scaling basis.

## `property` (type: `string`):

Which Google search surface to measure. Values are not comparable across properties.

## `dataTypes` (type: `array`):

Which datasets to fetch per group. Fewer data types means fewer requests, a faster run and a lower chance of being throttled. Related topics is deliberately not offered: Google currently answers that endpoint with an empty list for every keyword, and publishing it would report 'no related topics' everywhere.

## `mode` (type: `string`):

snapshot returns what Google says right now and stores nothing. monitor remembers the last successful check so later runs can report only what changed.

## `outputMode` (type: `string`):

changesOnly returns new and changed rising/breakout queries and new trending topics, plus a status row per group. all additionally returns every timeline point and region score. Timelines are measurements rather than events, so they are only returned by all.

## `trendingGeos` (type: `array`):

Countries whose Trending Now feed to fetch, for example US, DE, JP. Only used when trending\_now is selected above; defaults to the Location setting. Worldwide has no trending feed.

## `monitorId` (type: `string`):

Optional name separating independent monitoring histories in the same Apify account, for example 'seo-team' and 'ecommerce-team'. Leave empty unless you run several unrelated watchlists.

## `proxyConfiguration` (type: `object`):

Required for keyword data. Google Trends rate-limits its data endpoints per IP address. Production verification showed four Residential sessions with automatic country selection receiving HTTP 429, while RESIDENTIAL with US country targeting succeeded immediately. RESIDENTIAL@US is therefore the reliability-first default. This setting is ignored by Trending Now-only runs because that public RSS feed needs no proxy.

## Actor input object example

```json
{
  "keywords": [
    "meal prep",
    "electric bike"
  ],
  "queries": [
    {
      "keywords": [
        "chatgpt",
        "claude ai"
      ],
      "externalId": "ai-assistants"
    },
    {
      "keywords": [
        "electric bike"
      ]
    }
  ],
  "geo": "US",
  "timeframe": "today 3-m",
  "category": 0,
  "property": "web",
  "dataTypes": [
    "interest_over_time",
    "related_queries",
    "interest_by_region"
  ],
  "mode": "snapshot",
  "outputMode": "all",
  "trendingGeos": [
    "US",
    "GB"
  ],
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": [
      "RESIDENTIAL"
    ],
    "apifyProxyCountry": "US"
  }
}
```

# Actor output Schema

## `results` (type: `string`):

No description

## `runSummary` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "keywords": [
        "meal prep"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("automa-flow/google-trends-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "keywords": ["meal prep"] }

# Run the Actor and wait for it to finish
run = client.actor("automa-flow/google-trends-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "keywords": [
    "meal prep"
  ]
}' |
apify call automa-flow/google-trends-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,automa-flow/google-trends-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/WecREidW3gHipWFzP/builds/99lTG5edyaupVUPHn/openapi.json