Twitter (X) Follower Tracking via API — A Developer Guide
Tracking follower changes on Twitter (X) — who followed, who unfollowed, who an account is following, growth rate over time — sounds simple. In practice, it's one of the most rate-limit-constrained operations on the entire X API surface, and the path you choose to handle that constraint determines whether your product can scale to 100 accounts or stays stuck at 5. If the reason you are watching for new followers is to greet them, our Twitter (X) welcome message guide covers the status of the retired welcome-message API, the eligibility check and the two ways to send the DM.
This guide is the developer version. It covers the X API endpoints actually available for follower tracking (and the 15-requests-per-15-minutes cap on the official follower endpoints), the architectural patterns that work in production (snapshot diffs vs change-events vs hybrid), a runnable Python pipeline that handles the rate-limit dance, and the cost economics of tracking follower data at scale via the official X API vs a third-party path.
If you're building audience analytics, growth tools, social CRM, or competitive intelligence around Twitter follower data, this guide gives you the realistic integration shape — including the parts that don't fit on a marketing page.
If you searched for a Twitter follower tracker, a way to track new followers on Twitter, or an unfollow tracker you can run through an API, this is the build-it-yourself version of all three. Tracking new followers and catching unfollows are the same snapshot-and-diff job viewed from two sides, and monitoring Twitter followers across many accounts is that job on a schedule; the patterns below cover each case without paying for a separate tool per question.
The X API follower endpoints — what's available and what it costs
Three endpoints get used in follower tracking. They're all rate-limit-constrained on the official path, and the constraints determine your architecture.
/2/users/:id/followers — list a user's followers. Returns 1,000 followers per page. Official rate limit: 15 requests per 15 minutes per user-context auth. So you can read up to 15,000 followers per 15 minutes per OAuth context. To list a 1M-follower account in full, that's about 17 hours of continuous polling at maximum allowed rate.
/2/users/:id/following — list who a user is following. Same 15/15min cap.
/2/users/by — batch-resolve up to 100 user_ids → user objects. Per-call lookup of profile data (display name, bio, follower count). Higher rate limits but still per-15-min.
TwitterAPI.io equivalent:
/twitter/user/followers — same data, no 15-min caps: the only limit is 20 requests per second once you've paid (0.2 before your first payment). Pages hold 200 followers, so listing a 1M-follower account is about 5,000 calls, roughly 4 minutes at 20 requests/s instead of 17 hours.
/twitter/user/followings — same.
/twitter/user/batch_info_by_ids — batch user info, similar throughput.
The architectural implication. Official X API rate limits make full-graph snapshots of large accounts prohibitively slow. Most production trackers either restrict themselves to small accounts, or use a third-party path. TwitterAPI.io's higher page sizes + no 15-min caps make full-graph tracking economically and operationally viable at higher account counts.
Three architectural patterns — snapshots, change-events, hybrid
Pick the right pattern before writing code; the wrong one locks in cost and latency properties you can't easily fix.
Pattern A — Periodic full-graph snapshots. Every N hours/days, fetch the full follower list for an account; diff against the previous snapshot to find adds/removes. Simplest pattern; works well for accounts under 100K followers. Storage scales with snapshot frequency × accounts × follower count.
Pattern B — Change-event detection (incremental). Track only the most recent N followers (e.g., last 1,000); poll frequently; new entries are recent follows. Doesn't reliably catch unfollows for older relationships. Best for 'who's following me lately' use cases.
Pattern C — Hybrid (snapshot + change-stream). Take a full snapshot weekly; supplement with daily incremental polls of the most-recent-N to catch fast-moving follows. This is what most production tools do — full graph is your ground truth, change-stream is your real-time signal.
Anti-pattern: real-time follower-change webhooks. The X API doesn't expose follower-change events as a stream or webhook. Any third-party tool claiming 'real-time unfollow alerts' is polling under the hood — at whatever rate their architecture allows. The honest 'real-time' for follower changes is the polling cadence you can afford, not push semantics.
TwitterAPI.io quickstart — paginating a full follower list
Below is a working Python implementation that fetches a complete follower list for a target account using TwitterAPI.io, paginates through cursor tokens, and outputs JSONL with structured records.
Key implementation notes:
We use /twitter/user/followers with pageSize=200 to maximize per-call throughput.
We persist the cursor token across calls so a long pagination can resume after a crash.
The cost model: follower lists are billed per user returned, and on full 200-user pages that is 1 credit per follower, $0.01 per 1,000 (smaller pages cost 2–3 credits per follower). One full snapshot of a 1M-follower account is 5,000 pages, about $10. On the official X API, follower reads cost $0.010 each, so the same snapshot is 1,000,000 × $0.010 = $10,000, and the 15-requests-per-15-minutes limit stretches it to about 17 hours.
For ongoing tracking, the recommended cadence is one full snapshot weekly + daily 1k-row incremental polls for change detection: about 4,030,000 follower records per account per month at 1M followers (4 snapshots + 30 × 1,000), or roughly $40 on TwitterAPI.io vs roughly $40,300 on the official X API.
Follower growth rate — what it actually means and how to compute it
'Follower growth rate' gets quoted casually. For a useful metric, define it explicitly. Three definitions worth distinguishing:
1. Absolute net growth. Followers_today minus followers_30_days_ago. Easy to compute; misleading at the high end because absolute differences scale with account size (a 1M-follower account adding 10k followers is a different signal than a 10K-follower account adding 10k).
2. Percentage growth rate. Absolute_net / followers_30_days_ago. Better for cross-account comparison. Still misleading on accounts that lose followers — a -2% rate looks bad without context (campaign? algorithm change? tweet that went viral wrong?).
3. Daily follow/unfollow ratio. Daily_adds / daily_removes. Independent of account size; captures actual audience-acquisition health. Most useful for diagnosing what's actually happening on an account.
Production recommendation. Compute all three. Surface percentage growth + follow/unfollow ratio in the user dashboard; use absolute net for alerts (e.g., 'lost 5,000 followers today' is more actionable than '-2% in 30 days').
Cost economics — what tracking N accounts at full-graph cadence costs
Cost scales with: account count × follower count per account × snapshot frequency. Both paths bill per follower record returned, so the cleanest comparison is by follower records read per month (one 1M-follower account on weekly full snapshot + daily incremental is about 4M records a month):
On full pages the gap is about 1,000×: $0.01 vs $10 per 1,000 follower records. Small accounts return short pages (2–3 credits per follower below 200), which narrows it to roughly 330–500×. Add the 17-hour snapshot time on the official path and it is clear why teams tracking follower graphs at scale use a third-party path: the official rate limits make full-graph snapshots impractical for most realistic use cases.
The official path's positioning. The official X API is the right choice when (a) you have a regulatory requirement for first-party data access, (b) you specifically need enterprise-tier exclusives (PowerTrack, Audience API), or (c) your account count is small enough that the 17-hour snapshot time doesn't matter. For everything else, the third-party path's economics dominate. See our X API cost breakdown for the per-call math.
Operational notes — suspensions, deletions, ToS, latency expectations
Three operational notes for production follower trackers:
Account suspensions and deactivations. A tracked account can be suspended; user/info then returns HTTP 200 with data.unavailable: true and an unavailableReason, not an HTTP error. Treat as state, not error — log a target_account_suspended event and back off polling until the handle resolves. Same applies to deactivated user IDs in your follower list — handle them as 'user_id is no longer reachable' rather than as a data-pipeline error.
Follower-list latency. Both official and third-party APIs serve follower data with ~5-30 second latency relative to the live state. Don't expect 'real-time' follower changes; the closest you can get is fast polling, which has cost implications.
ToS compliance for downstream products. Public follower-list data is exposed via the public X API surface and is governed by the API ToS, not by per-user consent. For commercial products that profile individual users on top of follower data, additional data-protection regulations may apply in your jurisdiction (EU GDPR, California CPRA). Consult counsel on top of the API ToS.
What the data unlocks — analytics applications
Once follower-change data is in your pipeline, several downstream applications compose naturally:
Audience-growth diagnostics — Plot daily follow/unfollow ratio over time; correlate with tweet posting events. A drop in ratio that coincides with a specific tweet is highly diagnostic.
Audience overlap discovery — Cross-reference follower lists between accounts to find shared audience. Useful for partnership identification and competitive positioning.
Engagement-quality assessment — Compare an account's follower count growth against its engagement growth. If followers grow faster than engagement, you have growth quality concerns (bots, paid promotion, etc.).
Churn prediction (for paid social products) — Cohort-analyze followers by when they followed; predict which cohorts are likely to unfollow. The early-30-day-after-follow attrition curve is the highest-signal data point you can extract.
Influencer-network mapping — For high-follower accounts, the top-followers-by-follower-count subset effectively maps the account's influence network in their space.
# pip install requests
import json
import time
import pathlib
import requests
API_KEY = "YOUR_TWITTERAPI_IO_KEY"
BASE = "https://api.twitterapi.io"
HANDLE = "elonmusk" # change to whoever
PAGE_SIZE = 200 # TwitterAPI.io max per page
STATE_DIR = pathlib.Path(".state")
STATE_DIR.mkdir(exist_ok=True)
OUT = STATE_DIR / f"{HANDLE}_followers_{int(time.time())}.jsonl"
CURSOR_FILE = STATE_DIR / f"{HANDLE}_followers_cursor.txt"
headers = {"X-API-Key": API_KEY}
def resolve_uid(handle):
r = requests.get(f"{BASE}/twitter/user/info",
params={"userName": handle}, headers=headers, timeout=10)
r.raise_for_status() # user/info answers HTTP 200 either way; the outcome is in the body
body = r.json()
data = body.get("data") or {}
if body.get("status") != "success" or data.get("unavailable"):
return None # not found, or suspended (data["unavailableReason"])
return str(data["id"])
def fetch_full_follower_list(uid):
"""Paginate the full follower list. Resume from cursor if present."""
cursor = CURSOR_FILE.read_text().strip() if CURSOR_FILE.exists() else None
total = 0
page = 0
with OUT.open("a") as f:
while True:
params = {"userName": HANDLE, "pageSize": PAGE_SIZE}
if cursor:
params["cursor"] = cursor
r = requests.get(f"{BASE}/twitter/user/followers",
params=params, headers=headers, timeout=15)
r.raise_for_status()
body = r.json()
users = body.get("followers", [])
cursor = body.get("next_cursor")
for u in users:
f.write(json.dumps({
"follower_id": u["id"],
"username": u.get("userName"),
"name": u.get("name"),
"follower_count": u.get("followers_count"),
"verified": u.get("verified"),
"fetched_at": time.time(),
}) + "\n")
total += 1
page += 1
print(f"page {page}: {len(users)} users, total {total}")
if cursor:
CURSOR_FILE.write_text(cursor)
if not cursor or not users:
break
time.sleep(0.2) # gentle pacing
if CURSOR_FILE.exists():
CURSOR_FILE.unlink() # done
print(f"\nDone. {total} followers fetched into {OUT}")
if __name__ == "__main__":
uid = resolve_uid(HANDLE)
if uid is None:
print(f"Account @{HANDLE} not found / suspended.")
else:
fetch_full_follower_list(uid)
Questions readers ask
What's the rate limit on the X API follower list endpoint?
15 requests per 15 minutes per OAuth context on the official X API's /2/users/:id/followers, returning 1,000 followers per page. That's 15,000 followers per 15 min, or about 17 hours of continuous polling to enumerate a 1M-follower account. TwitterAPI.io has no 15-minute window: it returns 200 followers per page at up to 20 requests per second once you have paid, so the same 5,000 pages take minutes rather than hours.
Can I get real-time unfollow notifications via API?
No — there's no follower-change webhook on the X API. The closest you can get is fast polling (every few minutes). Any third-party tool that claims 'real-time unfollow alerts' is polling under the hood at whatever cadence their architecture allows. Honest 'real-time' is the polling frequency you can afford to run.
How much does it cost to snapshot 100 accounts' follower lists weekly?
Follower lists are billed per record returned. On TwitterAPI.io, full 200-user pages cost $0.01 per 1,000 followers, so one weekly snapshot of a 1M-follower account is about $10 (about $40/month for four), and 100 such accounts is about $4,000/month. On the official X API at $0.010 per follower read, the same workload costs about $4,000,000/month and takes much longer per snapshot because of the 15-minute rate limit. For accounts with 10K followers, divide by 100.
What's the best way to compute follower growth rate?
Compute three metrics: absolute net growth (followers today - followers N days ago), percentage growth rate (net / followers N days ago), and follow/unfollow ratio (daily adds / daily removes). Each surfaces different signal — net is most actionable for alerts, percentage is best for cross-account comparison, ratio is best for audience-acquisition diagnosis.
Can I track unfollows without doing a full snapshot every time?
Partially. Pattern B (incremental change detection) catches recent follows reliably but misses unfollows for older relationships. To catch all unfollows you need periodic full snapshots — recommended cadence is weekly full + daily incremental hybrid. Storing snapshots compactly (just the user_id set, ~25 bytes per follower) keeps storage cost low even at 1M-follower scale.
What if a tracked account gets suspended mid-pagination?
Persist the cursor token to disk between pages (the Python script does this). When user/info reports the handle as unavailable (data.unavailable: true, still HTTP 200), log a target_account_suspended event, back off polling, and resume from the saved cursor when the handle resolves. Don't lose your pagination state to operational errors.
Continue
- X API — TwitterAPI.io coverage hub
- Twitter account views tracking — sibling metric-tracking guide
- Twitter monitoring — broader architecture patterns
- X API cost breakdown — per-call rate math at scale
- Twitter rate-limit exceeded — official cap math at scale
- TwitterAPI.io pricing — per-call rates
- Twitter (X) welcome message: API status and how to greet new followers by DM
- 01Twitter (X) Statistics 2026: Attributed Figures and First-Hand Data on the Biggest Accounts
- 02Twitter (X) to SMS: Get a Text Message When an Account Posts
- 03Tweet Hunter (TweetHunter) Review: What It Automates, What It Costs, and the API Route for the Data Half
- 04How to Search Twitter (X) for Images: Operators, What They Return, and the API Route
- 05SOCMINT on Twitter (X): What Social Media Intelligence Is, and a Worked Method
- 06Bill Ackman on Twitter — A Tracking Guide for Financial Analysts
- 07Michael Saylor on Twitter — A Tracking Guide for Crypto Traders
- 08Twitter (X) Bulk Unfollow + Follower Remover — API Guide
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key