Read LinkedIn numbers through the same call you use for every other network, in one normalised shape, with an honest account of which metrics LinkedIn 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 LinkedIn |
|---|---|
| Impressions | Not reported by this network |
| Views | Not reported by this network |
| Reach | Not reported by this network |
| Likes, comments, shares | Reported where the network exposes them |
| Saves and clicks | Reported where the network exposes them |
Where LinkedIn reports both, both are returned separately, because a view and an impression are different events.
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 LinkedIn 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.
LinkedIn 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.
Engagement counts where the network exposes them. It does not report impressions, views or unique reach through its API, so those come back as zero rather than as an invented figure.
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.