What the Twttr API does and who it is for
The Twttr API, provided by KooSocial, wraps Twitter's (now X's) internal data and exposes it through a conventional REST interface. It is aimed at developers who need Twitter data — tweet content, user profiles, social graphs, search results, trending topics, community activity, and job listings — without having to navigate the official X API's increasingly restrictive access tiers.
With close to 20,000 marketplace subscribers and a popularity score of 9.9 out of 10, this API has clearly found a wide audience. The 99% average success rate is a meaningful signal of reliability, though the 936 ms average latency is worth factoring in for any use case where response time is a product requirement.
Endpoint overview
The API exposes 50 endpoints in total. The 40 documented here fall into several logical groups:
User and profile data
The /user endpoint retrieves a full user object by username, which is important because most other endpoints that accept a user identifier expect the internal rest_id, not the public handle. The typical flow is: look up a username with /user, extract the rest_id, and feed that ID into downstream calls. /get-users and its companion /get-users-v2 support bulk lookups by ID. /org-affiliates exposes organizational affiliates for a given account, which is useful for mapping corporate Twitter presences.
Social graph
Followers and followings are accessible via /followings and /following-ids (by username). User replies, media posts, liked tweets, and the main tweet timeline each have dedicated endpoints — /user-replies, /user-replies-v2, /user-media, /user-likes, and /user-tweets respectively.
Tweet and post data
Individual tweet details are available at /tweet-v2 (the current version) and /tweet-by-ids for batch retrieval. The older /tweet endpoint is marked deprecated. Post-level interactions are split across /comments, /comments-v2, /quotes, /retweets, and the now-deprecated /likes.
Search and discovery
/autocomplete implements Twitter's search query autocomplete, useful for building search UIs. Full search presumably lives in other endpoints (the full set of 50 is not entirely shown here). Trending content is reachable via /trends-locations and /trends-by-location, which together let you first discover which geographic locations have trend data and then pull the actual trends for a specific place.
Communities, lists, and spaces
Twitter Communities are well covered: /search-community, /community-topics, /explore-community-timeline, /community-members, /community-moderators, /community-tweets, /community-about, and /fetch-popular-community. Lists have their own set: /search-lists, /list-details, /list-timeline, /list-followers, and /list-members. Twitter Spaces details are available via /spaces.
Jobs
Twitter's job-posting feature is also surfaced — /jobs-search, /job-details, and /jobs-locations-suggest for location autocomplete. This is a niche but useful addition for applications that aggregate professional opportunities.
Pricing breakdown
All plans are billed monthly with a hard request cap and a per-second rate limit.
| Plan | Price / month | Requests / month | Rate limit |
|---|---|---|---|
| BASIC | $1 | 1,000 | 5 req/sec |
| PRO | $25 | 100,000 | 10 req/sec |
| ULTRA | $80 | 500,000 | 10 req/sec |
| MEGA | $150 | 1,500,000 | 10 req/sec |
The BASIC tier at $1 and 1,000 requests per month is best treated as an evaluation plan. At 1,000 requests, a small personal project might get by, but any real feature — a user profile page that pulls profile + tweets + followers — can easily consume 3–5 requests per page load, exhausting the monthly quota in a few hundred visits.
PRO at $25 gives a 100× increase in quota and doubles the rate limit to 10 requests per second. This is the realistic entry point for a production application with moderate traffic. At 100,000 requests per month, you have roughly 3,300 requests per day, which supports a modest application comfortably.
ULTRA and MEGA make sense when you are doing bulk data collection — crawling timelines, indexing communities, or running analytics pipelines. At $80 for 500,000 requests, the per-request cost drops to $0.00016, and MEGA pushes that further to $0.0001 per request across 1.5 million monthly calls.
Practical use cases
- Social listening tools: Combine
/search,/trends-by-location, and/comments-v2to monitor brand mentions, track sentiment on trending topics, or surface emerging conversations in a specific region. - Profile and analytics dashboards: Use
/user,/user-tweets,/user-media,/user-replies, and the social graph endpoints to build a comprehensive profile analytics view for an account. - Community and list monitoring: The community and list endpoint groups let you build tools that track activity within specific Twitter Communities or curated lists — useful for niche interest aggregators.
- Job aggregation: The jobs endpoints expose Twitter's job listings, which can be incorporated into broader job search platforms alongside other sources.
- Autocomplete and search UX: The
/autocompleteendpoint is directly useful for building search interfaces that mimic Twitter's own typeahead behavior.
Limitations and things to check before integrating
Latency: A 936 ms average latency is noticeable. For synchronous, user-facing requests — especially on mobile — you will want to consider caching strategies or background pre-fetching. If your application surfaces real-time data, test latency under your specific usage pattern before committing.
Deprecated endpoints: Several endpoints are explicitly marked deprecated — /tweet, /likes, /user-likes, /get-users-v2. Plan to use their V2 or current counterparts from the start to avoid migration work later.
Third-party API risks: As an unofficial wrapper around Twitter/X's internal APIs, the Twttr API is subject to changes in Twitter's underlying platform without prior notice. Changes to Twitter's internal data structures or access controls could affect endpoint behavior. Factor this dependency risk into any production architecture.
Rate limits: The BASIC tier's 5 req/sec cap is fairly low if you are fanning out to multiple endpoints per user action. Upgrade to PRO or above for anything that involves concurrent or burst requests.
Request counting: Because many workflows require chaining calls (resolve username → get rest_id → fetch timeline), your effective cost per feature is often several requests, not one. Budget accordingly when choosing a plan.
Getting started
The API is available through the RapidAPI marketplace. Subscribe to the BASIC plan to get credentials and explore the endpoints. The recommended first call is GET /user with a known Twitter username to understand the response shape and extract the rest_id you will need for most follow-on requests. From there, you can chain into /user-tweets, /followings, or whichever data type your application needs. For support, KooSocial can be reached at [email protected].
