# Posts (/docs/api/posts)



The Posts surface fetches a specific LinkedIn post by activity ID —
body, author, ugcPost URN, reaction breakdown by type, and view counts
where LinkedIn exposes them. Then enumerate the reactors for warm-list
building or distribution analytics.

<EndpointList topic="posts" />

## Activity IDs vs ugcPost IDs [#activity-ids-vs-ugcpost-ids]

LinkedIn uses **two** IDs for the same post:

* `activity:<id>` — the integer in `/feed/update/urn:li:activity:<id>/`
  URLs. This is what you start with.
* `ugcPost:<id>` — a separate integer that addresses the post in the
  "social" subsystem. Used for reactions, comments, and saves.

LinkFetch's `GET /v1/posts/:id` accepts the activity ID. The response
includes the matching `ugc_post_urn` so you can call reactions and
outbound actions without a separate lookup. Don't conflate them — they
look identical (both \~19-digit integers) but are not interchangeable.

## Get post by activity ID [#get-post-by-activity-id]

<EndpointDemo id="posts-get" />

Returns the normalised post: text, author, attachments, posted\_at
(derived from the activity-ID snowflake timestamp, **not** the
"posted N days ago" string), reaction breakdown by type
(`LIKE / PRAISE / EMPATHY / INTEREST / APPRECIATION / ENTERTAINMENT /
FUNNY`), and view counts when present.

## List reactions on a post [#list-reactions-on-a-post]

<EndpointDemo id="posts-reactions" />

Paginated reactors with name, headline, and reaction type. Great for
warm-list building. The response is shaped like `/v1/profiles` lite —
each reactor carries enough context to feed into a follow-up
[`/v1/profiles`](/docs/api/profiles) lookup if you need the full
record.

## Notes [#notes]

* 3 credits per post detail, 2 credits per reactions page.
* Posts cache for 7 days; the [extension](/docs/extension) re-captures
  on miss.
* Reactor counts can change after the call; `meta.fetched_at` is the
  truth for the reaction breakdown at capture time.