X News API: the two endpoints with no listed price

#Quick answer

The X news API is two X API v2 endpoints, live since 19 November 2025. GET /2/news/search takes a query and returns trending stories; GET /2/news/{id} returns one story plus the IDs of the posts it was clustered from. The stories are written by Grok and carry a disclaimer field saying so. Both endpoints are on pay-per-use access, but neither appears on X's published price table, and the real-time webhook version is Enterprise only.

Last updated: October 2026

This is one of the quietest launches on the platform. X (formerly Twitter) shipped it with a changelog line and a forum post, no developer blog, and no entry in the pricing docs. Search for it and you get the two doc pages and the announcement. So here is what the endpoints actually return, what they cost in practice, and the three places the documentation contradicts itself.

#What a news story actually is

Not an article. A story is a cluster of X posts that Grok has read and summarised, which is why there is no publisher field, no byline and no article URL anywhere in the schema.

What you get per story:

The contexts object is the part worth the call. Entity and ticker extraction is the expensive half of building a market or brand monitor, and X is doing it server-side for free. A story about a stock drop arrives with "tickers": ["NBIS"] and "organizations": ["Goldman Sachs", "Nebius Group N.V."] already parsed out.

That disclaimer field is not decoration. X ships the text "This story is a summary of posts on X and may evolve over time. Grok can make mistakes, verify its outputs" inside every payload, which is a fairly clear signal about what X expects you to do if you republish any of it.

#The two endpoints, and the parameters that bind

GET /2/news/search takes query (required, 1 to 2048 characters), max_results (1 to 100, default 10) and max_age_hours (1 to 720, default 168). That last one is the ceiling worth knowing before you plan anything: 720 hours is 30 days, and there is no archive behind it and no pagination token in the response. The response meta carries result_count and nothing else.

GET /2/news/{id} takes the ID in the path and the same news.fields selector. It is how you get cluster_posts_results, since the search response in X's own launch example does not include the cluster unless you ask.

Auth is unusually relaxed for 2026. Both endpoints accept app-only Bearer Token, OAuth 1.0a user tokens, and OAuth 2.0 PKCE with tweet.read plus users.read. If you only want news, a bearer token is enough and you never touch a consent screen. Our X API OAuth guide covers which flow to pick when you need more than reads.

Rate limits are 200 requests per 15 minutes per app on both endpoints, with search also carrying a separate 200 per user. They are easy to miss because X files them under a table called "Other endpoints" rather than anywhere near the news docs.

#Three places the docs disagree with themselves

First, the timestamp field. The changelog and the current lookup example both call it last_updated_at_ms, and the example value is an ISO 8601 string, not milliseconds. The OpenAPI news.fields enum and the X Activity API payload table both call it updated_at, and so did X's own launch responses. Request both names, read whichever arrives, and do not key a dedupe on one of them.

Second, the news.fields enum lists contexts four separate times and includes a keywords value that appears in no published example payload. Harmless, but it tells you the surface is generated from an internal schema that is still moving.

Third, and this one costs money: news.new sits on the pay-per-use webhook price table at $0.005 per event, while the X Activity API docs mark the same event Enterprise and Partner only. A price on a table is not an entitlement. If you are on self-serve access, assume you are polling.

#What it costs, honestly

X has not published a unit price. There is no News: Read row next to Posts: Read at $0.005 and User: Read at $0.010 on the pay-per-use price table, and the changelog entry that launched the endpoints says nothing about billing.

What we do know is that both endpoints are genuinely on pay-per-use, because when a developer asked for the complete list of pay-per-use endpoints in March 2026, X staff posted it and it ends with a News section containing both. So: callable, with a rate you have to read off your own Developer Console rather than the docs.

One cost you can predict is the second call. cluster_posts_results hands you post IDs and nothing else, so every story you want to actually display needs a GET /2/tweets?ids=... hydration pass, billed as Posts: Read at $0.005 per Post. Ten stories with ten posts each is up to 100 Posts, so $0.50 for one screen of content, and that is before you have read any of it twice. Posts dedupe within a 24-hour UTC window, which makes a daily job much cheaper than an hourly one. The same arithmetic shows up in X API search, where reads are the whole bill.

Cheapest workable pattern: poll search on a long interval, store the story IDs and summaries, and hydrate only the clusters a user actually opens.

#How it compares to the trends endpoint

They answer different questions. GET /2/trends/by/woeid/:id tells you which phrases are spiking in a place, billed at $0.010 per request, and gives you no interpretation at all. The news endpoints tell you what the story behind a phrase is, pre-summarised, with entities pulled out. If you are building a dashboard, trends is the tick and news is the explanation. The mechanics of the first one are in our guide to how X trending topics work.

If what you need is real-time rather than periodic, that is the X Activity API webhook route, which stays shut on self-serve for this event type.

#The thing that bites: reading news is not permission to reply to it

This is where news bots go wrong. Pulling stories is an ordinary read. Posting about them automatically is governed by the February 2026 change that restricted programmatic replies via POST /2/tweets to cases where the original author summoned your account by mentioning it or quoting one of its posts.

In October 2026 a developer took a news-context reply bot to the forum and asked X directly. Staff confirmed that a mention-only or quote-only workflow that replies to explicit inbound requests, discloses AI assistance, honours opt-outs and does no unsolicited keyword or timeline outreach generally fits the automation guidelines, while declining to issue a written approval for it. The line they drew is the useful part: "a bare mention, keyword match, follow, or engagement count would not authorize a reply" was the developer's own framing, and staff accepted it as the correct read.

So a news digest, a dashboard, a newsletter or a DM to people who asked for it are all fine shapes. A bot that watches news.new and quote-posts every story to accounts that never asked is the shape that gets an app suspended. If you automate anything that posts, read X's automation rules first and add the automated account label before you ship, not after.

#Should you build on it?

Yes for anything that reads: market monitors, internal briefings, a "what is X saying about this ticker" panel, enrichment for a dataset you already have. The entity extraction alone saves real work, the auth is simple, and 200 calls per 15 minutes is generous for a polling job.

Be careful with two things. The missing price means your first month's invoice is the only reliable spec, so set a spending limit in the console before the first loop runs. And the content is model-generated, with a disclaimer field that exists precisely because X knows it can be wrong, so do not put a Grok summary in front of a user as fact without showing where it came from.

If the goal is growth rather than data, the API is usually the wrong lever for the price. We lay out the trade-offs between the sanctioned API route and the browser route in our X API alternatives breakdown. Browser automation is a gray area under X's automation rules in a way reading the news endpoint simply is not, and that difference is worth understanding before you pick a side.