TweetBeaver is gone: every TweetBeaver function and how to get the same data today

TweetBeaver ran on the Twitter API through a standard OAuth app. The archived About page credits "TwitterOAuth by Abraham, the most popular PHP library for use with the Twitter OAuth REST API". Every search ran with the signed-in visitor's own access tokens, which is why the FAQ answered "Why must I sign in with Twitter?" with "TweetBeaver accesses Twitter data through the Twitter API which requires authorization in order to limit the number of searches made by each user." Rate limits were Twitter's per-user limits, and so was the cap on how much history it could return. The FAQ is blunt about it: "Why are there limits to how many tweets and favorites I can download? These limits are put in place by Twitter."

The FAQ also explains a detail people still remember: the authorization screen said TweetBeaver could post on your behalf. In the FAQ's words, "Some of TweetBeaver's functionality requires the read/write permission level despite never needing to post tweets on your behalf. If you're concerned you can create a separate account just for research, revoke access after using or just don't use the tool." Asked "Anything else planned for TweetBeaver?", the answer was "No"; asked "Can I contact TweetBeaver?", also "No". It was a one-person utility, and it was always going to stop the day the API it used stopped.

That day came in 2023. Twitter announced the end of free API access in February 2023 and cut it off in early April 2023; Engadget's report from that week lists apps that broke, including Social Bearing (covered below). The Wayback Machine shows TweetBeaver's full menu with the "TweetBeaver needs you to sign in with Twitter" banner in a March 2023 capture. The next capture, in May 2023, shows a single line: "Tweetbeaver has closed due to Twitter API changes". The same notice was still there in captures through 2024.

What the domain does now. We requested https://tweetbeaver.com, http://tweetbeaver.com and the old tool path https://tweetbeaver.com/getids.php in October 2026. All three returned HTTP 301 to an unrelated Vietnamese-language betting site. A Wayback capture from early 2026 shows the domain serving an unrelated Romanian-language content site. Neither has anything to do with the original tool, so do not sign in to anything on that domain expecting TweetBeaver.

The table follows the tile order of the last archived menu. Endpoint paths are relative to https://api.twitterapi.io; every call is a GET with an X-API-Key header and needs no X account, no OAuth app and no "Sign in with Twitter". The status column says how direct the replacement is: one call means a single endpoint answers the question, set means two list pulls plus an intersection you run in Python, walk means the answer sits on the last page of a newest-first list, and gone means there is no data source.

Ten tiles are one endpoint, four are a set operation, two are a walk and two are gone. Two of the one-call tiles also have free, no-login versions on this site: the Twitter ID finder for tiles 1 and 2, and the follow checker for tile 3. For a one-off lookup those are faster than writing code; the scripts below are for when you need hundreds of lookups or a CSV.

A mapping table says an endpoint exists. It does not say what comes back. So we ran the core TweetBeaver functions on 25 well-known public organization and media accounts in October 2026: @NASA, @BBCWorld, @Reuters, @AP, @nytimes, @WHO, @UN, @NatGeo, @CNN, @guardian, @WSJ, @TheEconomist, @esa, @SpaceX, @Microsoft, @Google, @github, @Spotify, @NBA, @FIFAWorldCup, @WWF, @INTERPOL_HQ, @bellingcat, @Wikipedia and @NWS. Between them they have 591,058,274 followers; the smallest has 346,535 (@INTERPOL_HQ), the largest 92,321,567 (@NASA).

For each account we made four calls: the profile (TweetBeaver tiles 1 and 8), the first timeline page (tile 6), the first page of followers and the first page of friends at 20 rows each (tiles 11 and 10). For five of them (@NASA, @Reuters, @WHO, @bellingcat, @NWS) we followed the timeline cursor to page 10. That is 145 calls, 1,400 posts and 1,021 user records. The table gives what came back and what each function costs per account, with the official X API's pay-per-usage price for the same read beside it.

Three things in that table matter for anyone replacing TweetBeaver. First, the per-call functions are effectively free at TweetBeaver's scale: resolving 1,000 handles to IDs is $0.18, and the median account's whole friends list is under a cent. Second, completeness was not the problem. Every page came back full except where the account had nothing more to give, and the one short follower page (19 of 20 for @TheEconomist) still pointed to a next page, which is what the docs mean by "up to" a page size. Third, the cost of a full follower export is driven entirely by follower count, which is the subject of the next chart.

The bio and location shares are worth a sentence for OSINT work. Among the newest followers of these 25 organizations, only about a third had any bio and a quarter had a location string. Among the accounts the organizations themselves follow, 96.2% had a bio. A big account's newest followers are mostly new, sparse profiles, so a follower list on its own says little about an account's real audience; the friends list says much more about who the account pays attention to.

One timing note: we called the endpoints through the twitterapi.io MCP server, a read-only tool client, and that client adds its own overhead, so we do not report per-call latency from this run. The "calls" and "hours at 20 req/s" columns are arithmetic: the call count divided by the paid rate limit of 20 requests per second, which is the floor on wall-clock time for a single key at that tier.

TweetBeaver's "Download a user's timeline" had a hard ceiling. The v1.1 timeline endpoint it called returned only a user's most recent posts, the limit twint's README summed up as "Twitter API limits to last 3200 Tweets only". People still think of a timeline export in those terms, so we measured what a fixed number of pages actually covers.

On the first page alone, the 20 newest posts spanned a median of 4.71 days across the 25 accounts. The range was huge: @Reuters' 20 newest posts covered about 1.2 hours, @WWF's covered 121 days. Three accounts had gone quiet: @guardian's newest post dates from November 2024 (its bio says the account is archived), @Wikipedia's from February 2025 and @bellingcat's from January 2026. The endpoint still returned their latest 20 posts; a timeline export of a quiet account simply ends in the past.

The 10-page walks make the point sharper. Each of the five accounts returned exactly 20 posts on every page, 200 in total, with no duplicate IDs and has_next_page still true after page 10. But 200 posts covered 0.74 days of @Reuters (about 18 hours), 57.7 days of @NWS, 61.6 days of @WHO, 127.9 days of @NASA and 457.2 days of @bellingcat, back to October 2024. For a newsroom account, TweetBeaver's 3,200-post ceiling is about two weeks of output; for a research account it is years.

So budget a timeline pull in posts, not in days. A 3,200-post export is 160 pages and $0.48 whatever the account. If what you actually need is a date range ("everything @WHO posted last month"), use advanced_search with from:WHO since:YYYY-MM-DD until:YYYY-MM-DD (UTC, until is exclusive) instead of paging the timeline from today backwards: you pay only for posts inside the window. The search operators reference linked below covers the date and type filters.

Two smaller findings from the sample. Retweets were 15.2% of first-page posts overall but very uneven: 14 of 20 on @UN, 12 of 20 on @Google, none on most news accounts. Replies were 0% because last_tweets leaves replies out unless you pass includeReplies=true, which is the switch to flip if you want TweetBeaver's full timeline behavior.

These four tiles are one endpoint each and cost the least of anything on the menu. GET /twitter/user/info?userName=NASA returns the user object in data with camelCase fields: id, userName, name, createdAt, followers, following, statusesCount, favouritesCount, mediaCount, location, description, isBlueVerified, protected, pinnedTweetIds and more (25 fields in the recorded response). id is TweetBeaver's "Convert @name to ID" answer, and the rest is "Get a user's account data". An unknown handle does not 404: it comes back as HTTP 200 with status: "error", msg: "user not found" and data: null, so check data before using it.

"Convert ID number to @name" and "Bulk lookup user account data" are GET /twitter/user/batch_info_by_ids?userIds=11348282,742143, which returns users[] with the same camelCase fields. It bills by the number of users returned: 18 credits per user below 100, 1 credit per user at 100 or more (see the pricing page at /pricing). The docs do not state a maximum batch size, so the script uses batches of 100; a batch where a few IDs are suspended returns fewer than 100 users and is billed at the 18-credit rate. In our run, @NASA resolved to 11348282 and @BBCWorld to 742143, the same IDs those accounts have had since 2007; an ID is the identifier to store, because handles change.

Prices side by side: 18 credits is $0.00018 a profile, or $0.18 per 1,000. The official X API charges $0.010 per user read (docs.x.com pricing), $10 per 1,000, about 55 times more. For a one-off lookup without code, the free ID finder tool on this site does tiles 1 and 2 in the browser.

"Download a user's timeline" is GET /twitter/user/last_tweets?userName= followed by cursor= pages. Two shape details trip people up: the posts are nested at data.tweets, while has_next_page and next_cursor sit at the top level; and errors come back as status: "error" with the reason in msg. Each post carries id, createdAt (for example Wed Oct 14 22:03:08 +0000 2026, always UTC), text, likeCount, retweetCount, replyCount, quoteCount, viewCount, bookmarkCount, lang, isReply, url, and the full retweeted_tweet or quoted_tweet object when there is one. TweetBeaver's CSV had fewer columns than that.

"Search within a user's timeline" becomes a search with the author operator: GET /twitter/tweet/advanced_search?query=from:NASA artemis&queryType=Latest. This is better than TweetBeaver's version in one important way. TweetBeaver searched only the posts it could download, so a term older than the 3,200-post window was invisible. Search is not tied to that window, and you can add since: / until: to scope it. The response is flat: tweets, has_next_page, next_cursor, with no status wrapper.

"Find conversations between two users" is one query: (from:NASA to:esa) OR (from:esa to:NASA). It returns the replies each account sent the other. To pull a whole thread around one of those replies, GET /twitter/tweet/thread_context?tweetId= returns the chain. Billing for all three is the same: 15 credits per post returned, so a full page of 20 is $0.003 and an empty page is billed the 15-credit minimum ($0.00015).

TweetBeaver called the accounts a user follows "friends", the old v1.1 name. Here they are followings. Both lists are GET /twitter/user/followers and GET /twitter/user/followings with userName, cursor and pageSize (20 to 200, default 200). Results are newest first: "Sorted by follow date, most recent followers appear on the first page" (docs.twitterapi.io). Each item is snake_case, unlike the profile endpoint: id, screen_name, name, created_at, followers_count, friends_count, statuses_count, location, description, protected, verified.

Page size is also the price lever. The docs price these lists at 1 credit per user for a full 200-user page, 2 credits for 100 to 199 and 3 credits for 20 to 99, with a 60-credit minimum per call. So always ask for 200 unless you only want a peek: a 200-user page is $0.002, while ten 20-user pages for the same 200 users are $0.006. Our study used 20-user pages on purpose, to keep the sample small, and paid $0.0006 a page.

If you need only the IDs (for set operations, or to diff a list over time), GET /twitter/user/followers_ids returns up to 5,000 IDs per call, and on full 4,000 to 5,000-ID pages the price drops to 0.45 credits per ID. For @AP that is $74.35 for the whole list instead of $165.23 with profiles. You can resolve only the IDs you care about afterwards with batch_info_by_ids.

There is also a no-code route on this site for one specific case: the export-following-list tool exports an account's following list to a file from your dashboard credits. Use it when you need a single list once; use the script when you need many accounts, a schedule or other columns.

"Check if two accounts follow each other" has a dedicated endpoint. GET /twitter/user/check_follow_relationship?source_user_name=a&target_user_name=b returns data.following (a follows b) and data.followed_by (b follows a) for 100 credits, $0.001 per check. The free follow checker tool on this site runs the same check in the browser.

The other four tiles in this group were always set operations; TweetBeaver just ran them on its server. Common followers of A and B is followers(A) & followers(B). Common friends is followings(A) & followings(B). "Accounts in a user's followers and friends lists" (mutuals) is followings(A) & followers(A). "Accounts followed by one user that also follow another named user" is followings(A) & followers(B). Match on the numeric id, never on the handle, because handles change and IDs do not.

The cost is whatever the two lists cost, and that is where these tools need care. Friends lists are small: the median account in our sample follows 847 accounts, five calls and under a cent. Follower lists can be enormous: across our 25 accounts, pulling every follower ID once would cost $2,659.76, and with full profiles $5,910.58. So the script below uses the cheap followers_ids endpoint for the follower side, and checks the follower count with one profile call before it starts, refusing to run past a dollar limit you set. For two accounts with a few thousand followers each, a common-followers query is a few cents; for two news organizations it is a budget decision.

This is also where TweetBeaver's design hid a limit. Its common-followers tools ran on Twitter's per-user rate limits, so on large accounts they returned partial results or stalled. Here the limit is your requests-per-second tier (20 per second once paid) and your budget, and the script tells you both before it spends anything.

These two tiles answer an investigator's favorite question: who were the earliest followers, or the first accounts this one followed? Both lists come back newest first, so the answer is on the last page, and there is no endpoint that starts from the oldest end. The only way to get there is to walk every page.

For friends lists that is cheap and quick. @bellingcat follows 75 accounts, one call. @Spotify follows 15,552, 78 calls and about $0.16. For follower lists it depends entirely on size. From the study's real counts: the first 25 followers of @bellingcat (716,560 followers) means 3,583 calls and about $7.17; of @INTERPOL_HQ (346,535), 1,733 calls and about $3.47; of @NASA (92,321,567), 461,608 calls, about $923, and at least 6.4 hours at 20 requests per second. The script prices the walk from the profile first and stops if it would cost more than you allow.

Treat the result with care. The list reflects current follows only: an early follower who later unfollowed, or whose account was deleted or suspended, is not on the last page any more. TweetBeaver had the same blind spot, because it read the same kind of list.

"Download a user's favorites" and "Search within a user's favorites" were among TweetBeaver's most used tiles; its meta keywords listed "favorites" next to "timeline". They read the public likes list, which in 2023 was still visible on anyone's profile. In June 2024 X made likes private: you can see your own Likes tab, and nobody else's. Like counts on each post remain public.

So there is no honest replacement. No read endpoint on twitterapi.io returns another account's likes, and none appears in the endpoint manifest. The write-side /twitter/like_tweet_v2 likes a post as your own logged-in account; that is a different product and does not read anyone's history.

What you can still do: use likeCount on posts, which every tweet object carries, to see how much engagement a post drew. To see who amplified a post, GET /twitter/tweet/retweeters?tweetId= lists the accounts that reposted it and GET /twitter/tweet/quotes?tweetId= returns the quote posts. Those two lists were never in TweetBeaver, and they cover much of what investigators used favorites for: showing which accounts push a given message.

TweetBeaver was not the only casualty. The same queries that bring people here ("social bearing", "tinfoleak", "twayback") are for tools from the same toolkits that stopped working for the same reason. We checked each one in October 2026. URLs are given as text for reference; the status column is what a plain request returned.

The pattern is the same in every row. These tools were thin front ends on the free Twitter API, and when the free API went in 2023 their makers had a choice between paying for data and shutting down. Most shut down, and the code that survives on GitHub calls endpoints that no longer exist. Rebuilding on a paid read API costs a fraction of a cent per lookup, but it is a decision you make for yourself; nobody is maintaining a free front end for you any more.

TweetBeaver was free because Twitter's API was free to it. The replacement is pay-per-call, so it helps to price a realistic month. Take an investigator who, each month, resolves 2,000 handles, exports 50 timelines of 3,200 posts, pulls 200 friends lists and 20 follower lists of accounts with about 50,000 followers, and runs 500 follow checks.

The arithmetic uses 18 credits per profile, 15 per post, 1 per list user at pageSize 200 and 100 per follow check ($1 = 100,000 credits), against $0.010 per user read, $0.005 per post read and $0.010 per follower or following read on the official X API (docs.x.com pricing). For posts that is about 33x cheaper per read than the official X API pay-per-use rate; for list users the gap is far wider. The official API also caps pay-per-usage at 3 million post reads a month.

Two practical limits apply on our side. Before your first payment the rate limit is 0.2 requests per second, enough to try every script on this page but not to walk a large follower list; once paid it is 20 per second, which is what the hour estimates above assume. Up to $1 in free credits for new accounts that pass the bot check; expires after 31 days; see /pricing.

Question. If you rebuild each TweetBeaver function on twitterapi.io read endpoints, what does each call actually return for well-known public accounts, how far back does a timeline reach, and what does each function cost per account?

Sample. 25 public organization and media accounts chosen before collection (listed in the study section), no private individuals. For each: one profile call, the first timeline page, the first followers page and the first friends page at 20 rows. For a pre-chosen subset of five, timeline pages 2 to 10. Totals: 145 calls, 1,400 posts, 1,021 user records. One follower call (@guardian) failed on the first attempt with a proxy error and succeeded on one retry.

Window and client. One collection pass in October 2026, through the twitterapi.io MCP server's read-only tools. That client returns a trimmed view of each response (profiles with 11 or 12 fields, list items with ID, handle, display name and, when set, bio and location), so the field counts on this page come from the full recorded REST responses, and the bio and location shares are computed from the trimmed view, in which an empty field is simply absent. The client's overhead makes per-call latency unmeasurable, so we report call counts and the rate-limit floor instead.

Costs. Every dollar figure is arithmetic: real counts from the run (rows returned, each account's follower, following and post counts) multiplied by published prices from docs.twitterapi.io and docs.x.com. We did not run a full follower export of any account; the export costs are what one would cost.

What the sample cannot show. It covers large organization accounts, so follower pages are dominated by very new followers and timeline depths reflect organizational posting rates; a personal or niche account will look different. Ten pages is not the end of any timeline we walked, so this run does not tell you how far back last_tweets can go in total. And the page sizes are the docs' maximums, not guarantees: one page came back one row short.

Privacy. Follower and following records were stored without handles, names, IDs or text, and only aggregate shares are published. The raw sample (organization post IDs and counts, no text), the analysis script and the results file are in the site repository under data/studies/tweetbeaver/.