Twitter (X) Profile Analytics — How to Pull User Metrics via API
Twitter (X) profile analytics covers the per-user metrics displayed on every X profile page — follower count, following count, listed count, tweet count, verified status, created-at date. Pulling those programmatically is a foundational dev task for analytics products, monitoring dashboards, batch ETL into a warehouse, or research datasets.
This guide walks the three practical Python paths in 2026 with runnable code, per-call cost from each provider, and the cost ratio derivable from the two cited pricing pages. The pricing numbers come from twitterapi.io/pricing and docs.x.com/x-api/getting-started/pricing, both verified June 2026.
What 'profile analytics' actually returns
Every X user profile carries a small public-metrics record. The field set is standardized across providers (they all wrap the same underlying X public surface):
- followers_count — current follower count
- following_count — accounts the user follows
- listed_count — public lists that include this user
- tweet_count — lifetime tweet/post count
- verified — boolean for the X verified badge
- created_at — account creation timestamp
Some providers also surface description, location, pinned_tweet_id, public_metrics as a nested object. The field set you get depends on which fields you request in the call.
Path 1 — twitterapi.io `/twitter/user/info`
twitterapi.io's profile read is at https://api.twitterapi.io/twitter/user/info with userName as the query parameter. Authentication is X-API-Key header. Pricing per twitterapi.io/pricing: $0.00018 per returned profile (18 credits at 1 USD = 100,000 credits).
Pick this when you need profile reads at scale — building a dashboard that displays many users' metrics, doing batch refresh of tracked accounts, or running analytics across thousands of profiles.
import os, requests
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
def get_profile(username: str) -> dict:
"""GET /twitter/user/info — profile lookup by handle."""
r = requests.get(
f"{BASE}/twitter/user/info",
headers=HEADERS,
params={"userName": username},
timeout=10,
)
r.raise_for_status()
return r.json()
profile = get_profile("twitterapi_io")
print(f"followers: {profile.get('followers_count')}")
print(f"following: {profile.get('following_count')}")
print(f"tweets: {profile.get('tweet_count')}")
print(f"verified: {profile.get('verified')}")
Path 2 — X official via xdk / Tweepy
X's official path is /2/users/by/username/{username} with user.fields=public_metrics,verified,created_at,description. xdk and Tweepy both wrap this endpoint and bill at the same X API rate.
Pricing per docs.x.com/x-api/getting-started/pricing: $0.010 per profile read. 24-hour UTC dedup window — fetching the same profile twice in the same UTC day is one charge.
Pick this when you're already on the X bill (you also write posts or read tweets), so the marginal profile read rides on the same auth.
# pip install tweepy
import tweepy
client = tweepy.Client(bearer_token="YOUR_X_BEARER")
resp = client.get_user(
username="twitterapi_io",
user_fields=["public_metrics", "verified", "created_at", "description"],
)
user = resp.data
pm = user.public_metrics
print(f"followers: {pm['followers_count']}")
print(f"following: {pm['following_count']}")
print(f"tweets: {pm['tweet_count']}")
print(f"verified: {user.verified}")
print(f"created: {user.created_at}")
Path 3 — Raw `requests` + bearer (no library)
If you don't want a library dep, plain HTTPS works. Auth is the same bearer token from the X Developer Console; you wire pagination + retries yourself.
Useful for single-call embedded scenarios (Lambda, edge worker) or when shipping a Python library dep isn't worth it.
import os, requests
HEADERS = {"Authorization": f"Bearer {os.environ['X_BEARER']}"}
def get_profile_raw(username: str):
r = requests.get(
f"https://api.x.com/2/users/by/username/{username}",
headers=HEADERS,
params={"user.fields": "public_metrics,verified,created_at,description"},
timeout=10,
)
r.raise_for_status()
return r.json()
print(get_profile_raw("twitterapi_io"))
Side-by-side comparison — 3 paths, 5 dimensions
Same job (fetch one user's public metrics) framed across the three paths. Costs are derived from each provider's published pricing page.
Three practical patterns: (a) per-profile cost ratio compounds — $0.010 / $0.00018 = ~55.5× per profile read; (b) X official's 24h UTC dedup is a real saving if you re-poll the same handles many times per day on the X surface; twitterapi.io has no analogous dedup, so cache your own results client-side; (c) most teams pick by which auth they already maintain.
Batch profile fetching — practical patterns
Batching: both providers support multiple user lookups per call. twitterapi.io's /twitter/user/batch_info_by_ids (or sequential calls) work for batch lookup by ID. X official's /2/users supports up to 100 IDs or usernames per call. Use larger batches to reduce HTTP overhead.
Polling cadence: profile metrics change slowly compared to tweet metrics (follower counts shift on the order of minutes-to-hours, not seconds). For most analytics workloads polling every 1-6 hours is more than sufficient. Daily snapshots work for trend monitoring.
Storage: persist the snapshot with the timestamp so you can compute delta-per-day (follower velocity) — that's the operationally interesting signal. A simple (user_id, captured_at, followers_count, following_count, tweet_count) row layout works.
Rate handling: 429s happen. Wrap each call with retry-on-429 + jittered backoff. Treat 5xx the same way.
Picking a path — the decision rule
Tracking many profiles at any meaningful volume on a per-call budget? → twitterapi.io. $0.00018/profile compounds favorably against X official's $0.010 — for 10,000 monthly profile reads the bill is $1.80 vs $100 (math from cited rates).
Already paying X for credits because you write or read tweets? → use X official; marginal profile read cost rides on the same auth + bill. The 24h UTC dedup makes re-polling cheaper in same-day workloads.
One-off script, single profile? → either works. Costs at this scale are pennies; pick by which auth is easier for you to set up.
Most production analytics teams pair the two: twitterapi.io for the broad batch-refresh layer + X official for any write or compound read+write workflow that needs unified auth.
# Practical example: track follower velocity for N accounts.
# Pull profiles daily, persist as JSONL, compute delta over time.
import os, requests, json
from datetime import datetime, timezone
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
def snapshot_profile(username: str) -> dict:
r = requests.get(
f"{BASE}/twitter/user/info",
headers=HEADERS,
params={"userName": username},
timeout=10,
)
r.raise_for_status()
p = r.json()
return {
"username": username,
"captured_at": datetime.now(timezone.utc).isoformat(),
"followers": p.get("followers_count"),
"following": p.get("following_count"),
"tweets": p.get("tweet_count"),
"verified": p.get("verified"),
}
TRACKED = ["twitterapi_io", "elonmusk", "sama", "karpathy"]
with open("snapshots.jsonl", "a") as f:
for u in TRACKED:
snap = snapshot_profile(u)
f.write(json.dumps(snap) + "\n")
print(f"{u}: {snap['followers']} followers")
# Cost framing (math from cited pricing):
# 4 profiles × $0.00018 = $0.00072 — well under a penny.
# Daily for 30 days = $0.0216 — basically free at this scale.
# Same workload via X official: 4 × $0.010 × 30 = $1.20 (~55x more).
# For 1,000 tracked accounts daily: $5.40/mo via twitterapi.io vs $300/mo via X.
# Verify against the live pricing pages before committing.Questions readers ask
What's the difference between `public_metrics` and `non_public_metrics`?
Public metrics (followers_count, following_count, listed_count, tweet_count) are visible on the public profile and available via any read API. Non-public metrics (impressions, profile clicks) for tweets require OAuth user-context auth and are only available for the account owner's own data.
Does the count include suspended or deactivated accounts?
When an account is suspended or deactivated, the profile endpoint returns an error (404 typically). For a tracking dataset, treat that as the operationally meaningful event — log the captured_at + the error code to your storage so you can compute up-time.
How fresh are follower counts?
X's profile data refreshes in near-real-time on its surface. Both twitterapi.io and X official return current state at call time. For sub-minute precision validate against the live x.com UI — exact propagation latency can vary for newly-followed-accounts within the past minute.
Can I get profile activity history (past follower counts)?
No — both APIs return current state only. There is no time-series of past profile metrics available via the read APIs. For historical data you must capture snapshots yourself; daily snapshots build a clean longitudinal dataset.
Is `bookmark_count` available on profiles?
Bookmark counts are a per-tweet metric, not a per-profile metric. For a profile, the displayed count fields are the public-metrics set listed above. For tweet-level bookmark counts, check the tweet endpoint's public_metrics.
How does cost scale to 100,000 profiles per day?
Math from cited pricing pages. twitterapi.io: 100,000 × $0.00018 = $18/day = ~$540/mo. X official: 100,000 × $0.010 = $1,000/day = ~$30,000/mo (modulo the 24h UTC dedup if you re-poll the same handles repeatedly). At this scale twitterapi.io is the clear cost path for analytics workloads.
Continue
- twitterapi.io — pricing
- X API — pricing (docs.x.com, 2026 verified)
- Tweepy documentation
- X official — Get user by username
- Twitter (X) API — cluster hub
- Twitter (X) API in Python — complete guide
- Twitter (X) stats API — public/private metrics
- Twitter account views tracking API
- twitterapi.io pricing
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key