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 | Not reported on the connections that are live today |
| Saves and clicks | Not reported on the connections that are live today |
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.
Per-post analytics return null on this network, not a row of zeros. Null means the numbers are not available, which is different from a post that got nothing.
LinkedIn does not expose member-profile post analytics through the API we can use. Per-post analytics return null rather than a row of zeros.
None on the connections that are live today. Impressions, views, reach and engagement counts are not reported, so the call returns null rather than an invented figure.
On this network the whole analytics payload is null, not a row of zeros. Null means the network will not tell us. Zeros would say the post got nothing.
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.