Twitter Trends Scraper With Rank History & Staying Power avatar

Twitter Trends Scraper With Rank History & Staying Power

Pricing

Pay per usage

Go to Apify Store
Twitter Trends Scraper With Rank History & Staying Power

Twitter Trends Scraper With Rank History & Staying Power

Track and analyze Twitter trends with the Twitter Trends Scraper. Extract trending hashtags, topics, tweet volumes, and timestamps from any location. Ideal for social media monitoring, market research, and content strategy. Fast, reliable, and scalable for global or local trend tracking.

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Scrapier

Scrapier

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

0

Monthly active users

5 days ago

Last modified

Share

Twitter Trends Scraper With Rank History & Staying Power reads the public getdaytrends.com trending board for 62 countries plus the worldwide feed and returns every trend as typed JSON: board rank, an 8-hour rankHistory sparkline, peakRank, rankDelta1h, movement, and staying-power metrics (hoursOnBoard, firstSeenUtc, lastSeenUtc, snapshotsObserved) built from a second source's ~18-hour snapshot timeline. Every row is structured JSON, ready to pass directly to an LLM, index into a vector store, or feed a monitoring pipeline. No X/Twitter login, API key or cookie is required to run it.

It is an Apify Actor that scrapes the getdaytrends.com trending-topics board — 50 ranked trends per market, plus two 10-row sidebar panels — and enriches every row with two things a plain trends list cannot give you: where the trend has been (an hourly rank sparkline decoded from the board's own SVG chart) and how long it has stuck around (a staying-power timeline joined from a second source, trends24.in). No account, login or cookie is used against either source; both are scraped logged out.

  • Reads the live board for any of 62 countries, or the worldwide board
  • Decodes each trend's 8-hour rank history from the board's own sparkline — zero extra requests
  • Joins a ~25-snapshot, ~18-hour staying-power timeline per trend — one extra request per run
  • Filters rows on derived movement (new / rising / falling / steady)
  • Filters rows on minimum hours already spent on the board
  • Toggles whether the two sidebar panels (top-by-score, longest-trending) are included alongside the clean 50-row board

The Actor returns three kinds of rows in one dataset: board trends carrying full rank history and staying power, sidebar-panel trends carrying the same metrics plus a panel label, and uncharged accounting rows when a source page cannot be read.

Result TypeExtracted FieldsPrimary Use Case
Board trend rowtrend, rank, rankHistory, sparklineHours, peakRank, peakAtUtc, rankDelta1h, movement, hoursOnBoard, hoursOnBoardIsMinimum, firstSeenUtc, lastSeenUtc, bestRankInWindow, snapshotsObserved, isNewInWindowTrack a trend's momentum and durability, not just its current position
Sidebar panel rowSame fields plus sourcePanel (top_by_score / longest_trending), panelDetail, isBoardRow: falseSurface trends the 50-row board misses — highest-scoring and longest-running
Uncharged accounting rowtimePeriod, errorReason, errorDetail, trend: nullSee exactly why a slice returned no rows, without paying for it

Rank history & staying power

This is what the other Twitter trends scrapers on the store do not return: a per-trend timeline instead of a single frozen count. rankHistory is decoded straight out of the board's <polyline> sparkline markup — each point is {hoursAgo, atUtc, rank}, built without any extra HTTP request because the base page already ships this data and every other trends scraper discards it. peakRank / peakAtUtc mark the best position in that window, rankDelta1h is the position change versus one hour ago (positive means it climbed), and movement classifies the trend as new, rising, falling or steady. Staying power comes from a second source, trends24.in, joined by normalized trend name across roughly 25 board snapshots spanning about 18 hours: hoursOnBoard, firstSeenUtc, lastSeenUtc, bestRankInWindow and snapshotsObserved (the sample-size denominator for every other metric).

{
"trend": "#PerthSantaConcertD2",
"rankHistory": [{ "hoursAgo": 0, "atUtc": "2026-07-25T08:00:00Z", "rank": 1 }],
"movement": "rising",
"hoursOnBoard": 3.41,
"snapshotsObserved": 6
}

Alongside the 50-row board, getdaytrends.com renders two 10-row sidebar panels: "top by score" and "longest trending." boardPanels controls whether these are included; when they are, each row is labelled sourcePanel: "top_by_score" or "longest_trending", with isBoardRow: false and panelDetail carrying the panel's own display text. This matters when the trend that matters to you never cracks the top-50 board but is already flagged by the source site itself as unusually durable.

Why not build this yourself?

getdaytrends.com does not publish an API — the board data is rendered HTML, and the rank-history sparkline is a raw SVG <polyline> whose coordinates have to be reverse-engineered against the chart's viewBox to recover hourly rank. Get the coordinate math wrong and every history point is silently off by an hour. trends24.in has no API either; building staying power means fetching its snapshot page, parsing roughly 25 timestamped <ol> blocks, and joining ~50 trends per snapshot to the board by normalized name — get the name normalization wrong (case, leading #, whitespace) and trends silently fail to join, understating hoursOnBoard for everything.

Both sources also carry dead surface area that looks live until you actually probe it: six legacy date-archive URLs (yesterday, day2, day3, weekAgo, monthAgo, yearAgo) return HTTP 520 on every attempt. A DIY scraper either doesn't know this and burns retries on a page that will never return 200, or has to discover it by trial and error. This Actor already made that call — those toggles are still accepted for compatibility, but they short-circuit into an uncharged accounting row instead of retrying a page that is permanently gone.

A trends list answers "what's trending right now" — a name and a position, refreshed each time you run it. A trend rank-history tracker answers "is this still trending, and for how long" — the same name, but with its trajectory attached. The distinction matters because a single position tells you nothing about direction: rank 8 could be a story that just broke, or one that already peaked at rank 1 and is fading. Twitter Trends Scraper With Rank History & Staying Power returns both in the same row — the current board position in rank, and its trajectory in rankHistory, movement and the staying-power block — so you don't need to run the scraper twice and diff the results yourself just to know which #8 you're looking at.

⚠️ What this scraper deliberately does not return

This Actor omits fields it cannot reliably fill rather than ship an empty or misleading column:

  • No tweet-volume or tweet-count field. The base scraper this Actor extends carried a volume field that was effectively unpopulated, and on a portion of rows its fallback selector emitted the trend's own name as the volume value instead of a number. Rather than reproduce that, volume is not part of this Actor's output at all.
  • No historical date-archive results. getdaytrends.com's date-archive URLs — behind the legacy yesterday, day2, day3, weekAgo, monthAgo and yearAgo toggles — return HTTP 520 on every attempt. Those toggles are still accepted as input for compatibility with the base actor, but each one now produces a single uncharged accounting row (errorReason: "source_endpoint_dead") instead of retrying a page that will never come back.
  • hoursOnBoard can be a floor, not an exact figure. When hoursOnBoardIsMinimum is true, the trend was already present in the oldest snapshot inside the staying-power window, meaning it was very likely trending before the window opened. The true duration is at least hoursOnBoard, possibly more.
  • Every derived metric ships its own denominator. snapshotsObserved, timelineSnapshots, timelineWindowHours and sparklineHours travel alongside the numbers they support, so a hoursOnBoard built from 2 snapshots can be told apart from one built from 24 without cross-referencing anything else.
  • A page that cannot be fetched or parsed never becomes a fabricated or charged row. It produces a single uncharged accounting row with a typed errorReason, and the run continues with whatever targets remain.

How does the Actor handle blocking and rate limits?

Requests are sent with curl_cffi using Chrome TLS impersonation by default, which falls back to plain requests with a standard desktop Chrome-on-Linux header set if curl_cffi is unavailable in the run environment. The header set intentionally does not spoof a Windows user agent from inside Apify's Linux container — an OS/stack mismatch between the TLS fingerprint and the declared platform is the kind of inconsistency a WAF is built to catch.

Neither getdaytrends.com nor trends24.in requires a proxy from Apify to respond, so proxy defaults to no proxy ({"useApifyProxy": false}). If you do select an Apify proxy and it fails its own preflight check against the target, the Actor automatically falls back to Apify RESIDENTIAL rather than failing the run outright.

Failures are split into two kinds, handled differently. A transient failure — a network error, or a non-200/non-520/404/410 status — is retried up to maxRetries times with exponential backoff plus random jitter between attempts. A deterministic upstream failure — HTTP 520, 404 or 410 — is not retried at all: those statuses mean the resource is permanently gone or dead, so retrying only burns time and request quota. When a target is exhausted without success, the run does not fail; it emits one uncharged accounting row for that target, logs the reason, and moves on to the next one.

  1. Open Twitter Trends Scraper With Rank History & Staying Power on Apify and click Try for free
  2. Leave every input at its default for the current worldwide live board, or set market to a country code (e.g. "US") — no parameter is required
  3. Set the query controls you want: movementFilter to keep only rising/falling/new/steady trends, minHoursOnBoard to drop one-hour spikes, lookbackHours to shrink the history window, boardPanels to include or drop the two sidebar panels
  4. Click Start
  5. Download the dataset as JSON, CSV, Excel, XML or HTML, or stream it through the Apify API

How to run multiple hour slices or markets in one job

A single run scrapes one market. Within that run, hourSlices accepts an array of past-hour numbers (["1","6","12"]) to add extra historical board slices to the live one, and startUrls accepts a list of explicit getdaytrends.com board URLs to scrape alongside the selections above — both are processed in the same run. To cover more than one country, schedule the Actor once per market: market is a single-select input, not an array, so multi-country coverage means multiple runs (or Apify schedules), one per country code.

⬇️ Input

ParameterRequiredTypeDescriptionExample Value
lookbackHoursNointegerTrims both the hourly rankHistory (max 8h, read from the board sparkline) and the staying-power timeline (max 25h). Minimum 1, maximum 25. Default 8.8
movementFilterNostring (enum)Filters rows on the derived movement value: all, new, rising, falling, steady. Default all."rising"
minHoursOnBoardNointegerDrops trends trending for fewer than this many hours, measured across the staying-power timeline. 0 disables the filter. Needs includeStayingPower on. Minimum 0, maximum 25. Default 0.2
includeStayingPowerNobooleanAdds one extra request per run to build the staying-power timeline, filling hoursOnBoard, firstSeenUtc, lastSeenUtc, bestRankInWindow, snapshotsObserved, isNewInWindow. Off = fastest board-only run. Default true.true
marketNostring (enum)Country whose trending board is scraped. Empty string reads the worldwide board. The legacy base key country is still accepted and takes precedence when supplied."US"
boardPanelsNostring (enum)board-and-panels also returns the two sidebar panels (top-by-score, longest-trending), each labelled sourcePanel. board-only returns just the clean 50-row board. Default board-and-panels."board-only"
maxTrendsPerRunNointegerHard cap on charged result rows. 0 means no cap. Minimum 0. Default 0.50
liveNobooleanReads the current live trending board. On by default, and also switched on automatically when no hourly slice is selected. Default true.true
hourSlicesNoarray (stringList)Additional past-hour boards to scrape, as hour numbers 1–23. The base's individual hour1hour23 booleans are still accepted and merged in. Default [].["1","6","12"]
startUrlsNoarray (requestListSources)Optional explicit getdaytrends.com board URLs to scrape in addition to the selections above. Default [].[]
requestTimeoutSecsNointegerPer-request timeout in seconds. Minimum 5, maximum 300. Default 30.30
maxRetriesNointegerRetries on a transient network error or non-200 status. Deterministic upstream failures (520 / 404 / 410) are not retried. Minimum 0, maximum 10. Default 3.3
proxyNoobject (proxy)Apify Proxy configuration. Both source sites respond without a proxy from Apify, so no proxy is the default. If a selected proxy fails its preflight check, the Actor falls back to Apify RESIDENTIAL. Prefilled {"useApifyProxy": false}.{"useApifyProxy": false}

Example input

{
"market": "US",
"lookbackHours": 8,
"movementFilter": "rising",
"minHoursOnBoard": 2,
"includeStayingPower": true,
"boardPanels": "board-only",
"maxTrendsPerRun": 50
}

Backward compatibility: the base actor's keys — country, hour1hour23, yesterday, weekAgo, monthAgo, yearAgo, day2, day3, flags, proxyConfiguration — are all still read and merged in; country takes precedence over market when both are supplied.

Common pitfall: minHoursOnBoard needs includeStayingPower set to true. With staying power off, hoursOnBoard is null on every row, and a minHoursOnBoard greater than 0 will filter out every row rather than a subset — the Actor cannot measure a floor it never computed.

⬆️ Output

Every result is one typed JSON dataset row. Rows come in two shapes: a normal trend row carries 26 keys of rank history and staying-power data; an uncharged accounting row (source page unreachable, or a legacy date toggle that is permanently dead upstream) carries a shorter 6-key shape with errorReason and errorDetail instead. The dataset's default view surfaces 28 columns — the union of both shapes. Export as JSON, CSV, Excel, XML or HTML, or read the dataset through the Apify API.

FieldDescription
trendTrend name or hashtag text, as displayed on the board
rankCurrent board position (1–50); null on sidebar-panel rows
movementnew, rising, falling, steady, or null when not enough history exists to classify it
rankDelta1hPosition change versus 1 hour ago (positive = climbed)
peakRankBest position reached inside the rankHistory window
peakAtUtcUTC timestamp of that peak
rankHistoryArray of {hoursAgo, atUtc, rank} — up to 8 hourly board positions, decoded from the board's own sparkline
sparklineHoursHow many hourly positions were available for this trend (a missing hour means off-board, not rank 0)
hoursOnBoardHours the trend has been on the board within the sampled staying-power window
hoursOnBoardIsMinimumtrue when the trend was already trending before the window opened — hoursOnBoard is a floor, not an exact figure
bestRankInWindowBest position across every staying-power snapshot in the window
snapshotsObservedSample size — how many snapshots this trend appeared in
isNewInWindowtrue when the trend appears in exactly one snapshot
firstSeenUtcReal UTC timestamp of the first snapshot containing the trend
lastSeenUtcReal UTC timestamp of the last snapshot containing the trend
timelineWindowHoursSpan of the staying-power window in hours — the denominator behind hoursOnBoard
timelineSnapshotsTotal snapshots the staying-power timeline was built from
snapshotTimeUtcThe board page's own real slice time, parsed from its embedded date, not the scrape clock
timePeriodLive, N hour(s) ago, Custom, or the name of a legacy date toggle on an accounting row
sourcePanelboard, top_by_score, or longest_trending
isBoardRowtrue for the 50-row board, false for a sidebar panel row
isHashtagtrue when the trend text starts with #
panelDetailPanel-specific display text (e.g. a score label); null on board rows
trendPageUrlAbsolute URL of the trend's getdaytrends.com detail page
errorReasonPresent only on uncharged accounting rows — a short machine code for why nothing was scraped
errorDetailPresent only on uncharged accounting rows — the URL or human-readable detail behind errorReason
timeScrape-time timestamp, kept for backward compatibility with the base actor
scrapedAtScrape-time timestamp (current name)

errorReason values observed in the source: source_endpoint_dead (a legacy date toggle whose upstream URL returns HTTP 520 on every probe), http_520 / http_404 / http_410 (deterministic upstream removal, not retried), fetch_failed (retries exhausted on a transient error), no_trend_table (page fetched but no trend table found), timeline_unavailable (the staying-power source produced no usable snapshots).

Scraped results

[
{
"trend": "#PerthSantaConcertD2",
"rank": 1,
"movement": "rising",
"rankDelta1h": 4,
"peakRank": 1,
"peakAtUtc": "2026-07-25T08:00:00Z",
"rankHistory": [
{ "hoursAgo": 0, "atUtc": "2026-07-25T08:00:00Z", "rank": 1 },
{ "hoursAgo": 1, "atUtc": "2026-07-25T07:00:00Z", "rank": 5 },
{ "hoursAgo": 2, "atUtc": "2026-07-25T06:00:00Z", "rank": 5 }
],
"sparklineHours": 3,
"hoursOnBoard": 3.41,
"hoursOnBoardIsMinimum": false,
"bestRankInWindow": 1,
"snapshotsObserved": 6,
"isNewInWindow": false,
"firstSeenUtc": "2026-07-25T04:54:15Z",
"lastSeenUtc": "2026-07-25T08:18:50Z",
"timelineWindowHours": 18.0,
"timelineSnapshots": 24,
"snapshotTimeUtc": "2026-07-25T08:00:00Z",
"timePeriod": "Live",
"sourcePanel": "board",
"isBoardRow": true,
"isHashtag": true,
"panelDetail": null,
"trendPageUrl": "https://getdaytrends.com/united-states/trend/%23PerthSantaConcertD2/",
"scrapedAt": "2026-07-25T08:22:11Z"
},
{
"trend": "Bengals",
"rank": 22,
"movement": "falling",
"rankDelta1h": -6,
"peakRank": 1,
"peakAtUtc": "2026-07-24T14:00:00Z",
"rankHistory": [
{ "hoursAgo": 0, "atUtc": "2026-07-25T08:00:00Z", "rank": 22 },
{ "hoursAgo": 1, "atUtc": "2026-07-25T07:00:00Z", "rank": 16 }
],
"sparklineHours": 2,
"hoursOnBoard": 18.0,
"hoursOnBoardIsMinimum": true,
"bestRankInWindow": 1,
"snapshotsObserved": 24,
"isNewInWindow": false,
"firstSeenUtc": "2026-07-24T14:06:02Z",
"lastSeenUtc": "2026-07-25T08:18:50Z",
"timelineWindowHours": 18.0,
"timelineSnapshots": 24,
"snapshotTimeUtc": "2026-07-25T08:00:00Z",
"timePeriod": "Live",
"sourcePanel": "board",
"isBoardRow": true,
"isHashtag": false,
"panelDetail": null,
"trendPageUrl": "https://getdaytrends.com/united-states/trend/Bengals/",
"scrapedAt": "2026-07-25T08:22:11Z"
},
{
"trend": "#OpeningDayGiveaway",
"rank": null,
"movement": "new",
"rankDelta1h": null,
"peakRank": 3,
"peakAtUtc": "2026-07-25T08:00:00Z",
"rankHistory": [
{ "hoursAgo": 0, "atUtc": "2026-07-25T08:00:00Z", "rank": 3 }
],
"sparklineHours": 1,
"hoursOnBoard": 0.35,
"hoursOnBoardIsMinimum": false,
"bestRankInWindow": 3,
"snapshotsObserved": 1,
"isNewInWindow": true,
"firstSeenUtc": "2026-07-25T08:04:11Z",
"lastSeenUtc": "2026-07-25T08:04:11Z",
"timelineWindowHours": 18.0,
"timelineSnapshots": 24,
"snapshotTimeUtc": "2026-07-25T08:00:00Z",
"timePeriod": "Live",
"sourcePanel": "top_by_score",
"isBoardRow": false,
"isHashtag": true,
"panelDetail": "Score: 128",
"trendPageUrl": "https://getdaytrends.com/united-states/trend/%23OpeningDayGiveaway/",
"scrapedAt": "2026-07-25T08:22:11Z"
},
{
"time": "2026-07-25T08:22:11Z",
"timePeriod": "yesterday",
"trend": null,
"errorReason": "source_endpoint_dead",
"errorDetail": "getdaytrends.com date-archive URLs return HTTP 520 upstream.",
"scrapedAt": "2026-07-25T08:22:11Z"
}
]
  • Social listening and newsroom analysts: filter movementFilter: "rising" combined with a low hoursOnBoard to catch a story while it's still breaking, and use movement: "falling" plus a high peakRank to spot a story that has already peaked before you cover it.
  • AI engineers and LLM developers: an agent issues a query with market and movementFilter, receives structured JSON back, and passes trend, rankHistory and hoursOnBoard straight into the model as grounded, current context — no scraping code in the agent itself.
  • Market researchers: schedule runs across several markets and diff rank and movement per trend between runs to measure share-of-voice and cross-market volatility for a topic or brand hashtag.
  • Brand and campaign teams: track a specific hashtag's rank, movement and hoursOnBoard across scheduled runs to see whether a campaign is gaining or losing board position, and for how long it held it.
  • Content and social teams: filter on movement: "rising" with a low hoursOnBoard to identify topics worth timing content around while they are still gaining position, and use sourcePanel: "top_by_score" to catch high-scoring topics before they reach the main 50-row board.

🧬 How do you monitor trend staying power over time?

Staying-power monitoring is the discipline of tracking not just whether a trend is on the board, but whether it is gaining or losing durability — separating a genuine, sustained story from an hour-long spike that will be gone by your next run. The Actor's hoursOnBoard, movement and snapshotsObserved fields already give you a single-run snapshot of this; monitoring means diffing that snapshot against a previous run.

Diff on trend as the join key. Between two runs, watch rank and movement for direction change, hoursOnBoard for whether a trend that was new last run is still on the board this run, and snapshotsObserved for whether your sample size is growing (a trend genuinely persisting) or static (a trend that stopped being picked up). A typical workflow: schedule the Actor hourly for a market via an Apify schedule, pull each run's dataset through the Apify API, and alert when a tracked hashtag's movement flips from rising to falling, or when hoursOnBoard crosses a threshold that marks it as durable rather than a spike.

One thing worth being precise about: the staying-power metrics themselves are not built by this Actor accumulating its own run history in Apify storage — they come from trends24.in's own already-multi-snapshot timeline, read fresh in a single request each run. Run-over-run monitoring (comparing this run to your last run) is something you build on top, by diffing dataset rows between scheduled runs yourself — the Actor does not persist a run-to-run diff internally.

Twitter Trends Scraper With Rank History & Staying Power works with any language or tool that can send an HTTP request, through the Apify API.

REST API with Python

from apify_client import ApifyClient
client = ApifyClient("<YOUR_APIFY_TOKEN>")
run = client.actor("<YOUR_USERNAME>/twitter-trends-scraper-with-rank-history-staying-power").call(run_input={
"market": "US",
"movementFilter": "rising",
"minHoursOnBoard": 2,
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
if not row.get("errorReason"):
print(row["trend"], row["rank"], row["movement"], row["hoursOnBoard"])

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request.

Scheduled monitoring and delivery

Use an Apify schedule to run the Actor hourly or on any cron interval per market, and pull each run's dataset through the Apify API afterward. There is no actor-specific webhook payload documented in the source; use Apify's own webhook support on run events to trigger downstream delivery instead of polling.

Yes. Twitter Trends Scraper With Rank History & Staying Power reads only what any logged-out visitor already sees on getdaytrends.com's and trends24.in's public trending-topic pages — no login, cookie or authenticated endpoint is used. Courts have generally treated scraping of publicly accessible web data as not violating the U.S. Computer Fraud and Abuse Act — see hiQ Labs, Inc. v. LinkedIn Corp., 9th Circuit, 2019 (reaffirmed 2022).

Trend names and rank positions are aggregate public-topic data, not personal data about an identifiable individual, so this output does not carry the same GDPR/CCPA obligations as scraping personal profiles. What does apply is the source sites' own terms of service, and any local rules on systematic reuse of a compiled dataset. Consult your legal team before commercial use involving bulk storage or redistribution of the results.

❓ Frequently asked questions

62 country codes plus the worldwide board, set through market (or the legacy country key, which takes precedence when both are supplied). The full list is in the Input section above.

Set movementFilter to rising, falling, new or steady. all (the default) returns every row regardless of movement.

How does the Actor handle getdaytrends.com's and trends24.in's anti-bot measures?

Requests use curl_cffi with Chrome TLS impersonation, falling back to plain requests if curl_cffi is unavailable. Both source sites respond without a proxy from Apify by default; if a selected Apify proxy fails its preflight check, the Actor falls back to Apify RESIDENTIAL. Fetches retry with exponential backoff and jitter up to maxRetries times, except on deterministic upstream failures (HTTP 520/404/410), which are not retried since retrying them is pure waste.

Does the Actor return trend rank history and staying power?

Yes. rankHistory (up to 8 hourly positions, decoded from the board's own sparkline) and the staying-power block (hoursOnBoard, firstSeenUtc, lastSeenUtc, bestRankInWindow, snapshotsObserved, isNewInWindow) are on every board and panel row. Staying power is null across the board when includeStayingPower is turned off, or when the trends24.in timeline could not be fetched that run.

Up to 50 board rows plus 20 sidebar-panel rows (10 per panel) per URL scraped, before any filter is applied. maxTrendsPerRun caps the total charged rows across the whole run; 0 (the default) means no cap. movementFilter and minHoursOnBoard can reduce the count further.

Why doesn't the Actor return a tweet-volume or tweet-count field?

Because it is not reliably available from either source. The base scraper this Actor extends returned a volume field that was unpopulated or, on a portion of rows, corrupted with the trend name itself when the site's markup lacked the expected value. This Actor omits the field entirely rather than ship an empty or unreliable column.

Why do the legacy date-toggle inputs (yesterday, weekAgo, monthAgo, etc.) return no data?

getdaytrends.com's date-archive URLs return HTTP 520 on every probe. The six toggles are still accepted for input compatibility with the base actor, but instead of retrying a page that will never return 200, they emit a single uncharged accounting row with errorReason: "source_endpoint_dead" per toggle.

How do I monitor a hashtag's staying power over time?

Schedule the Actor for the market you care about, pull each run's dataset, and diff rank, movement and hoursOnBoard per trend between runs — see the monitoring section above for the full loop and which fields to compare.

Does this Actor work with Claude, ChatGPT and AI agent frameworks?

Yes. It is callable as a standard HTTP endpoint through the Apify API, so any agent framework that can make a request can invoke it and receive typed JSON — including rank history and staying power — directly usable as grounded context.

Checked on the Apify Store on 8 July 2026: karamelo/twitter-trends-scraper covers the widest set of countries and time periods (live plus up to 3 days back) but returns only time, timePeriod, trend and volume per row — a single snapshot, no history. fastcrawler/x-twitter-trends-scraper-2025 documents only a country input and returns rank, topic, tweet_volume and last_updated — also a single snapshot. fastcrawler/twitter-x-trends-scraper-api-real-time-trend-tracker likewise returns rank, topic, tweet_volume and last_updated from a single required country input. None of the three document an hourly rank-history field or a staying-power/duration-on-board metric; this Actor's rankHistory and staying-power block are what none of them return.

Can I use this Actor without managing proxies or platform credentials?

Yes. No X/Twitter account, API key or cookie is needed — both sources are scraped logged out. Both respond without a proxy from Apify by default, and if you do select an Apify proxy, the Actor tests it and falls back to RESIDENTIAL automatically if it fails. The only credential you need is your own Apify token.

💬 Your feedback

Found a bug, or need a field that's on the board but missing from the output? Open an issue on the Actor's Issues tab on Apify — reports that include the market and approximate run time are the fastest to act on.