Twitter Trends API: Get Trending Topics in 2026

By Sorsa Editorial

Updated July 8, 2026: added the 100 free requests starting allowance, refreshed the current per-request pricing against the official pay-per-use trend rate, and reconfirmed the endpoint's default result count and the often-empty tweet-count field.

Key Takeaway: To get Twitter (X) trending topics through an API in 2026, send an authenticated GET request with a WOEID, the numeric Where On Earth IDentifier for a location. The official X API serves this at GET /2/trends/by/woeid/{woeid} on paid tiers using a Bearer token, covering roughly 470 trend locations worldwide.

A Twitter trends API does not have to mean OAuth, an app-review queue, or a five-figure contract. Sorsa API, an alternative Twitter/X API, returns the same WOEID-based trends through a single /trends call authenticated with one API key. Each trend comes back already paired with a ready-to-run search query and a direct URL, and billing is flat per request: one trend pull costs about $0.002 on the Pro plan ($199 for 100,000 requests) against roughly $0.20 on the official API, which reads the same 20 trends at $0.010 each. The rate limit is a flat 20 requests per second on every plan, with no 15-minute windows.

Trending topics are one of the few real-time signals on the open web that show what millions of people are paying attention to right now. Marketing teams use them to time campaigns, newsrooms use them to spot breaking stories, and quant desks treat them as an early signal layer. The hard part in 2026 is rarely the use case. It is getting the data out cleanly, because the official path is more fragmented and more expensive than most tutorials admit.

This guide covers what is actually available today: how WOEID-based retrieval works, how the official X API v2 trends endpoint behaves (including where it falls short), how to pull trends with a single API key, and working code in Python, Node.js, and curl. Most existing tutorials still reference the deprecated v1.1 endpoint and Tweepy's OAuth 1.0a flow, which no longer applies to trends.

Table of Contents

1. What Is the Twitter Trends API?
2. Two Ways to Get X Trends Through Code in 2026
3. How WOEID Works (and Why Every Trends Call Needs One)
4. Getting Trending Topics with the Sorsa API
5. WOEID Reference: Top Countries and Cities
6. Code Examples: Python, Node.js, and curl
7. Combining Trends With Search for Deeper Analysis
8. Common Issues With the Official X Trends Endpoint
9. Use Cases for Trend Data
10. Rate Limits, Caching, and Best Practices
11. In Practice: Trend Polling for a Newsroom Desk
12. Frequently Asked Questions
13. Getting Started

What Is the Twitter Trends API?

A Twitter trends API is an HTTP endpoint that returns the topics currently trending on X (formerly Twitter) for a specific geographic area. A typical response is a ranked list of about 20 to 50 topics for one location, recomputed by the platform every few minutes. Trends accessed this way are location-scoped, not personalized.

The distinction matters. The personalized "Trends for you" view on the X website blends in accounts you follow and your activity, and it is not exposed through any API. What an API returns is the platform-wide, location-scoped list X computes for a region, which is exactly what you want for analytics, monitoring, and research.

The list is recomputed every few minutes. For nearly every workload, polling each location once every 5 to 15 minutes catches new entries as they appear without wasting requests.

Two Ways to Get X Trends Through Code in 2026

Two practical paths exist for retrieving X trending topics through code in 2026: the official X API v2 trends endpoint, authenticated with an OAuth 2.0 Bearer token on a paid tier, and third-party REST APIs that wrap the same WOEID-based data behind a single API key. Both return location-scoped trends; they differ in authentication, pricing, and what each trend object includes.

Option 1: The official X API v2 trends endpoint

X exposes its trends endpoint at GET /2/trends/by/woeid/{woeid}. It takes a WOEID as a path parameter and returns a list of trend objects, each carrying a trend_name and an optional tweet_count that you request through the trend.fields parameter. The full reference lives in X's official trends documentation.

Authentication is an OAuth 2.0 Bearer token, which means registering a developer app and sitting on a paid tier of the X API. There is no free access to trends in 2026, and the platform now bills reads per resource, so every trend returned is a separately metered unit. For the wider context on how that pricing works, see our breakdown of X API pricing in 2026 and why the official API is so expensive.

To go from a trending topic to the actual posts behind it, you build your own search query and call the search endpoint separately.

Option 2: A single-key trends endpoint

The Sorsa trends endpoint is built around a different priority: making trend data usable in the very next step of a pipeline. The response includes the trend name plus a pre-built search query and a direct URL, so you can flow straight into deeper analysis without writing any query-construction code.

Authentication is a single API key in the ApiKey header. There is no OAuth flow, no app registration, and no developer review. Sign up, copy a key, send the request, and the first 100 requests are free with no card required. Pricing is flat per request across every endpoint, including trends, so one trend list fetch costs the same as one user lookup or one search call.

Side-by-side: official X API trends vs Sorsa

A factual comparison for trend retrieval specifically, with the genuine limits of each option stated plainly.

The pattern that follows from the numbers: at any real polling volume, flat per-request billing is far cheaper than paying for every individual trend, and a single API key removes the OAuth and app-review overhead. The honest caveats are that neither option returns historical trends, and the Sorsa endpoint does not attach a tweet-volume figure to each trend. The next sections show how to work with both, and the Common Issues section covers why the official tweet_count is unreliable in the first place.

How WOEID Works (and Why Every Trends Call Needs One)

A WOEID (Where On Earth IDentifier) is a numeric ID that uniquely labels a geographic place. Twitter adopted WOEIDs for trends around 2010 and still uses them, so every trends API call requires a WOEID for the location you want. There are roughly 470 valid trend WOEIDs, spanning worldwide, country, and city levels.

A few examples make the shape clear:

• 1 is Worldwide (global trends)
• 23424977 is the United States
• 23424975 is the United Kingdom
• 23424900 is Mexico
• 2459115 is New York City
• 44418 is London

Country-level IDs cover an entire country, while town-level IDs cover a single metro area. Not every country has town-level trends; smaller markets often return only a single country-wide list. You do not authenticate differently per region and there is no per-region pricing. If you know the integer, you can fetch its trends.

How to find the WOEID for a location

For the most common markets, use the reference table below. For anything beyond the top markets, a complete list of X-supported trend locations is maintained as a public WOEID gist on GitHub with all of the valid entries. The Sorsa API does not expose a separate "available locations" endpoint, so the gist is the canonical lookup; if a location is not in it, X does not publish trend data for that place at the API level.

Getting Trending Topics with the Sorsa API

The trends endpoint takes a single query parameter, woeid, and returns a list of trend objects. There is no historical mode and no pagination: each call returns the current list at the moment of the request.

Request:

GET https://api.sorsa.io/v3/trends?woeid=23424977
Header: ApiKey: YOUR_API_KEY

Response:

{
  "trends": [
    {
      "name": "#FedDecision",
      "query": "%23FedDecision",
      "url": "https://twitter.com/search?q=%23FedDecision"
    },
    {
      "name": "Powell",
      "query": "Powell",
      "url": "https://twitter.com/search?q=Powell"
    },
    {
      "name": "rate cut",
      "query": "%22rate+cut%22",
      "url": "https://twitter.com/search?q=%22rate+cut%22"
    }
  ]
}

Each trend object has three fields:

• name: the human-readable label of the trending topic. Display this in your UI.
• query: the URL-encoded search string. Pass it to the search endpoint to retrieve the actual posts behind the trend.
• url: a direct link to the X search results page, useful for clickable references in dashboards or alerts.

To build a historical record, poll on your own schedule and store each snapshot. A run every 10 to 15 minutes per location, written to a time-series store, becomes a usable dataset within a few weeks. The full request and response shape is documented in the trends endpoint reference, and the quickstart guide walks through getting a key.

WOEID Reference: Top Countries and Cities

The tables below cover the WOEIDs that come up most often in production. For every supported location, use the public WOEID gist.

Global

Countries

Major Cities

For smaller cities and regional markets, use the full WOEID gist.

Code Examples: Python, Node.js, and curl

All three examples below hit the same endpoint and require only an API key in the ApiKey header.

curl

curl -H "ApiKey: YOUR_API_KEY" \
  "https://api.sorsa.io/v3/trends?woeid=23424977"

Python

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# US trends (WOEID 23424977)
resp = requests.get(f"{BASE}/trends", headers=headers, params={"woeid": 23424977})
trends = resp.json()["trends"]

for t in trends[:10]:
    print(t["name"], "->", t["url"])

Node.js

const API_KEY = "YOUR_API_KEY";

async function getTrends(woeid) {
  const res = await fetch(`https://api.sorsa.io/v3/trends?woeid=${woeid}`, {
    headers: { ApiKey: API_KEY },
  });
  const { trends } = await res.json();
  return trends;
}

// US trends
getTrends(23424977).then((trends) => {
  trends.slice(0, 10).forEach((t) => console.log(t.name, t.url));
});

Polling multiple regions in parallel

When you track several markets at once, fire the requests concurrently rather than in a loop. The flat 20 requests per second limit makes a handful of regions trivial.

import asyncio
import aiohttp

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
WOEIDS = {"US": 23424977, "UK": 23424975, "Japan": 23424856, "Brazil": 23424768}

async def fetch_trends(session, name, woeid):
    url = f"{BASE}/trends"
    async with session.get(url, headers={"ApiKey": API_KEY}, params={"woeid": woeid}) as r:
        data = await r.json()
        return name, [t["name"] for t in data["trends"][:10]]

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_trends(session, n, w) for n, w in WOEIDS.items()]
        for name, tops in await asyncio.gather(*tasks):
            print(name, tops)

asyncio.run(main())

Combining Trends With Search for Deeper Analysis

A trend name on its own tells you a phrase is hot. The value comes from pulling the posts behind it, and the pre-built query field turns that into one extra call instead of a query-building exercise. When you do need to craft filters by hand, the search query builder assembles the syntax for you. The query arrives URL-encoded, so decode it before passing it to the search endpoint, which expects plain text.

import requests
from urllib.parse import unquote_plus

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# 1. Get current US trends
trends = requests.get(
    f"{BASE}/trends", headers=headers, params={"woeid": 23424977}
).json()["trends"]

# 2. For the top few trends, pull the posts driving each one
for trend in trends[:5]:
    body = {"query": unquote_plus(trend["query"]), "order": "popular"}
    posts = requests.post(f"{BASE}/search-tweets", headers=headers, json=body).json()["tweets"]
    print(trend["name"], "->", len(posts), "top posts")

From here you can rank accounts by engagement on those posts, classify sentiment, or route anything matching a watchlist into Slack. The search step is covered end to end in our Twitter search API guide, and an always-on version runs in the real-time monitoring walkthrough. Because both the trend pull and each search are flat single requests, a trends-to-posts pipeline stays cheap even at high frequency.

Common Issues With the Official X Trends Endpoint

The official X trends endpoint commonly returns fewer trends than expected, around 20 per location by default rather than the 50 the older v1.1 endpoint returned, and it occasionally returns an empty list during platform-side issues. Its tweet_count field is frequently null even when requested through trend.fields, and access is restricted to paid API tiers.

These are not edge cases. They show up repeatedly in X's own developer forums:

• Only about 20 trends. Developers calling GET /2/trends/by/woeid/{woeid} on v2 report receiving roughly 20 items, while the documentation does not promise the 50 that v1.1 used to return. If you specifically need a longer list, you have to work within that default and the endpoint's result-count parameter.
• Empty responses. During platform incidents, the endpoint has returned blank trend lists for every WOEID at once. This reflects upstream data, not your code, so any production poller needs to handle an empty array gracefully.
• Missing tweet volume. The tweet_count field is meant to carry per-trend volume, but multiple developers report it returning null even when trend.fields is set correctly. Treating that figure as reliable is a mistake.
• Paid-tier and OAuth overhead. Trends are not part of any free tier, and every call needs a Bearer token tied to a registered app, which is the slowest part of getting started.
• The v1.1 trail is a dead end. Older tutorials point at GET trends/place in v1.1, which X has deprecated. Code copied from those guides will not work.

This is the practical reason a single-key alternative exists. Pulling trends through an alternative Twitter/X API like Sorsa sidesteps the OAuth setup and the per-resource billing, returns the full current list in one request, and pairs each trend with a ready search query. The tweet-volume gap applies to both paths, and the honest answer for either one is the same: derive volume by counting search results for a trend over a time window, which is a more truthful measure than a field the platform leaves empty.

Use Cases for Trend Data

Trend data looks decorative until it sits inside a real pipeline. These are the patterns that drive most production usage.

Real-time content marketing. Social teams pull regional trends every 10 to 15 minutes, score them against brand-voice rules, and surface the ones safe to engage. The original Oreo Super Bowl moment was a manual version of this; the automated version runs on a trends feed.

Newsroom alerting. News desks watch a primary market plus a few bordering ones and fire a Slack alert when an unfamiliar topic enters the top ten, often catching a story before it reaches the wires.

Trading signal research. Quant teams pull trends in target markets on a tight interval and cross-reference against tickers and sector keywords. A trending topic sometimes precedes the corresponding price move, which makes it a useful input layer.

Localized campaign planning. Agencies pull trends for every market a client operates in, once or twice a day, to decide what creative ships where. The output is usually a sheet or BI dashboard rather than a live system.

Brand and crisis monitoring. The sudden appearance of a brand or product in regional trends is often the earliest signal of a PR event. Pairing trends with mention tracking turns this into a cheap, reliable alarm, and it pairs naturally with a social listening or competitor tracking workflow.

In every one of these, the trend call is the cheap part. The work is what you do with the result, which is why flat per-request pricing matters more here than it first appears.

Rate Limits, Caching, and Best Practices

A few practical notes for running this at scale.

Cache aggressively. Trends change every few minutes at most, so caching results for 5 to 10 minutes per WOEID covers nearly every use case and cuts request volume by orders of magnitude. Redis with a TTL is the simplest implementation.

Respect the rate limit. Sorsa enforces a flat 20 requests per second per API key across all endpoints, including /trends. Polling 20 regions every 30 seconds is fine; polling 200 regions every second is not, and returns 429 Too Many Requests. For higher throughput, the rate limits page covers custom limits.

Handle empty lists. Some smaller WOEIDs occasionally return short or empty arrays. This is normal and reflects the underlying X data, so code defensively.

Use the query field, not name, for search. The name is human-readable but may contain characters that need escaping. The query is already URL-encoded and is what X uses internally; decode it before passing it to the search endpoint.

Stagger scheduled polls. When tracking 50 WOEIDs, do not fire all 50 on the minute boundary. Spread them across a 30-second window to avoid burst load. The documentation also covers request patterns for optimizing API usage at scale.

In Practice: Trend Polling for a Newsroom Desk

The teams that lean hardest on trend data are social newsrooms and brand-monitoring desks. A roughly 12-person media analytics group we worked with polled regional trends across eight markets every few minutes to catch breaking stories early.

On the official API's pay-per-use model, reading around 30 trends per market across eight markets every five minutes adds up quickly, because each trend returned is a separately billed resource and a busy month pushes toward the platform's read ceilings. Moving the same polling to a flat per-request plan collapsed that into a single predictable monthly figure and removed the per-resource accounting entirely, since one location pull counts as one request no matter how many trends come back. The saving was not a clever optimization; it follows directly from flat-rate billing being far cheaper than per-resource billing at this volume, the same roughly 100x per-pull gap shown in the comparison table above.

Frequently Asked Questions

Does the X API v2 have a trends endpoint?

Yes. The X API v2 trends endpoint is GET /2/trends/by/woeid/{woeid}. It takes a WOEID as a path parameter, returns a list of trend objects, and supports an optional tweet_count field through the trend.fields parameter. Authentication uses an OAuth 2.0 Bearer token, and access is limited to paid X API tiers. The legacy v1.1 trends/place endpoint has been deprecated.

Why does the X trends endpoint return only 20 trends or an empty response?

The X API v2 trends endpoint returns about 20 trends per location by default, fewer than the 50 the retired v1.1 endpoint returned, and its documentation does not guarantee a fixed count. It can also return an empty array during platform-side incidents, which affects all WOEIDs at once rather than indicating a bug in your request. Production pollers should handle short and empty lists gracefully.

Is there a free Twitter trends API?

There is no free trends access through the official X API in 2026, since trends sit behind paid tiers and reads are billed per resource. Free scrapers and unofficial endpoints exist but tend to be rate-limited and unreliable. For dependable access at low cost, an alternative Twitter/X API such as Sorsa starts you with 100 free requests, no card required, then bills a flat rate, so one trend pull costs roughly $0.002 on the Pro plan and small workloads run a few dollars a month.

What is the difference between the official X trends API and Sorsa?

The official X trends endpoint returns trend names with an optional, often-empty tweet count and requires an OAuth 2.0 Bearer token on a paid tier billed per trend read. The Sorsa /trends endpoint returns each trend name with a pre-built search query and a direct URL, authenticates with a single API key, and bills a flat rate per request. For pipelines that combine trends with search, the ready-made query field removes the step of building search syntax by hand.

Do Twitter trends include tweet volume or counts?

The official X trends endpoint exposes a tweet_count field, but developers report it returning null even when requested through trend.fields, so it is unreliable. The Sorsa endpoint does not attach a volume figure to each trend. The most truthful way to gauge volume on either path is to query the search endpoint with the trend's query and count results over a fixed time window.

Can I get trends for a specific city?

Yes, when X supports trends for that city. Town-level WOEIDs cover most major metros worldwide, out of roughly 470 supported trend locations in total. Smaller cities usually have no dedicated list and fall back to country-level data. The public WOEID gist lists every supported location, and any city in it can be passed directly as the woeid parameter.

How do I find the WOEID for a country or city?

Check the reference table in this guide for common markets. For anything else, the public WOEID gist on GitHub lists every X-supported trend location and its numeric ID. If a place is not in that list, X does not publish trend data for it at the API level, so there is no WOEID to query.

Can I get historical Twitter trends?

No trends API returns historical data; both the official X endpoint and the Sorsa endpoint return only the current list. To build history, poll on a schedule and store each snapshot, typically every 10 to 15 minutes per location written to a time-series database. Because Sorsa bills a flat rate per request, frequent polling for a historical archive stays inexpensive.

Getting Started

The fastest path to your first trend list:

1. Create an account on the Sorsa dashboard and copy an API key, with no developer-account approval to wait on.
2. Send a GET request to https://api.sorsa.io/v3/trends with your key in the ApiKey header and a WOEID like 1 (Worldwide) or 23424977 (US).
3. Pass each trend's pre-built query field to the search endpoint to retrieve the actual posts driving the trend.

Every new account includes 100 free requests to start, no card required, and paid plans begin at $49 a month for 10,000 requests, with a flat 20 requests per second on every tier. The API has served more than 5 billion requests since 2022. You can try any endpoint without writing code in the Sorsa Playground, read the full API reference, or compare the options in our Twitter API alternative guide. For volume beyond the standard plans, the team handles custom limits through talk to sales.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

This guide draws on our hands-on work building and operating Sorsa, an alternative Twitter/X API, and on testing the live /trends endpoint against the official one during this update. The official endpoint's path, result behavior, and billing were verified against X's official trends documentation and X's developer forum threads on result limits and the tweet-count field; WOEID coverage was checked against the public WOEID gist. Pricing for both providers reflects the figures current as of June 9, 2026. Last verified June 9, 2026.