Read Threads numbers through the same call you use for every other network, in one normalised shape, with an honest account of which metrics Threads genuinely reports.
One call returns a post's numbers in the same shape as every other network, so your code reads impressions and likes without knowing which network it is looking at.
curl https://api.postlake.dev/v1/posts/post_…/analytics \
-H "Authorization: Bearer $POSTLAKE_API_KEY"This is the part usually left vague. Networks do not report the same things, and pretending they do produces charts that are quietly wrong.
| Metric | On Threads |
|---|---|
| Impressions | Not reported by this network |
| Views | Reported |
| Reach | Not reported by this network |
| Likes, comments, shares | Reported where the network exposes them |
| Saves and clicks | Reported where the network exposes them |
Threads reports views, not impressions, and PostLake keeps them apart. A view is someone watching; an impression is the post being displayed. Filing one under the other overstates nothing but mislabels everything downstream, because every rate that divides by impressions is then computed against the wrong denominator.
GET /v1/analytics?period=30d returns every connected account together, already normalised, so an agent can decide what to post next rather than only report what happened. Because the shapes match, comparing Threads to the rest is arithmetic instead of a mapping exercise.
Where a network is missing a metric it is a zero with a known reason, not a gap you have to investigate. That honesty is the difference between a dashboard you trust and one you quietly stop opening.
Threads exposes analytics to approved applications, and PostLake wraps it so you get the same response shape as every other network. One call, one format, no per-network parsing.
Primarily views, plus engagement counts where the network exposes them.
Because that network does not report it. PostLake never fills a missing metric with a related one. A zero means "not reported here", which is a different and more useful fact than a number that quietly came from somewhere else.
Yes. Over MCP it is get_post_analytics for one post and get_analytics for everything, returned as a table an agent can act on rather than raw JSON it has to re-request.