LinkedIn

The LinkedIn connector exposes two endpoints:

Endpoint	Purpose	Billed
GET /v1/linkedin/search	Keyword search across public LinkedIn posts	per page
GET /v1/linkedin/post/{post_id}	A single post with author, text, engagement, and top comments	per request

The typical workflow is search → fetch: run a keyword search to discover relevant posts, then pass each result's activity_id (or url) to the post endpoint for the full record.

Post identifiers

A post is identified by its activity id — the numeric code embedded in a LinkedIn post URL. Both endpoints work with it, and the post endpoint also accepts a full post URL verbatim:

https://www.linkedin.com/posts/javier-blas_why-is-oil-activity-7510981610687614977-K83x
                                                             └──────────────────┘
                                              activity_id = 7510981610687614977

• Activity id — 7510981610687614977
• Full post URL — https://www.linkedin.com/posts/…-activity-7510981610687614977-…

Search results already include both the url and the activity_id, so you can hand either straight to the post endpoint.

Post types

type	Meaning
post	A standard LinkedIn post
article	A long-form LinkedIn article

Engagement vocabulary

Post engagement is surfaced under stable keys:

Field	Meaning
like_count	Reactions on the post
comment_count	Comments on the post
share_count	Reshares, when available

Why some fields are null

Not every post exposes every metric. Missing values are returned as null rather than dropped, so your schema stays stable. The comment_count reflects the post's total comment count, which may be larger than the number of comment objects returned in comments[].

Latency & reliability

LinkedIn is a public-web source, so:

• Results are best-effort discovery — they reflect what is publicly available and can shift over time; they are not exhaustive.
• Occasional 429 upstream_rate_limited responses indicate a transient block — retry with backoff and it will clear. See Errors.
• Large max_pages values run several sequential fetches; prefer modest page counts and paginate over multiple calls for big pulls.