Twitter Trends Scraper - Brand & Keyword Monitoring

Twitter Trends Scraper — Trending Topics, Hashtags & Brand Alerts

Twitter Trends Scraper - Brand & Keyword Monitoring pulls the live X/Twitter trending-topics board for Worldwide or any of 62 country markets and returns typed JSON — one row per trend, per slice. Unlike a plain trends dump, it checks every trend against your own brand, product, or competitor keyword list and remembers what it saw last run, so a scheduled task can report only what's genuinely new. Trends are split into hashtags and plain-text topics, ranked, timestamped to the real UTC snapshot hour, and tagged with a match reason — ready for a dashboard, a Slack alert, or a database, with no HTML parsing on your end. This guide covers every input and output field and how social-listening, SEO, and research teams actually deploy it on a schedule.

What Does This Twitter Trends Scraper Do?

It reads the public getdaytrends.com board — a live mirror of X/Twitter's trending-topics feed — for Worldwide or any of 62 country markets, and turns each trend row into structured JSON. No X/Twitter account, login, or API key is required; the source page is public. Every trend is checked against an optional keyword watch list (case-insensitive, #-insensitive), classified as a hashtag or a plain topic, and — if you're running it on a schedule — compared against a named, persistent memory bucket so the actor can tell you which trends are genuinely new since the last run.

• Scrapes the live board (rank 1–50) for Worldwide or any of 62 country markets
• Adds hourly rewinds of the same board, 1 to 23 hours back, in the same run
• Matches every trend against a keyword watch list with three strictness levels (contains, wholeWord, exact)
• Flags matches while keeping the full board, or filters down to matches only
• Splits hashtags from plain-text topics via trendType / isHashtag
• Detects new-since-last-run trends using a named, persistent key-value store — not the run's ephemeral default store
• Accepts custom getdaytrends.com URLs and legacy base-actor input keys for drop-in compatibility

Features & Capabilities

The core engine is a resilient HTML scraper with retry/backoff and soft-block detection; the watch-list and memory layers run on top of it, entirely on data already fetched — no extra requests.

Core features

• Board coverage: the source page ships four trend tables — two halves of the 50-trend board (table.ranking.trends) plus two sidebar panels (table.ranking.top) that repeat board entries under different semantics ("top by score", "longest trending"). This actor returns the board only by default so the row count matches the real board, labelling every row's origin in sourcePanel; set includePanelRows to also pull the sidebar panels.
• Keyword watch list: watchKeywords is matched against every trend name with a leading # stripped on both sides, so nike matches both Nike and #Nike. keywordMatch controls strictness — contains (cup matches World Cup Final), wholeWord (cup does not match cupcake), or exact.
• Flag vs. filter: watchMode: "flag" keeps the whole board with isWatchMatch tagged per row; watchMode: "only" drops everything that didn't match, so a scheduled alert stays short.
• New-since-last-run detection: the actor opens a named (persistent) key-value store, twitter-trends-watch-memory, and compares this run's trends against the set that was present in the previous run under the same alertMemoryKey. isNewSinceLastRun is a real boolean from the second run onward, and null — never a misleading true — on the first run or right after resetWatchMemory.
• Hourly rewinds: alsoCheckHoursAgo adds 1–23 hour snapshots of the same board alongside (or instead of) the live board, one request each.
• Legacy-compatible input: the original base actor's country, live, and hour1…hour23 keys are still read — accepted either at the top level or nested under a flags object — and take priority over this actor's own watchCountry / includeLiveBoard / alsoCheckHoursAgo equivalents when supplied, so an input JSON written for the base Twitter Trends Scraper runs here unchanged.
• Export as JSON, JSONL, CSV, Excel, HTML table, or XML — every standard Apify dataset format.

How this actor compares to other Twitter/X and trend scrapers

Compared as of 2026-07-08 (Apify Store data snapshot), against the top-ranked competing listings for this search space.

Feature	Twitter Trends Scraper - Brand & Keyword Monitoring	crawlerbros/twitter-keywords-scraper	vnx0/google-trends-scraper
Platform	X/Twitter (via getdaytrends.com board)	X/Twitter (native search)	Google Trends
Login/cookies required	❌ No	✅ Yes — auth_token + ct0 session cookies	❌ No
Entity returned	Trending topics/hashtags (board rank)	Individual tweets (text, engagement)	Daily trending search keywords
Keyword watch + match strictness	✅ 3 modes (contains/wholeWord/exact)	Search-term input only, no post-filter matching	Not documented
Cross-run "new since last run" alerting	✅ Named persistent memory, isNewSinceLastRun	Not documented	Not documented
Historical/rewind slices	✅ Hourly, 1–23h back	Not documented	✅ Up to 90 days via daysBack
Output format	Typed JSON, one schema for all slices	Typed JSON	Typed JSON

If your use case is feeding structured data straight into an LLM or a dashboard, the "login required" and "new since last run" rows are the decision-makers — a scraper that needs refreshed session cookies every 30–60 days is a maintenance burden a public-board scraper doesn't have, and post-hoc deduplication logic you'd otherwise write yourself is already built into the memory layer here.

When another tool might suit you better

If you need the actual text, author, and engagement metrics (likes, retweets, replies) of individual tweets matching a search term — rather than the aggregate trending-topics board — crawlerbros/twitter-keywords-scraper is the better fit; it returns per-tweet data at the cost of requiring your own X/Twitter session cookies. If your interest is specifically Google's "Trending Now" search feed rather than X/Twitter, vnx0/google-trends-scraper covers that with up to 90 days of historical backfill.

Twitter Trends Scraper within the Scrapio data stack

This actor covers Twitter/X trending topics and hashtags. For individual posts matching a keyword or hashtag, use Twitter X Posts Scraper By Keyword & Hashtag Search. For reply sentiment on a given post, use Twitter X Reply Scraper: Reply Sentiment & Tone Breakdown. For posts paired with the author's profile details, use X Twitter Posts Search With Author Profile Details.

Why do developers and data teams scrape Twitter/X trends?

🏢 Brand and social-listening teams

A marketing or comms team sets watchKeywords to their brand, product, and campaign names, watchMode: "only" to drop the noise, and schedules the run hourly with newOnly: true. Every dataset row that lands carries matchedKeyword, isNewSinceLastRun, and trendUrl, so an automation can push straight to Slack or a ticketing system the moment a brand term starts trending, without re-alerting on something already flagged in the previous run.

📊 AI training data and RAG indexing

The trend field is the high-information text signal — short, current, real-world phrases people are searching and discussing right now, tagged as hashtag or topic via trendType. For RAG enrichment, trend plus locationName and snapshotTimeUtc let a retrieval layer answer "what was trending in Germany at this hour" with a grounded citation back to sourceUrl. For training data, rank, isHashtag, and trendType are consistently typed across every row and every market, so a trend-classification or virality-labeling dataset needs no normalization pass.

📱 Competitive and market intelligence

Set the watch list to competitor names and brands, leave watchMode on flag to keep full board context, and track rank over successive scheduled runs to see whether a competitor's product or campaign is climbing or falling on the board relative to your own terms in the same run.

🔬 Research and academic use

alsoCheckHoursAgo plus a scheduled task builds an hour-by-hour trending-topics time series for a single market or many, useful for research into virality, topic lifecycle, or regional discourse patterns. All data returned is limited to what the public getdaytrends.com board publishes — no private account or engagement data is collected.

🎥 Product and monitoring tool builders

Because the memory layer, hashtag/topic split, and keyword matching all run inside the actor, a directory or monitoring product can point several scheduled tasks — one per market or per client, each with its own alertMemoryKey — directly at this actor's dataset output instead of building and maintaining that logic separately.

🍚 Input Parameters

All 18 parameters, read directly from .actor/actor.json. None are required — an empty input runs the live Worldwide board.

Parameter	Required	Type	Default	Description
watchKeywords	No	array (stringList)	[]	Case-insensitive terms matched against every trend name; a leading # is ignored on both sides, so nike matches #Nike and Nike. Leave empty to keep every trend.
watchMode	No	string, enum: flag, only	"flag"	flag keeps the whole board and marks matches with isWatchMatch=true. only drops non-matching rows. Ignored when the watch list is empty.
keywordMatch	No	string, enum: contains, wholeWord, exact	"contains"	contains = keyword appears anywhere in the trend. wholeWord = must stand alone (cup does not match cupcake). exact = whole trend equals the keyword.
trendType	No	string, enum: all, hashtags, topics	"all"	Keep hashtags only, plain topics only, or both. Applied before the watch list.
newOnly	No	boolean	false	Drops every trend already on the board in the previous run under the same memory key. Default reports everything, still tagged with isNewSinceLastRun.
alertMemoryKey	No	string (textfield)	""	Namespaces the run-to-run memory so several schedules can watch different markets or keyword lists independently. Empty derives it from the market, e.g. "united-states".
resetWatchMemory	No	boolean	false	Clears this memory bucket before the run so the current board becomes the new baseline. isNewSinceLastRun will be null on that run.
watchCountry	No	string, enum (62 codes + "")	""	The country board to read. "" = Worldwide. Overridden by the legacy country input if supplied.
includeLiveBoard	No	boolean	true	Pulls the trends on the board right now — the slice you want for alerting.
alsoCheckHoursAgo	No	array (stringList)	[]	Hourly rewinds of the same board, "1"–"23" hours back. Each entry costs one extra request.
includePanelRows	No	boolean	false	Also returns the two sidebar ranking panels ("top by score", "longest trending"), labelled in sourcePanel. Off by default so row count matches the real board.
country	No	string, enum (62 codes + "")	""	Legacy base-actor key. Takes priority over watchCountry when supplied.
live	No	boolean	(no default)	Legacy base-actor key. Overrides includeLiveBoard when present in the input.
startUrls	No	array (stringList)	[]	Optional raw getdaytrends.com URLs scraped in addition to the slices above. Supports {today}, {yesterday}, and {day3} placeholders.
maxRetries	No	integer	3	Retries per URL (min 0, max 10) before recording an uncharged accounting row.
requestTimeoutSecs	No	integer	30	Per-request timeout in seconds (min 5, max 300).
proxy	No	object (proxy editor)	{"useApifyProxy": false}	The source site does not require a proxy — leave this off unless runs get rate-limited. If a selected proxy fails its connectivity check, the actor falls back to Apify RESIDENTIAL, then to no proxy.

No parameter in this schema accepts credentials, tokens, or cookies — none of the 18 fields are marked isSecret, because none are needed. The actor reads a public page and requires no account of any kind.

{
  "watchKeywords": ["nike", "adidas", "world cup"],
  "watchMode": "flag",
  "keywordMatch": "wholeWord",
  "trendType": "all",
  "newOnly": true,
  "alertMemoryKey": "nike-us-hourly",
  "watchCountry": "US",
  "includeLiveBoard": true,
  "alsoCheckHoursAgo": ["1", "3"],
  "includePanelRows": false,
  "maxRetries": 3,
  "requestTimeoutSecs": 30
}

Supported URL types and input formats

The actor builds its own request URLs from watchCountry/country and alsoCheckHoursAgo; you don't need to construct URLs by hand for a standard run. For custom slices, startUrls accepts raw getdaytrends.com addresses, with three template placeholders expanded to UTC dates at run time:

• https://getdaytrends.com/united-states/ — the plain live board for a market
• https://getdaytrends.com/{today}/24/ — a templated custom slice, {today} expands to the current UTC date
• Legacy input written for the base actor, e.g. {"country": "GB", "hour1": true, "hour3": true}, is read unchanged — country, live, and hour1…hour23 are accepted both at the top level of the input JSON and nested inside a flags object.

Note on the source site's own dated archive: the yesterday, day2, day3, weekAgo, monthAgo, and yearAgo legacy toggles are still accepted for backward compatibility, but every one of those upstream URLs currently returns HTTP 520 from getdaytrends.com. Requesting them produces an uncharged error row with errorReason: "source_archive_unavailable" rather than silently returning nothing. Hourly rewinds (alsoCheckHoursAgo, 1–23 hours) are unaffected and work normally.

📦 Output Format

Typed, normalized JSON with a stable field set across every market and slice. Three row shapes exist, distinguished by type — a charged trend row per result, and two uncharged accounting shapes (error, notice) that report failures or empty filtered runs without billing you for them.

Output for trend rows (type: "trend")

Every key the row-building code writes, copied from src/main.py:

{
  "type": "trend",
  "isChild": false,
  "isWatchMatch": true,
  "matchedKeyword": "world cup",
  "matchedKeywords": ["world cup"],
  "matchRule": "wholeWord",
  "isNewSinceLastRun": true,
  "firstSeenAt": "2026-07-19T09:14:02.118Z",
  "lastSeenAt": "2026-07-19T09:14:02.118Z",
  "runsSeenCount": 1,
  "alertMemoryKey": "united-states",
  "memoryBaselineRuns": 2,
  "rank": 7,
  "trend": "World Cup Final",
  "trendType": "topic",
  "isHashtag": false,
  "sourcePanel": "board",
  "searchUrl": "https://twitter.com/search?q=World%20Cup%20Final",
  "trendUrl": "https://getdaytrends.com/trend/World%20Cup%20Final/",
  "locationName": "United States",
  "countryCode": "US",
  "snapshotTimeUtc": "2026-07-19T09:00:00Z",
  "sourceUrl": "https://getdaytrends.com/united-states/",
  "timePeriod": "Live",
  "time": "2026-07-19T09:14:02.118Z",
  "scrapedAt": "2026-07-19T09:14:02.118Z"
}

Field	Type	Description
type	string	Always "trend" for this row shape.
isChild	boolean	Always false — this actor emits no nested child entities.
isWatchMatch	boolean or null	Whether this trend matched the watch list; null when no watchKeywords were supplied.
matchedKeyword	string or null	The first watch-list keyword that hit.
matchedKeywords	array or null	Every watch-list keyword that hit.
matchRule	string or null	The match strictness used (contains/wholeWord/exact); null when no watch list is active.
isNewSinceLastRun	boolean or null	New since the previous run under this memory key; null when there is no baseline yet.
firstSeenAt	string	ISO timestamp this trend was first recorded in this memory bucket.
lastSeenAt	string	ISO timestamp of this run.
runsSeenCount	integer	How many runs (including this one) have seen this trend in this memory bucket.
alertMemoryKey	string	The memory bucket namespace used for this run.
memoryBaselineRuns	integer	How many prior runs the comparison was made against; 0 = no baseline.
rank	integer or null	Board position.
trend	string	The trend name, exactly as it appears on the board.
trendType	string	"hashtag" or "topic".
isHashtag	boolean	Whether the trend name starts with #.
sourcePanel	string	"board", "top-by-score", or "longest-trending".
searchUrl	string	Link to this trend's live search results on X.
trendUrl	string	Link to the trend's detail page on getdaytrends.com.
locationName	string	Market name, e.g. "United States", or "Worldwide".
countryCode	string or null	ISO country code; null for Worldwide.
snapshotTimeUtc	string or null	The real UTC hour this board slice represents, parsed from the source page.
sourceUrl	string	The exact page this row was parsed from.
timePeriod	string	The slice label, e.g. "Live", "3 hours ago", "Custom".
time	string	Scrape timestamp — kept for compatibility with the base actor's field name.
scrapedAt	string	Scrape timestamp.

Output for uncharged accounting rows (type: "error" / type: "notice")

A failed slice or an empty filtered run never bills as a result. Failures on a specific URL push a type: "error" row:

{
  "type": "error",
  "isChild": false,
  "errorReason": "source_archive_unavailable",
  "errorDetail": "getdaytrends.com dated archive endpoints return HTTP 520; no trends are retrievable for this slice.",
  "sourceUrl": "https://getdaytrends.com/united-states/<date>/24/",
  "timePeriod": "yesterday",
  "locationName": "United States",
  "countryCode": "US",
  "alertMemoryKey": "united-states",
  "time": "2026-07-19T09:14:02.118Z",
  "scrapedAt": "2026-07-19T09:14:02.118Z"
}

errorReason values observed in the source: source_archive_unavailable (dated archive returns HTTP 520), http_<status> (any other non-200 response), no_trend_table_in_response (a 200 page without a trend table — a soft block), request_error_<ExceptionName> (a network-level failure), and no_trends_parsed (page fetched but nothing parsed). A run that legitimately matches nothing after filtering — rather than failing to fetch — pushes a single type: "notice" row instead, with errorReason: "no_rows_after_filters" and an errorDetail string naming which filters were active, plus memoryBaselineRuns instead of sourceUrl/timePeriod. To keep only billed results, filter the dataset on type == "trend".

Schema stability and export options

Field names stay stable across runs and markets; getdaytrends.com's own front-end changes do not add or remove keys from this schema, since parsing is driven by table structure (table.ranking.trends / table.ranking.top) rather than brittle CSS classes tied to a specific layout. The volume field carried by the original base actor is not emitted here at all — the source page and X's own guest trends endpoint both return it null or, on the base's fallback selector, wrong on a meaningful share of rows, so it was removed rather than shipped null-or-corrupt. A similar isPromoted field was tested and dropped for measuring null on every trend checked. Results export as JSON, JSONL, CSV, Excel, HTML table, or XML from the Apify dataset — the standard Apify Storage export options, no separate delivery mechanism.

Beyond the dataset, the actor also writes a RUN_SUMMARY.json record to the run's key-value store (Storage tab → this run → Key-value store) with runId, market, proxyUsed, slicesRequested, trendRowsCharged, watchKeywords, watchMode, matchRule, watchMatches, alertMemoryKey, memoryBaselineRuns, hasBaseline, newSinceLastRun, distinctTrendsThisRun, and accountingRows — a one-glance summary of what that specific run did.

💡 Twitter Trends Scraper Strategy Guide

🎯 Strategy 1: Real-time brand-mention enrichment

Trigger a run on demand — from a Slack command, a cron job, or another workflow step — with watchKeywords set to your brand and product terms and watchMode: "flag" so the full board comes back for context. Read isWatchMatch, matchedKeyword, and rank off each row and append them to whatever system tracks brand mentions — a spreadsheet, a CRM field, or a monitoring dashboard — so a human sees not just "you're trending" but which term matched and where it currently ranks.

🎯 Strategy 2: Scheduled monitoring and alerting

This is the actor's built-in mechanism. Put it on an Apify Schedule (hourly is a reasonable cadence, matching the board's own hourly rewind granularity), set newOnly: true, watchMode: "only", and a fixed alertMemoryKey per market or campaign. Each run pulls the live board, diffs it against the memory bucket from the previous run, and returns only rows with isNewSinceLastRun: true — feed that dataset straight to a webhook or Slack integration. The first run under a new or reset key returns isNewSinceLastRun: null on every row, since there is nothing to diff against yet; from the second run on, the field is a real boolean.

🎯 Strategy 3: Multi-market dataset build

To build a cross-market trending-topics dataset — for research, a monitoring product, or a historical archive — run one task per watchCountry (or Worldwide), each with its own alertMemoryKey so their memory buckets don't collide, and add alsoCheckHoursAgo to backfill same-run hourly context. Aggregate each task's dataset export (CSV or JSON) into your warehouse or database on whatever cadence your Apify plan's schedule and concurrency allow.

Strategy comparison at a glance

Strategy	Best for	Run pattern	Output format
Real-time enrichment	On-demand brand-mention checks fed into another system	Triggered single run	JSON row per trend
Scheduled monitoring	Hands-off brand/campaign alerting	Apify Schedule, newOnly: true	Filtered JSON, diffed each run
Multi-market dataset build	Research or cross-market archives	One task per market, own alertMemoryKey	CSV/JSON aggregated across tasks

Related Twitter/X Scrapers & Tools

Scraper	What it extracts
Twitter X Posts Scraper By Keyword & Hashtag Search	Individual X/Twitter posts matching a keyword or hashtag
Twitter X Reply Scraper: Reply Sentiment & Tone Breakdown	Reply-level sentiment and tone for a given post
X Twitter Posts Search With Author Profile Details	Posts paired with the posting author's profile details
Tiktok Trending Hashtags Analytics Scraper & Top Videos	TikTok's trending hashtags and their top videos
Reddit Trends Scraper — Trending Subreddit & Velocity Report	Trending subreddits and posting-velocity data on Reddit
linkedin-post-keyword-monitor	Keyword monitoring across LinkedIn posts

How to integrate this Twitter Trends Scraper with your stack

Twitter Trends Scraper - Brand & Keyword Monitoring works with any language or tool that can call the Apify API — there is no separate signup flow or vendor-specific SDK required beyond the Apify client for your language.

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_API_TOKEN")

run_input = {
    "watchKeywords": ["nike", "adidas"],
    "watchMode": "only",
    "watchCountry": "US",
    "newOnly": True,
    "alertMemoryKey": "nike-us-hourly",
}

run = client.actor("<YOUR_USERNAME>/twitter-trends-scraper-watch-your-brand-keywords").call(
    run_input=run_input
)

rows = []
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item.get("type") == "trend":
        rows.append(item)

for row in rows:
    print(f"{row['trend']} (rank {row['rank']}) matched {row['matchedKeyword']}")

Node.js

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: "YOUR_APIFY_API_TOKEN" });

const run = await client.actor("<YOUR_USERNAME>/twitter-trends-scraper-watch-your-brand-keywords").call({
  watchKeywords: ["nike", "adidas"],
  watchMode: "only",
  watchCountry: "US",
  newOnly: true,
  alertMemoryKey: "nike-us-hourly",
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();

items
  .filter((row) => row.type === "trend")
  .forEach((row) => console.log(`${row.trend} (rank ${row.rank})`));

Async and scheduled pipelines

For a fire-and-forget large job, start the run with client.actor(...).start() instead of .call() and poll client.run(runId).get() for status, or configure a webhook on the Actor's run-succeeded event from the Apify Console to notify your endpoint when the dataset is ready. For recurring brand monitoring, an Apify Schedule (cron-based, configured in the Console) is the standard pattern — combine it with newOnly: true so each scheduled run only returns the delta.

Who Needs This Twitter Trends Scraper? (Use Cases & Industries)

🏢 Brand and PR teams

A brand or PR team sets watchKeywords to the company name, product lines, and any live campaign hashtag, schedules the run hourly with watchMode: "only" and newOnly: true, and routes the resulting rows — matchedKeyword, rank, trendUrl — into whatever alerting channel the team already uses, so a spike in mentions of a product name is caught within the hour it appears on the board.

📊 SEO and content strategy teams

Content teams use trend and trendType from the Worldwide or a target-market board to spot which topics and hashtags are actively climbing right now, informing what to publish or promote same-day rather than reacting to yesterday's news cycle.

📱 Competitive intelligence teams

Setting the watch list to competitor names with watchMode: "flag" keeps the whole board for context while tagging every row where a competitor term appears, letting an analyst track a competitor's rank across scheduled runs to see whether their visibility on the board is rising or falling.

🔬 Researchers

Academic and market researchers use alsoCheckHoursAgo plus a recurring schedule across one or more markets to build an hour-resolution dataset of trending-topic lifecycles — how quickly a topic climbs, peaks, and falls off a public board — using only publicly published data.

Is it legal to scrape Twitter/X trending topics?

Scraping publicly accessible web pages is generally lawful in the United States — the Ninth Circuit's ruling in hiQ Labs v. LinkedIn (9th Cir. 2019) held that scraping data a website makes publicly available, without bypassing any access control, does not violate the Computer Fraud and Abuse Act. This actor reads the public getdaytrends.com trends board, which requires no login and mirrors X/Twitter's own public trending-topics feed; no account credential or authentication wall is bypassed.

Separately, a website's Terms of Service may prohibit automated access; violating a ToS is a potential civil contract matter between the site operator and the scraper, not a criminal one, and its enforceability varies by jurisdiction and by what the ToS actually says.

This actor does not return personal data — trend names, ranks, and hashtags are aggregate public signals, not information about identifiable individuals — so data-protection frameworks like the GDPR or CCPA, which govern personal data, do not apply to this actor's output. Twitter Trends Scraper - Brand & Keyword Monitoring returns only publicly accessible data. What you do with that data is your responsibility — consult legal counsel for commercial applications.

❓ Frequently asked questions

Does this Twitter trends scraper work without an X/Twitter account?

Yes. It reads the public getdaytrends.com board directly — no X/Twitter login, cookies, or API key is required, and none of the actor's 18 input parameters accept a credential of any kind.

How does it handle anti-scraping measures?

A 200 response with no trend table on the page is treated as a soft block, not a successful fetch, and is retried. Every request retries up to maxRetries times (default 3) with exponential backoff plus jitter (roughly 1s, 2s, 4s, capped at 8s) before recording an uncharged error row. Proxy is optional and off by default since the source site does not require one; if you enable it and the selected proxy fails its connectivity check, the actor automatically falls back to Apify RESIDENTIAL, then to no proxy at all.

Can I run it at scale without getting blocked?

There is no published uptime or block-rate figure for this actor. What is documented in the source: retries with backoff on transient failures, an automatic proxy fallback chain if you opt into a proxy, and uncharged accounting rows (rather than a silent charge) whenever a slice genuinely fails.

How fresh is the data?

Live — every run fetches the current board from getdaytrends.com at request time; nothing is served from a cache. alsoCheckHoursAgo adds hourly rewinds of the same live-fetched board, up to 23 hours back. The source site's dated archive (yesterday, week/month/year-ago views) currently returns HTTP 520 upstream and is not retrievable through this actor at all — those legacy toggles are accepted but produce an uncharged accounting row explaining why.

Which fields work best for AI training and RAG indexing?

trend is the high-information text field — the actual trending phrase or hashtag. For RAG, pair it with locationName and snapshotTimeUtc to ground an answer in a specific market and hour, citing back to sourceUrl. For training or classification data, trendType, isHashtag, and rank are typed and consistently populated across every row and market, requiring no cleanup before use.

Does it work with Claude, ChatGPT, and other AI agent tools?

There is no MCP server for this actor. It is callable as a standard Apify Actor run by any agent framework capable of an HTTP request or the apify-client SDK — every response is typed JSON, ready to drop into an LLM context window without a parsing step.

How does this compare to other Twitter/X and trend scrapers?

As observed on their Apify Store listings (data snapshot 2026-07-08): crawlerbros/twitter-keywords-scraper returns individual tweet text and engagement metrics for a search term, but requires your own X/Twitter session cookies and does not document cross-run new-trend detection. vnx0/google-trends-scraper covers a different platform (Google's "Trending Now" feed, not X/Twitter) with up to 90 days of historical backfill. This actor is the one built specifically for the X/Twitter trending-topics board, with keyword watch-listing and persistent cross-run alerting built in — it does not return individual tweet content or engagement counts.

What happens if my watch list matches nothing?

The run still returns a non-empty, auditable dataset. If the board was fetched successfully but zero trends survived your active filters (watch list, trendType, or newOnly), the actor pushes a single uncharged type: "notice" row with errorReason: "no_rows_after_filters" and an errorDetail string naming exactly which filters were active and how many trends were parsed before filtering — so an empty result reads as "nothing matched," not "something broke."

ℹ️ Disclaimer

Twitter Trends Scraper - Brand & Keyword Monitoring extracts only publicly available data from the getdaytrends.com trends board. This tool is intended for lawful use cases only. Users are responsible for complying with the source site's terms of service and applicable data protection laws in their jurisdiction.