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.
This guide is the developer version. It covers the X API endpoints actually available for follower tracking (and the brutal 15 followers/page × 15 pages/15 min cap on the official path), 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.
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 (same on Basic and Pro tiers). 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, spending-limit control instead of 15-min caps. Page size up to 5,000 followers/page. Listing a 1M-follower account at max throughput is roughly 200 calls = 30 minutes instead of 17 hours.
- /twitter/user/followings — same.
- /twitter/user/info — 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 count=5000 to maximize per-call throughput.
- We persist the cursor token across calls so a long pagination can resume after a crash.
- The cost model: about $0.00015 per call × 200 calls for a 1M-follower account = $0.03 for one full snapshot of a 1M-follower account. On the official X API: 200 calls × $0.005 = $1.00 per snapshot AND it takes 17 hours instead of 30 minutes.
- For ongoing tracking, the recommended cadence is one full snapshot weekly + daily 1k-row incremental polls for change detection — total cost per account per month ≈ $0.50 at 1M followers.
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. Realistic numbers for tracking 10 / 100 / 1,000 accounts at 1M average followers, weekly full snapshot + daily incremental:
At 1,000 tracked accounts the gap is roughly 33× — $750 vs $25,000/month. Combine that with the 17-hour-vs-30-minute snapshot time-to-completion difference and the operational impact is significant. Production teams tracking follower graphs at scale almost universally end up on a third-party path because the official path's 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](/blog/x-api-cost-breakdown-2026).
Operational notes — suspensions, deletions, ToS, latency expectations
Three operational notes for production follower trackers:
- Account suspensions and deactivations. A tracked account can be suspended; the API will 404 the handle. 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 = 5000 # TwitterAPI.io max
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)
if r.status_code == 404:
return None
r.raise_for_status()
return str(r.json()["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 = {"userId": uid, "count": 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().get("data", {})
users = body.get("users", [])
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"),
"verified": u.get("isVerified"),
"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 equivalent strict 15-minute cap and supports larger page sizes (up to 5,000 followers/page) — a full 1M-follower snapshot takes about 30 minutes instead.
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?
On TwitterAPI.io at $0.00015/read, tracking 100 accounts (1M average followers) with weekly snapshots + daily incremental polls costs roughly $75/month. On the official X API at $0.005/read, the same workload costs about $2,500/month — and takes much longer to complete each snapshot due to the 15-min rate limit. The 33× gap compounds at scale.
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 the API 404s the handle, 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
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key