Twitter Trends Scraper & Country List Per Trend

Twitter Trends Scraper — Trends, Country Ranks and History as JSON

Twitter Trends Scraper & Country List Per Trend reads the X/Twitter trending board from getdaytrends.com for any of 62 markets, then opens every trend's own page to pull its live cross-country footprint — the countries it is trending in right now, each with its rank there, plus the countries it trended in earlier. Every row is typed, normalized JSON — a trend row, a live-country-rank row, and a historical-trend row — no HTML, no selectors, no parsing required before you use it. Point it at a market, choose how deep the cross-country lookup goes, and get back which trends are a local blip and which are a genuinely global story.

⚠️ How the cross-country "also trending" footprint is actually built

Worth stating plainly, because it is the whole point of this Actor and it is easy to assume something more exotic is happening.

For every board trend the Actor expands, it makes one additional HTTP request: a plain GET to that exact trend's own worldwide page on getdaytrends.com (https://getdaytrends.com/trend/<slug>/). That page renders an "in Other Locations" list — every country/region where that same trend term is either trending right now or has trended before. The Actor is not comparing related or co-occurring terms, and it is not consulting a lookup table: it re-reads getdaytrends' own per-country boards for the identical trend name and classifies each location by the text in its details cell:

• "#13 now" → the trend is live in that location, currently ranked 13 there
• "6 hours ago" → the trend trended recently there, last seen 6 hours before the snapshot
• "Feb 24, 2026 15:00" → the trend trended there at that absolute past timestamp

Board links only carry the country-scoped trend URL (/united-states/trend/<slug>/), which the source code documents as dead upstream (worldwide_trend_url() in src/main.py, measured 0/8 → HTTP 520). The Actor rewrites every trend link to the worldwide form before fetching it, which is what makes the footprint request work at all.

A few mechanics that change what you actually get back:

• Requests are deduplicated per run. If the same trend URL turns up on more than one board window or start URL, the footprint page is fetched once and reused from an in-memory cache for the rest of the run.
• Only main-board trends are expanded, never the sidebar "panel" trends (see sourcePanel below) — even if maxTrendsToExpand still has budget left.
• footprintTopN caps two different things differently. On the trend row's nested arrays, the cap is applied separately — up to footprintTopN live locations and up to footprintTopN recent/past locations. On the flat footprintLocation child rows (when emitFootprintRows is on), the same cap is applied once, to the live-then-recent-then-past list combined. With a lot of live countries and footprintMode: liveAndRecent, the flat child rows can therefore show fewer historical countries than the nested recentlyTrendedIn array on the very same trend row.
• "Worldwide" is a pseudo-location, not a country. getdaytrends lists an aggregate "Worldwide" row inside the same footprint list. It can appear inside alsoTrendingIn, but it is excluded from globalReach, liveCountryCount and isGlobalStory — those are country counts only.
• A trend that fails its own footprint fetch is not dropped. The board row is still pushed with footprintStatusReason set to a typed reason (NO_FOOTPRINT_TABLE, HTTP_520, TIMEOUT, …) instead of "OK", and the nested/child footprint fields stay null.

What is Twitter Trends Scraper & Country List Per Trend?

It is an Apify Actor that reads the X/Twitter trending board hosted by getdaytrends.com — a public, cookieless mirror of X's trends, not X's own private API — and returns two linked things per trend: the board entry itself, and its cross-country footprint. No X/Twitter account, login, cookie or developer key is required for either step.

• Scrape the trending board — up to 50 board trends plus any sidebar panel trends, for Worldwide or 62 individual markets
• Scrape each trend's live country footprint — every country it is trending in right now, with its rank there
• Scrape each trend's historical footprint — every country it trended in before, with a timestamp
• Read the board as it stands now, or as it stood 1–23 hours ago, in the same run
• Export as JSON, CSV or Excel, or read the dataset straight through the Apify API — no proxy management, no HTML parsing

What data does Twitter Trends Scraper & Country List Per Trend collect?

Three linked entity types come out of the same run: the board trend itself, its live cross-country presence, and its historical cross-country presence.

Data Type	Key Fields	JSON Field Names
Board trend	Trend name, board rank, which panel it came from, hashtag flag, its own worldwide page URL	trend, rank, sourcePanel, isHashtag, trendUrl, snapshotTimeUtc
Live country presence	The countries the trend is trending in right now, its rank in each, and the aggregate reach score	alsoTrendingIn, globalReach, liveCountryCount, topCountryRank, bestRankCountry, isGlobalStory, isTrendingWorldwide
Historical country presence	The countries the trend trended in before, and when it last did so there	recentlyTrendedIn, recentCountryCount, footprintSampleSize

footprintLocation rows (the flat, one-row-per-trend-per-country form) carry the same underlying data as alsoTrendingIn / recentlyTrendedIn above — see Output below for the exact field lists of both representations.

Need more Twitter/X data?

This Actor is trend- and reach-focused, not post- or profile-focused. If you also need the tweets themselves, pair it with Twitter X Posts Scraper (Media & Link Extraction) for post content and media, Twitter (X) Reply Scraper — Verified & Engagement Filter for reply-level engagement data, or X (Twitter) Posts Search & Post Replies for keyword-driven post search. All four sit in the same account, so field naming and output style stay consistent across a pipeline that combines trend discovery with post-level detail.

How does Twitter Trends Scraper differ from the official X API?

X's own trends surface sits behind the X API's developer programme — you register an app, and the trends-by-location endpoints are gated by the API access tier your account holds, per X's own developer documentation. This Actor instead reads getdaytrends.com's public, already-rendered trending board, so no X account, app registration or approval step is involved.

Feature	X API (official)	Twitter Trends Scraper & Country List Per Trend
Access	Developer account, registered app, API tier that includes trends endpoints	✅ Apify account, press Start
Data source	X's own backend trends index	getdaytrends.com's public trending board, a third-party mirror of the same trending topics
Cross-country footprint per trend	Not a built-in concept — one call returns one location's list; joining a trend across many locations is work you do yourself, call by call	✅ Built into every trend row via alsoTrendingIn / recentlyTrendedIn, from up to maxTrendsToExpand extra page reads
"Trended before" history	Not exposed by the trends endpoints	✅ liveAndRecent mode returns the country and the timestamp a trend last trended there, as far back as getdaytrends still shows it
Rate and quota terms	Set by your API tier, published in X's developer documentation	No request-rate limit imposed by the Actor itself; maxRetries (0–10) and requestTimeoutSecs (5–180) govern retry and backoff behaviour
Output shape	X's versioned, documented response schema	One flat, stable-key row schema per entity type, documented below

Use the official X API when your product has a direct contractual or compliance need to source trends from X itself. Use this Actor when you want a country-by-country trend footprint today, without an approval process standing between you and the data.

Why do developers and teams scrape Twitter/X trends?

Trending-topic data is time-sensitive and inherently comparative — its value is in knowing what's moving and where, which is why the audiences below care about the cross-country footprint specifically, not just the board.

For AI engineers and agent builders

A trend-aware agent needs to distinguish signal from noise before it acts — a hashtag that is a genuine worldwide story (isGlobalStory: true, globalReach in double digits) is worth a different response than a single-country blip. Feed trend, globalReach, bestRankCountry and alsoTrendingIn straight into an agent's tool context or a vector store; the field names never change between runs, so no parsing step sits between the fetch and the model call.

For marketers, PR and newsroom teams

Before committing a campaign or a reporter to a story, you need to know if it is local or global. Run the Worldwide board with footprintMode: liveOnly, sort by globalReach, and bestRankCountry tells you which market is driving it. Because alsoTrendingIn carries the live rank per country, you can time regional pushes to markets where a trend is still climbing rather than one where it already peaked.

For researchers and analysts

recentlyTrendedIn with its lastTrendedAt and hoursSinceTrending fields gives a lightweight longitudinal signal for how a topic's geographic footprint changes over time, without touching any gated or personal data — every field here is public, aggregate trend metadata. Schedule the Actor hourly against boardWindows and diff liveCountryCount per trend across runs to study diffusion speed.

For developers building trend-history data products

footprintLocation child rows are built for exactly this — one row per trend per country, ready to load into a warehouse table without reshaping. Combined with the mirrored per-run dataset (footprint-<runId>, created automatically whenever emitFootprintRows is on), you get both a normalized event stream for a live dashboard and a clean, isolated batch per run for backfills.

How to scrape Twitter/X trends (step by step)

This Actor runs on Apify. Start it from the Apify Console, or call it through the Apify API with your Apify token.

1. Open Twitter Trends Scraper & Country List Per Trend on the Apify Store and click Try for free
2. Leave 📍 Starting market (market) on Worldwide, or pick one of the 62 supported markets — no input is required at all to run it with defaults
3. Set 🌐 Footprint depth (footprintMode) and 🔢 How many trends to expand (maxTrendsToExpand) to control how deep the cross-country lookup goes
4. Click Start
5. Download results as JSON, CSV or Excel, or read the dataset through the Apify API / apify-client

What to do when getdaytrends changes its structure

Nothing on your side. The Actor is maintained, and the output schema — field names and types — stays stable across upstream layout changes, so integrations built on trend, alsoTrendingIn and the other fields documented below keep working without you re-mapping anything. No numeric turnaround time is published; check the Actor's build log if you suspect an upstream change has broken a run.

⬇️ Input

Eleven parameters, all optional — the Actor runs with zero input, reading the Worldwide board with footprintMode: liveOnly. Read directly from .actor/actor.json.

Parameter	Required	Type	Description	Example Value
footprintMode	No	string (enum)	Controls the cross-country lookup depth for every board trend. liveOnly returns only the countries a trend is trending in right now, each with its rank there. liveAndRecent adds the countries it trended in earlier, with the timestamp it last trended there. off skips the extra requests entirely — board only. An unrecognized value falls back to liveOnly with a logged warning. Enum: liveOnly, liveAndRecent, off. Default: liveOnly.	"liveOnly"
maxTrendsToExpand	No	integer	Caps how many board trends — parents, not the location rows they produce — get a footprint lookup, in board order. Each expanded trend costs one extra page request. 0 expands every trend on the board (up to 50 extra requests). Minimum 0, maximum 50, default 10.	10
footprintTopN	No	integer	Caps how many locations are kept per trend footprint list, in getdaytrends' own relevance order. 0 removes the cap. Minimum 0, maximum 100, default 25. Applied separately to live vs. recent/past on the nested trend-row arrays, but as one combined cap on the flat footprintLocation rows — see the ⚠️ section above.	25
emitFootprintRows	No	boolean	When true, every footprint location is also written as its own flat row (type: "footprintLocation", isChild: true), mirrored into a second per-run dataset named footprint-<runId>. When false, the footprint exists only as the nested alsoTrendingIn / recentlyTrendedIn arrays on the trend row. Default: true.	true
market	No	string (enum: "" + 62 ISO country codes)	The board to read first. "" (default) reads the Worldwide board. If the legacy country field below is also set and non-empty, country wins so existing input files keep working.	"US"
boardWindows	No	array of strings	Which board snapshots to scrape. "live" for the board right now, or a string "1"–"23" for the board as it stood that many hours ago — e.g. ["live", "1", "6"] reads three full snapshots, each independently footprinted. Values outside that set are silently dropped. Legacy boolean keys (live, hour1 … hour23), if present in the input, take priority over this field entirely. Default: ["live"].	["live", "6"]
startUrls	No	array	Scrape specific getdaytrends.com URLs directly, in addition to or instead of the board. Supports {today}, {yesterday} and {day3} placeholders. Each entry runs a full board-parse + footprint pass labelled timePeriod: "Custom". No default (empty).	["https://getdaytrends.com/japan/3/"]
maxRetries	No	integer	How many times to retry a failed page fetch — with exponential backoff plus jitter — before giving up and recording an uncharged error row with a typed reason. A 404 or 410 response is treated as permanent and is never retried. Minimum 0, maximum 10, default 3.	3
requestTimeoutSecs	No	integer	Per-request timeout in seconds, applied to every board fetch, every trend-footprint fetch, and the proxy connectivity test. Minimum 5, maximum 180, default 30.	30
country	No	string (free text)	Backward-compatible alias for market, kept so input files written for the original scraper still run unchanged. When both are set, country silently wins. Leave empty to use market. No default.	""
proxy	No	object (Apify proxy configuration)	Defaults to no proxy — getdaytrends.com serves Apify's datacenter IP ranges directly, so nothing is needed or billed. If a configured proxy fails its connectivity check, the Actor falls back to Apify RESIDENTIAL, then to a direct connection. Default: {"useApifyProxy": false}.	{"useApifyProxy": false}

The base proxyConfiguration key is also accepted as an alias for proxy, for input files carried over from the original scraper.

Example input (every field shown explicitly):

{
  "footprintMode": "liveAndRecent",
  "maxTrendsToExpand": 15,
  "footprintTopN": 20,
  "emitFootprintRows": true,
  "market": "US",
  "boardWindows": ["live", "6"],
  "startUrls": [],
  "maxRetries": 3,
  "requestTimeoutSecs": 30,
  "country": "",
  "proxy": { "useApifyProxy": false }
}

Common pitfall: leaving footprintMode set to "off" while emitFootprintRows stays true doesn't error — it just silently returns board rows with no footprint data at all, because a footprintLocation row can only ever be produced from a footprint lookup that actually ran.

⬆️ Output

Every row is typed, normalized JSON pushed live to the default dataset as the run progresses. Export as JSON, CSV, Excel, or read it through the Apify API. Four distinct row shapes can appear in the same dataset, distinguished by type and isChild — the default dataset view shown in the Apify Console (30 columns) is a flattened subset built for the table UI; the fields below are everything the Actor actually writes, taken from the row-building code in src/main.py.

Board trend row (type: "trend") — the charged unit

{
  "type": "trend",
  "isChild": false,
  "time": "2026-07-25T14:00:00Z",
  "timePeriod": "Live",
  "trend": "#MondayMotivation",
  "rank": 3,
  "sourcePanel": "Trending board",
  "market": null,
  "marketName": "Worldwide",
  "snapshotTimeUtc": "2026-07-25T14:00:00Z",
  "isHashtag": true,
  "trendUrl": "https://getdaytrends.com/trend/MondayMotivation/",
  "panelDetail": null,
  "globalReach": 3,
  "liveCountryCount": 3,
  "recentCountryCount": 2,
  "isTrendingWorldwide": false,
  "isGlobalStory": false,
  "topCountryRank": 2,
  "bestRankCountry": "United States",
  "alsoTrendingIn": [
    { "location": "United States", "countryCode": "US", "rank": 2 },
    { "location": "Brazil", "countryCode": "BR", "rank": 5 },
    { "location": "India", "countryCode": "IN", "rank": 9 }
  ],
  "recentlyTrendedIn": [
    { "location": "Japan", "countryCode": "JP", "lastTrendedAt": "2026-07-25T08:00:00Z", "hoursSinceTrending": 6 },
    { "location": "Germany", "countryCode": "DE", "lastTrendedAt": "2026-02-24T15:00:00Z", "hoursSinceTrending": 3720 }
  ],
  "footprintSampleSize": 5,
  "footprintStatusReason": "OK",
  "scrapedAt": "2026-07-25T14:00:07Z"
}

market carries the ISO code you requested (null on the Worldwide board). sourcePanel is "Trending board" for the main 50-row board or the sidebar panel's own heading (e.g. a "Trending in News" box) for panel trends — only "Trending board" rows are eligible for footprint expansion. footprintStatusReason is "OK" on a successful lookup, a typed failure string (NO_FOOTPRINT_TABLE, HTTP_520, TIMEOUT, FETCH_FAILED, REQUEST_ERROR:<name>) on a failed one, or null when no lookup was attempted at all (footprint off, a panel row, or the maxTrendsToExpand budget was already spent). recentlyTrendedIn is only populated in liveAndRecent mode; it stays null in liveOnly and off.

Live country presence row (type: "footprintLocation", footprintStatus: "live") — uncharged

{
  "type": "footprintLocation",
  "isChild": true,
  "time": "2026-07-25T14:00:00Z",
  "timePeriod": "Live",
  "trend": "#MondayMotivation",
  "parentTrend": "#MondayMotivation",
  "parentRank": 3,
  "market": null,
  "marketName": "Worldwide",
  "location": "United States",
  "locationCountryCode": "US",
  "locationSlug": "united-states",
  "footprintStatus": "live",
  "locationRank": 2,
  "lastTrendedAt": "2026-07-25T14:00:00Z",
  "hoursSinceTrending": 0,
  "trendUrl": "https://getdaytrends.com/trend/MondayMotivation/",
  "scrapedAt": "2026-07-25T14:00:07Z"
}

Historical country presence row (type: "footprintLocation", footprintStatus: "recent" or "past") — uncharged

{
  "type": "footprintLocation",
  "isChild": true,
  "time": "2026-07-25T14:00:00Z",
  "timePeriod": "Live",
  "trend": "#MondayMotivation",
  "parentTrend": "#MondayMotivation",
  "parentRank": 3,
  "market": null,
  "marketName": "Worldwide",
  "location": "Japan",
  "locationCountryCode": "JP",
  "locationSlug": "japan",
  "footprintStatus": "recent",
  "locationRank": null,
  "lastTrendedAt": "2026-07-25T08:00:00Z",
  "hoursSinceTrending": 6,
  "trendUrl": "https://getdaytrends.com/trend/MondayMotivation/",
  "scrapedAt": "2026-07-25T14:00:07Z"
}

footprintStatus: "past" uses the same shape with an absolute lastTrendedAt timestamp instead of a relative one. A location whose details cell matches none of the three known formats is written with footprintStatus: "unknown" and locationRank / lastTrendedAt / hoursSinceTrending all null, rather than being dropped silently.

Failed-fetch diagnostic row (type: "error") — uncharged

{
  "type": "error",
  "isChild": false,
  "time": "2026-07-25T14:00:00Z",
  "timePeriod": "6 hours ago",
  "trend": null,
  "market": "FR",
  "marketName": "France",
  "sourceUrl": "https://getdaytrends.com/france/6/",
  "errorReason": "HTTP_520",
  "scrapedAt": "2026-07-25T14:00:11Z"
}

Pushed only for a board fetch that exhausted maxRetries (errorReason is an HTTP status code, TIMEOUT, a REQUEST_ERROR:<name>, or NO_TREND_ROWS when the page loaded but no board rows parsed). Note this row's URL field is named sourceUrl, not trendUrl — a genuine naming inconsistency versus every other row type, worth knowing if you're mapping by field name across row types.

What's charged, what isn't. This Actor is pay-per-event. Every board trend row (type: "trend", including sidebar panel trends, which are never footprint-eligible but are still counted) is pushed with the row_result charged event. Every footprintLocation child row and every error diagnostic row is pushed uncharged. To see only the billed rows in the dataset, filter on "type": "trend".

How does Twitter Trends Scraper compare to other Twitter/X trends scrapers?

Feature	This Actor	Generic alternative
Cross-country footprint per trend	✅ Built into every trend row — alsoTrendingIn with a live rank per country	maged120/twitter-trends' listing (checked on the Apify Store, 2026-07-25) documents country-specific trend output, but does not document a cross-country footprint field on a single row
Historical "trended before" data with a timestamp	✅ recentlyTrendedIn with lastTrendedAt / hoursSinceTrending per location	Not documented on any of the three competing listings checked 2026-07-25
Tweet-volume field	Deliberately not returned — see limitations below	maged120/twitter-trends and practicaltools/twitterTrendsAPI both list a volume-style field (tweetVolume / tweet_volume) on their listings, checked 2026-07-25
Row granularity	One row per trend, plus one row per trend × country when the footprint is on	Competitor listings (all three, checked 2026-07-25) document one row per trend only
Access requirement	No X login, no API key, no proxy required by default	patient_discovery/twitter-trends-by-location's listing advertises a "cookieless architecture", checked on the Apify Store 2026-07-25 — not independently measured here

If you're building an AI agent or RAG pipeline, the row-granularity line is the decision-maker — parsing HTML or re-requesting a trend's page yourself inside an agent loop is a reliability failure mode, not a feature, and this Actor's alsoTrendingIn / footprintLocation output removes that step entirely.

One documented limitation, stated up front: this Actor never returns a volume field. The base scraper it extends did, but that field was measured 0% reliably populated at source and actively wrong on 19 of 70 sampled rows — it emitted the trend name as the volume. Rather than ship a field that lies some of the time, it was removed. If your workflow needs an engagement-volume number, treat that as a known gap, not an oversight.

How many results can you scrape with Twitter Trends Scraper?

There is no hard row cap enforced by the Actor itself. Total volume is the product of board size, snapshot count, and footprint depth, all of which you control:

• Each board snapshot lists the main 50-trend board (verified 50/50 across four countries in the parsing logic) plus a variable, market-dependent number of additional sidebar panel trends — all of these are returned and charged.
• boardWindows controls how many snapshots are read in one run: "live" plus any of "1"–"23" — up to 24 independent full board+footprint passes if you list them all.
• maxTrendsToExpand (0–50, default 10) caps how many trends per snapshot get a footprint lookup; the rest of the board is still returned, just without a footprint. Set it to 0 to expand every board trend.
• footprintTopN (0–100, default 25) caps how many locations are kept per trend's footprint list, so a viral trend with dozens of live countries doesn't balloon a single row.
• With emitFootprintRows on, each kept location also becomes its own uncharged footprintLocation row — these are additional to, not counted against, any of the caps above.

No benchmark run time or throughput figure is published here, because none has been measured for this specific configuration space.

Integrate Twitter Trends Scraper and automate your workflow

Twitter Trends Scraper & Country List Per Trend works with any language or tool that can send an HTTP request, through the standard Apify API.

REST API integration

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/twitter-trends-scraper-where-each-trend-is-also-trending").call(
    run_input={
        "footprintMode": "liveOnly",
        "maxTrendsToExpand": 10,
        "market": "US",
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item["type"] == "trend":
        print(item["trend"], item["globalReach"], item["bestRankCountry"])

Works in Python, Node.js, Go, Ruby, cURL — anything that can call the Apify API with your token.

Automation platforms (n8n, Make)

In n8n, the native Apify node lets you select this Actor and its input fields become node parameters directly — chain a Schedule Trigger into the Apify node to run it hourly against boardWindows, then branch on isGlobalStory downstream. In Make, the Apify app module works the same way: run the Actor, then map dataset items into a Google Sheets or Slack module keyed on trend and globalReach for trend-alerting automations.

Is it legal to scrape Twitter/X trending topics?

Yes. This Actor returns only publicly available trend data — trend names, board rank, and aggregate cross-country presence — rendered on getdaytrends.com's public pages without any login. Trending-topic names and country counts are business/aggregate metadata, not personal data about an identifiable individual, so this sits under general terms-of-service and database-rights considerations rather than GDPR or CCPA, which govern personal data specifically. You are responsible for reviewing getdaytrends.com's and X's own terms of service for your intended use, particularly for high-volume or commercial redistribution. Consult legal counsel for commercial use cases at scale.

❓ Frequently asked questions

Does Twitter Trends Scraper work without an X/Twitter account?

Yes. It never logs into X or getdaytrends.com — no X account, developer key, cookie, or getdaytrends account is required for any part of the run, including the footprint lookup.

How often is the trend data updated?

Every run fetches the board and every footprint page live, with a cache-control: max-age=0 header on each request, so a "live" board window reflects getdaytrends' current state at request time — nothing is served from a stored cache. The hourly boardWindows values ("1"–"23") read getdaytrends' own historical snapshot for that many hours back, which is a different thing from a live fetch of the current board.

What happens when a trend's footprint page has no data, or a board fetch fails?

The board trend row is still returned. If the footprint page loads but has no "Other Locations" table, footprintStatusReason is set to NO_FOOTPRINT_TABLE and the footprint fields stay null. If the page fails outright after maxRetries attempts, you get a typed reason like HTTP_520 or TIMEOUT instead. If an entire board fetch fails or returns zero parsed trends, a separate uncharged type: "error" row is written with errorReason set (NO_TREND_ROWS when the page loaded but nothing matched), rather than the run silently producing fewer rows with no explanation.

Can I scrape private or restricted trend data?

No — and there isn't any to reach. Everything getdaytrends.com renders on its board and trend pages is already public with no login wall, and that is the entire surface this Actor reads.

What does it cost to run?

Pricing is pay-per-event: one row_result charge per board trend row (see ⬆️ Output above for exactly which rows those are). Footprint child rows and diagnostic error rows are never charged. Check the Actor's Apify Store pricing tab for current per-event pricing and any trial credit available on your account.

Does Twitter Trends Scraper work for AI agent workflows and LLM pipelines?

Yes. It's callable as a standard Apify Actor run from any HTTP client or agent framework — there's no separate integration layer to install. Every dataset item is typed JSON with stable field names, so an agent can consume alsoTrendingIn, globalReach and the rest directly, with no HTML or selector parsing between the fetch and the model call.

How does Twitter Trends Scraper handle anti-bot defenses?

It sends a real Chrome-on-Linux User-Agent matched to the container's actual OS, plus the matching sec-ch-ua client-hint headers — mismatching a spoofed Windows UA from a Linux container is a known signal WAFs flag. Failed requests retry with exponential backoff plus random jitter (up to maxRetries times, 404/410 excluded as permanent), and a proxy is only used if you configure one — getdaytrends.com serves Apify's datacenter IP ranges directly by default, with automatic fallback to Apify RESIDENTIAL if a configured proxy fails its connectivity check.

How does Twitter Trends Scraper compare to other Twitter/X trends scrapers?

See the comparison table above. The short version, based on the three closest listings on the Apify Store (checked 2026-07-25): none of them documents a cross-country footprint or trended-before history attached to a single trend row — that combination is this Actor's differentiator.

Does Twitter Trends Scraper return data in a format LLMs can use directly?

Yes. Every row — trend, live location, historical location, or diagnostic — is typed, normalized JSON with fixed field names across every run. Pass it straight into an LLM's context window, index it into a vector store, or route it through an agent tool without a transformation step.

Can I use Twitter Trends Scraper without managing proxies?

Yes. The default configuration (proxy: {"useApifyProxy": false}) uses no proxy at all, because getdaytrends.com serves Apify's own datacenter IP ranges directly. You can still supply Apify proxy groups or your own proxy URLs if you want to, and the Actor falls back automatically if a configured proxy fails.

What happens if getdaytrends changes its structure or blocks the scraper?

The Actor is maintained, and its output schema is designed to stay stable — the field names and types documented above don't change on your end even when the underlying page markup does. No specific turnaround time is published for a fix after a breaking upstream change.

💬 Your feedback

Found a bug, a field that's off, or a market that isn't behaving the way this README describes? We want to know — report it through the Actor's Issues tab on Apify, or reach out through API Empire's support channel on the Apify Store. Bug reports and missing-field requests are how this Actor's output schema stays accurate.