Social media analytics APIs: what every network exposes, what it costs, and what it quietly deleted

The map

One row per network. “Who” is who can obtain a token that returns the metrics; “Cost” is the network’s charge for the API itself, not for any tool built on it.

Impressions are being deleted, one network at a time

The single most consequential change for anyone storing social metrics is that Meta is replacing “impressions” with “views” everywhere, and doing it through hard deprecations that return errors rather than zeros.

The definitions differ, which is the trap. An Instagram impression counted a piece of content appearing on a screen; a view counts a piece of content being seen or played, and Reels views include replays. Historical impressions and new views are not the same series, and a chart that stitches them together lies at the seam. Store the metric name and the API version alongside every value.

Rate limits and quotas, network by network

Only X bills per call. Everyone else throttles. These are the published ceilings you design a polling schedule around:

The polling schedule that follows from those numbers: read Instagram and Facebook insights once a day per post for the first week and weekly after that, because 200 calls an hour per account is generous for daily reads and hopeless for anything real-time. Poll X metrics on a budget you set in dollars, not requests. Read Bluesky as often as you like. Prefer webhooks where they exist — Meta and Threads fire them for comments and mentions, not for metric changes, so metrics remain a pull.

Normalising the metrics without lying

A unified analytics layer has to decide what “engagement” means across networks that count different actions. There are two defensible approaches and one common mistake.

• Union of actions. Engagement = every action the network reports (likes, comments, shares, saves, clicks, quotes, bookmarks). Honest but incomparable — X counts profile clicks, Instagram does not.
• Common core. Engagement = likes + comments + shares only, because every network reports those three. Comparable, and it undercounts the networks where saves or clicks dominate.
• The mistake is a single “engagement rate” column whose denominator changes by network. TikTok divides by views, Instagram by reach or followers, X by impressions, Bluesky has no denominator at all. Store the numerator and the denominator separately and name the denominator.

Time windows also disagree. Instagram account insights accept at most 30 days per request. X non-public metrics exist only for posts from the last 30 days. TikTok’s Display API has no time dimension at all — it returns the current counts. YouTube Analytics is the only one that will give you a per-day series for a video published two years ago. Design the ingest to snapshot current counts on a schedule rather than expecting any network to give you history on request.

Reading each API: the minimum viable calls

The calls that return the headline numbers, so you can see how differently they are shaped:

# YouTube — a per-video daily series (Analytics API, OAuth with yt-analytics.readonly)
GET https://youtubeanalytics.googleapis.com/v2/reports
  ?ids=channel==MINE&startDate=2026-08-01&endDate=2026-08-31
  &metrics=views,estimatedMinutesWatched,averageViewDuration,subscribersGained
  &dimensions=day&filters=video==VIDEO_ID

# Instagram — media insights (Instagram Login path)
GET https://graph.instagram.com/v26.0/{media-id}/insights
  ?metric=views,reach,likes,comments,saved,shares,total_interactions

# Facebook Page — post-level media views (the replacement for post_impressions)
GET https://graph.facebook.com/v26.0/{post-id}/insights
  ?metric=post_media_view,post_clicks,post_reactions_by_type_total

# Threads — per-post insights
GET https://graph.threads.net/v1.0/{media-id}/insights
  ?metric=views,likes,replies,reposts,quotes,shares

# X — public metrics on up to 100 posts per call (each post read is billed)
GET https://api.x.com/2/tweets?ids=ID1,ID2&tweet.fields=public_metrics,non_public_metrics

# Bluesky — public counts, no token
GET https://public.api.bsky.app/xrpc/app.bsky.feed.getPosts?uris=at://did:plc:.../app.bsky.feed.post/...

Two shapes stand out. YouTube is a reporting query with dimensions and filters — a small SQL. Everything else is a per-object fetch. A unified layer ends up with two ingest paths whatever it does.

Access: who gets a token, and how long it takes

Where PostMCP fits

PostMCP is the publishing half of this picture, not the analytics half. Its API creates, schedules and publishes posts to LinkedIn, X, Facebook, Instagram, Threads, Bluesky and YouTube, and get_post returns the per-profile delivery state and live permalink for every post — the ids you feed into the insights calls above. It does not expose analytics endpoints, and this page exists because the people integrating the publishing API keep asking where the metrics come from. The honest answer is: from each network’s own insights API, on the account owner’s token, under the limits in the tables above. Pair the two and you have the loop; pretend one covers the other and you have a schema that breaks next April.