Twitter to RSS: How to Get an RSS Feed of Any X Account, Search or List

Twitter shipped RSS for profiles and searches in its early years, then removed the feeds as it retired the old API generations; the scripts that still rank for this query (a CPAN module, a Google Apps Script) were written to patch exactly that loss, and both depend on access that no longer exists. X has shown no sign of bringing feeds back, and its current developer offering is a pay-per-use JSON API, not syndication. So the honest framing is this: there is no Twitter RSS feed, only converters, and every converter is as reliable as its source of posts.

That source is the whole problem. A converter can read posts in three ways. It can scrape the website with a logged-in session, which is what Nitter does and what X has been shutting down; the Nitter README records cease-and-desist letters from X Corp dated 24 August 2026 demanding a takedown of instances and the repository, and GitHub shows the repository archived in September 2026 (checked 2026). It can pay the official API, which charges $0.005 per post read with a 3 million read monthly cap on pay-per-use (docs.x.com, verified 2026), a price that makes a 20-post feed refresh cost ten cents. Or it can use a third-party read API such as twitterapi.io, where the same 20-post call is $0.003 (twitterapi.io pricing, checked 2026), about 33 times less per post (0.005 / 0.00015 = 33.3).

Whoever runs the converter also decides what you see: how many items, how often they refresh, whether replies and reposts are included, and whether the feed exists next month. A hosted converter decides that for you; a public Nitter instance decides by going offline. Running the converter yourself moves every one of those decisions to your side, at a cost you can compute in advance. The rest of this page is that build.

The comparison below uses prices and limits as published when we checked them in 2026: RSS.app plan pages for the hosted converter, the Nitter README and our own instance probe for public Nitter, docs.x.com for the official API, and the twitterapi.io pricing page for the self-hosted column. The self-hosted costs assume one feed polled hourly with 20 posts per call; the cost section has the full grid.

Two readings of that table. If you need a handful of hourly feeds and do not care who hosts them, RSS.app's Basic plan is cheaper than polling the API yourself, and it is an honest product. If you need sub-hour freshness, more than 50 items, filtering logic, or a URL that will still resolve when a vendor changes plans, self-hosting wins, and it wins by a wide margin on cost against the official API. The incremental figure in the 100-feed row is explained in the cost section: a since_time search that returns nothing is billed the $0.00015 per-call minimum rather than 20 posts.

A feed is a list of recent items in reverse chronological order, which maps onto three twitterapi.io endpoints. All three take the API key in an X-API-Key header, return JSON with a tweets array plus has_next_page and next_cursor, and return about 20 posts per page (docs.twitterapi.io, checked 2026).

Use last_tweets for the common case, one account one feed; pass userId once you know it, since the docs recommend it for stability. Use advanced_search with queryType=Latest when the feed is a topic rather than a person, or when you want several accounts in one feed (from:NASA OR from:SpaceX OR from:esa) and therefore one call instead of three. Use list/tweets when you already curate an X list; note that its includeReplies defaults to true, the opposite of last_tweets, so set it explicitly. The response shape is the same across the three, which is why the server below has one XML builder and three two-line fetchers.

This is what one post looks like in the response, trimmed to the fields the feed uses. createdAt is in X's classic %a %b %d %H:%M:%S %z %Y format, url is the canonical post link, and author.userName is the handle; everything else (counts, entities, quoted_tweet, retweeted_tweet) is available if you want richer items.

RSS 2.0 is small. The specification maintained by the RSS Advisory Board requires three channel elements, title, link and description, and says of items that "all elements of an item are optional, however at least one of title or description must be present" (rssboard.org RSS 2.0 specification). Dates use RFC 822 format, which Python's email.utils.format_datetime produces; guid carries an isPermaLink attribute that defaults to true, so a post URL is the right value and lets readers de-duplicate across refreshes; ttl is an integer number of minutes a reader may cache the channel. The atom:link rel="self" element from RFC 4287's namespace is not required by RSS but the W3C validator recommends it, and most readers use it to fix a feed's own URL.

Two things the validator enforces that are easy to get wrong, because we got them wrong. First, RSS <author> must be an e-mail address, so putting @NASA there produces "Invalid email address"; the conventional fix is the Dublin Core dc:creator element. Second, channel-level elements such as lastBuildDate must come before the first <item>, or the validator reports "Misplaced Item". Our first draft of the builder below failed on exactly those two points and passed after the fix (W3C Feed Validator, checked 2026). Treat the validator as part of the build, not a final polish: a feed that fails it is usually still parsed by lenient readers but with missing dates or duplicated items.

The builder uses xml.etree.ElementTree, which escapes text and attribute values for you; the one place you escape manually is description, which RSS defines as entity-encoded HTML, so html.escape runs once and the XML serializer encodes it a second time. If you prefer Atom, the feedgen package (version 1.0.0 on PyPI, checked 2026) produces both formats from the same object model, at the cost of a dependency; the server on this page stays stdlib-only.

The complete server is the code block at the end of this article. It is http.server from the standard library with three routes, a per-feed cache, and conditional responses; here is the design, because the design is what keeps the bill predictable.

Polling cadence lives in the cache, not in a scheduler. The server never polls on its own. The first request for /user/NASA.xml calls the API, builds the XML, and stores it with an expiry of CACHE_SECONDS (default 900, fifteen minutes). Every request within that window, from any number of readers, gets the cached bytes. So the upstream cadence is at most one call per feed per interval, and a feed nobody reads costs nothing. The <ttl> element is set to the same interval so well-behaved readers do not ask more often than the cache changes.

Conditional requests are free. The response carries an ETag (a hash of the XML) and Last-Modified. A reader that sends If-None-Match with the current tag gets 304 Not Modified and no body; the check happens against the cache, so it never reaches the API. Most desktop and server-side readers (NetNewsWire, Miniflux, FreshRSS, Feedly's fetcher) revalidate this way. Set PUBLIC_BASE to the URL readers will use so the atom:link rel="self" matches the document location, which clears the one recommendation the validator still raised on our localhost test.

Errors are loud. If the API call fails, the server answers 502 with the message and keeps the last good copy out of the cache on purpose, so you notice. If you would rather serve stale content during an outage, keep the previous XML alongside the expiry and return it on exception; it is a four-line change.

Three URL shapes. /user/<handle>.xml maps to last_tweets with replies excluded, /search/<url-encoded query>.xml to advanced_search with queryType=Latest, and /list/<listId>.xml to list/tweets with replies excluded. The .xml suffix is cosmetic but helps readers that sniff the extension. Run it behind a reverse proxy with TLS (Caddy does this in two lines), or on any platform that gives you a public HTTPS URL. The commands below are the smoke test we ran.

Pricing basis: $0.15 per 1,000 posts, a minimum of $0.00015 (15 credits) per API call, 1 USD = 100,000 credits (twitterapi.io pricing, checked 2026). Assumptions: each call returns 20 posts, so a call costs 20 x $0.00015 = $0.003; the cache makes exactly one call per feed per interval; a month is 30 days (43,200 minutes). The last column is the incremental variant described below the table, assuming each feed gains 5 new posts a day.

The arithmetic is linear, so the useful observations are about the shape. Plain polling pays for 20 posts on every call whether or not anything is new, which is why a quiet account polled every 5 minutes costs the same $25.92 as a busy one. The incremental variant fixes that: instead of last_tweets, run advanced_search with from:<handle> since_time:<last check>; a call that returns nothing is billed the $0.00015 minimum rather than $0.003, and you pay $0.00015 for each genuinely new post. At 5 posts a day that is 8,640 x $0.00015 + 150 x $0.00015 = $1.32 a month at a 5-minute interval, a 20-fold saving. The trade is state: the server must keep the last 20 items per feed itself (a JSON file per feed is enough) and merge new posts into it, where the plain version is stateless. Grouping accounts with OR in one query cuts the call count further.

For scale, the official X API at $0.005 per post read would make the same hourly 20-post refresh 720 x 20 x $0.005 = $72 a month per feed before its 24-hour deduplication, which charges a resource once per UTC day however often it is returned (docs.x.com, verified 2026); the deduplicated figure depends on how many distinct posts the account produces and is well below $72 for quiet accounts, but each new post still costs 33 times more to read. Against hosted converters, the numbers say: for a few hourly feeds RSS.app's $8.32 plan is the cheaper purchase; for 15-minute freshness on more than a handful of feeds, the incremental self-hosted variant costs less than the $16.64 Developer plan and has no item cap.

Once the server has a public HTTPS URL, every consumer is a standard RSS subscriber. In a feed reader (NetNewsWire, Miniflux, FreshRSS, Feedly, Inoreader) add https://feeds.example.com/user/NASA.xml like any other feed; readers that honour ttl and ETag will refresh on your interval and get 304s in between. For Slack, the built-in RSS app (/feed subscribe <url>) posts each new item to a channel. For e-mail, point a digest service or a self-hosted tool such as rss2email at the feed. For automation, n8n's RSS Feed Read trigger, Zapier's RSS by Zapier, and Make's RSS module all accept the URL and expose the item fields (title, link, pubDate, description) as variables, which is often simpler than wiring those tools to the API directly.

Three refinements earn their place quickly. Filter in the server rather than the reader: a MIN_LIKES environment variable that drops items below a likeCount, or a word list that excludes promotional posts, turns a noisy account into a usable feed and costs nothing extra. Expand reposts and quotes: when a post carries retweeted_tweet or quoted_tweet, append that text to the description so the item makes sense out of context. And add <enclosure> or inline <img> tags from extendedEntities.media if your reader shows images; RSS 2.0 has had the <enclosure> element since the specification was written, and most readers render media from it.

What goes wrong, in rough order of frequency:

If you want the alerting side of this rather than a feed to read (a Slack message within a minute of a post, or a webhook that pushes posts to you), the tweet-notification and keyword-alerts guides linked below cover polling and webhook rules on the same endpoints; the feed server here is for the many tools that already speak RSS.