X API trends: two endpoints that disagree on one number

#Quick answer

X API trends is two endpoints, and they do not agree with each other. GET /2/trends/by/woeid/:id returns tweet_count as an integer. GET /2/users/personalized_trends returns post_count as a string. Both return names and no numbers unless you ask for the field, and X's documented example for each one demonstrates the wrong half of that. The bill is $0.010 per request either way, and trends is the only data type on the rate card that deduplication does not cover.

Last updated: November 2026

Three facts decide whether this namespace is usable: volume is opt-in, the price is per request rather than per result, and the personalized endpoint has a daily ceiling you cannot buy your way past.

#Two endpoints, and a third page with nothing behind it

Trends on X (formerly Twitter) are the ranked topic lists in the Explore tab. How they get built on the product side is a separate piece on X trending topics. On the API side the surface is this small:

X's documentation index lists a third reference page, "Get AI trend by ID", promising "a single AI-curated trend by its identifier, including metadata about the trend and the Posts driving it". Open it and there is a heading, that sentence, and nothing else. No path, no parameters, no response schema, no example. The live API description at version 2.174 contains no AI trends path either, and X's own rate-limit reference heads the section "Trends (2 endpoints)". The page is linked from both the X API v2 index and the Enterprise API index, so it is doubly advertised and entirely empty.

Worth noting what else is missing from the changelog. Trends by WOEID was announced on 12 December 2023. Personalized trends never was. Neither was an AI trends endpoint. One of the two live endpoints in the namespace arrived without any announcement at all, which is the same documentation pattern we hit tracing the X API rate limits for newer paths.

#Volume is opt-in, and both examples get it wrong

Here is X's example request for trends by WOEID, verbatim:

curl "https://api.x.com/2/trends/by/woeid/1" \
  -H "Authorization: Bearer $BEARER_TOKEN"

And the example response printed directly beneath it:

{ "data": [ { "trend_name": "#AI" }, { "trend_name": "Breaking News" } ] }

Those two are consistent, and that is the problem. The response has no volume because the request did not ask for any. trend.fields accepts exactly two values, trend_name and tweet_count, and omitting the parameter gets you half the object. Nothing on the page says so. A developer copying the quickstart concludes the endpoint does not report volume.

What you want is this:

curl "https://api.x.com/2/trends/by/woeid/1?\
max_trends=50&trend.fields=trend_name,tweet_count" \
  -H "Authorization: Bearer $BEARER_TOKEN"

The personalized-trends page has the mirror-image bug. Its example response shows:

{ "data": [ { "trend_name": "#AI", "tweet_count": 125000 } ] }

tweet_count is not a valid field on that endpoint. The personalized_trend.fields enum holds category, post_count, trend_name and trending_since. So X's documented example for personalized trends advertises a field the schema does not have, while omitting the two fields that make the endpoint interesting: category, which buckets the trend, and trending_since, which tells you how old it is.

#The same number, two names, two types

This is the detail that will break a client written against one endpoint and pointed at the other:

One namespace, one concept, and nothing shared. If you normalise trends from both sources into one table, the integer-versus-string split is a silent type coercion waiting to land, and the field name difference means a client reading tweet_count from the personalized response gets undefined rather than an error.

Naming also tells you roughly when each was built. tweet_count predates the rename of Tweets to Posts; post_count came after. X renamed the concept and shipped the second endpoint with the new vocabulary without touching the first.

#Why the per-request price matters more than it looks

Trends sits on the write table of the pay-per-use rate card, at $0.010 per request. Three consequences follow, and all three are arithmetic rather than opinion.

max_trends is free money up to 50. The parameter defaults to 20 and caps at 50. The charge is per request, not per trend returned. So a default call pays $0.010 for 20 trends and a maxed call pays $0.010 for 50. There is no reason to ever send the default.

Deduplication does not apply. The rate card deduplicates billable resources inside a 24-hour UTC window: request the same Post twice today and you are charged once. That mechanism needs a resource to key on. A per-request charge has none, so every repeat poll of an unchanged trend list is a fresh $0.010. Trends is the one data type here where polling the identical payload bills every single time, which is the opposite of how the Posts side of X API pricing behaves.

It is twice the price of a Post read. A Post resource is $0.005. One trends request, which returns no Post text, no author and no engagement, is $0.010. At the 75-per-15-minutes app ceiling, continuous WOEID polling tops out around $72 a day per app.

And personalized trends does not get the owned-read discount. Owned Reads drop to $0.001 per resource when your app reads its owner's own data, and the qualifying list runs to twelve endpoints covering your Posts, mentions, likes, bookmarks, followers, following, blocks, mutes and lists. Personalized trends reads nothing but the authenticated user's own data. It is not on the list. It stays at $0.010, ten times the rate X charges for every other flavour of "your own stuff".

#The 200-a-day cap is the real ceiling

Here is where personalized trends stops being a product feature.

The per-app 200 per 24 hours is app-wide, not per user. Your entire application gets 200 personalized-trends calls a day across every account that has authorised it. Fifty users can be refreshed four times a day each. Two hundred users can be refreshed once. Beyond that, somebody goes without, and no amount of credit changes it, because the constraint is quota rather than money. The theoretical maximum you can spend on personalized trends is $2.00 a day.

Note too that the 200-per-15-minutes app figure is a decoy. Two hundred calls inside one window consumes the whole day's allowance, so the two app limits are the same number wearing different hats.

Then there is the subscription requirement. X's prerequisites for personalized trends list a Premium user subscription alongside the OAuth 2.0 PKCE tokens. The endpoint needs your user to be paying X, on top of the app-wide quota. Trends by WOEID asks for none of that and accepts a plain app-only Bearer token, which is why almost everything built on X trends is built on WOEIDs.

#There is no way to discover a WOEID

WOEID is Yahoo's Where On Earth identifier, inherited from the v1.1 era. Version 1.1 shipped two helper endpoints for it, trends/available and trends/closest. Neither exists in v2. The 2.174 description has exactly two trends paths, and the woeid path parameter is a bare integer with no enum, no minimum and no maximum, so the API will accept any number you send it and will not tell you which numbers mean anything.

What X publishes is eight values:

If your product needs Berlin, Lagos, São Paulo or any of the hundreds of other locations X has historically supported, the v2 API offers no route to the number and no route to the list. That is the single biggest practical gap in the namespace, and it is why so many "X trends API" pages you will find are selling a resolver rather than documenting one.

#What to use instead, depending on what you wanted

If you wanted volume on a specific topic rather than a ranked list, the trends endpoints are the wrong tool. Recent counts give you a time series for an arbitrary query, which is both more precise and cheaper per unit of information than polling a top-50 list; the mechanics are in our notes on X API search. Counts: Recent is $0.005 per request against trends at $0.010.

If you wanted trends to decide what to post about, the honest read is that a ranked list of 50 strings with a volume number is a weak input. It tells you what is loud, not what your audience responds to, and by the time a term is in a national top 50 the reply slots on the big Posts are gone. X-Autopilot works the other end of that problem, running on your own Mac in your own browser session so there is no shared cloud IP pool in the path. That is a smaller detection surface than a hosted scheduler, not a risk-free one, and automating engagement through a browser sits in a gray area under X's rules rather than being something X sanctions. The trends endpoints are fully sanctioned. They just answer a narrower question than their name suggests.