in LinkedIn API Live in production. Email, messengers & calendars next
Infrastructure
Messaging
Scraping
Enrichment data
Documentation Browse all docs →
QuickstartOne key, first call in 2 min MCP serverTyped tools for any agent API referenceEvery endpoint & schema WebhooksEvents, retries, signatures
GTM engineersConnect any agent to your GTM process AI SDRRun an autonomous SDR on real infrastructure AgenciesOnboard clients safely, run from your stack PlatformsAdd LinkedIn on proven infrastructure LinkedIn automationSafe connects, messages & follow-ups Account providersWarm, secure & lease account fleets
Pricing Blog
LinkedIn shadowban checkerDo your invitations still arrive? A ten-minute check All free toolsSmall checks that run without an account
Get API key Sign in
Guides

LinkedIn Posts API

LinkedIn Posts API

Publishing is the one thing LinkedIn hands out with no application at all, and reading the same posts back is the thing it stopped handing out.

Updated September 2026 · 13 min read

LinkedIn’s Posts API creates and retrieves posts for a member or an organization, and the two halves are governed nothing alike. Writing a member post runs on w_member_social, one of only three self-serve permissions on the entire platform. Reading a member’s posts back runs on r_member_social, which LinkedIn’s own documentation calls a closed permission with requests not being accepted.

Organization posts sit between the two, open to an approved Community Management app whose authenticated member holds a Page admin role. Nothing in the official set reads a third party’s posts under any permission, and that absence is what the whole engagement-data market is built on. On the account-based side of it, gtm-api.com reports 20,000+ accounts at under a 1% ban rate.

On this page

  1. What the Posts API covers, and for whom
  2. Publishing, and the two write scopes
  3. Reading posts back, and the permission that is closed
  4. Comments and reactions, and the scope family nobody notices
  5. Reading posts you do not own
  6. Frequently Asked Questions
  7. Sources

What the Posts API covers, and for whom

LinkedIn describes the endpoint in a single line: “The Posts API facilitates the creation and retrieval of organic and sponsored posts.” It lives in the Marketing docset, under Community Management, and every call needs two headers, the versioning header in YYYYMM form and X-Restli-Protocol-Version: 2.0.0.

What decides whether you can make the call is never the endpoint. It is the permission, and the six rows below are the whole picture.

What you want to do Permission How you get it
Publish as the authenticated member w_member_social Self-serve, via the Share on LinkedIn product
Publish as an organization w_organization_social Community Management review, plus a Page admin role
Read the member’s own posts r_member_social Closed, requests not accepted
Read an administered Page’s posts r_organization_social Approval, plus a Page admin role
Read comments and reactions The _feed scope family Same approval, different scope names
Read anybody else’s posts None documented No official route at any tier
🔑 The asymmetry in one lineLinkedIn will let any developer publish to a member’s feed on the day they sign up, and will not let them read that same feed back. Write access is a self-serve product. Read access is a permission LinkedIn has stopped granting.

Publishing, and the two write scopes

Member publishing is genuinely open. The Get API Access page lists exactly three permissions available without approval, and one of them is Share on LinkedIn, granting w_member_social, described there as “Post, comment and like posts on behalf of an authenticated member.” Add the product to your app in the Developer Portal and the scope is yours.

Organization publishing is a different process with a different bar. The scope is w_organization_social, and the docs attach a role condition to it: it is “Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR DIRECT_SPONSORED_CONTENT_POSTER CONTENT_ADMIN”. Getting the scope at all means going through Community Management review, which LinkedIn scopes tightly: “At this time, our Community Management APIs are only available to registered legal organizations for commercial use cases only.”

That review runs in two tiers, and the second one asks for something most developers do not expect. Development tier checks the use case, a verified business email, a verified organization and website, and an app tied to that organization’s LinkedIn Page. Standard tier adds a privacy policy, the data and security terms, and “Screen recording that accurately demonstrates all core functionality”. You are showing them the working product before they will let it work at scale.

One naming point saves an afternoon on an older tutorial. The Posts API superseded the UGC Posts API for creation: “The Posts API replaces the ugcPosts API for creating posts (User Generated Content) on behalf of an organization or member.” The ugcPosts pages are still published, and still listed in the Shares overview alongside Posts, so the two coexist in the documentation while only one of them is the current way to create.

Reading posts back, and the permission that is closed

The read side exists as a finder on the same endpoint, addressed by author: GET https://api.linkedin.com/rest/posts?author={URN}, where the URN is a Person or an Organization. Pagination defaults to 10 per page and caps at 100, and a viewContext parameter selects whether you see the post as its author or as an ordinary reader.

Then the permission decides everything. For an organization the docs say “To retrieve all posts authored by an organization, r_organization_social permission is required”, with the same Page-role restriction as the write scope. For a member the docs say “To retrieve all posts authored by a person, r_member_social permission is required”, and that scope carries a warning in its own description: “Retrieve posts, comments, and likes on behalf of an authenticated member. This permission is restricted and is available to approved users only.”

Restricted turns out to be the polite version. The Community Management overview states the position without hedging: “r_member_social is a closed permission. We’re not accepting access requests at this time due to resource constraints.” The Marketing FAQ repeats it as a question and answer, which means it is the settled answer rather than a temporary notice somebody forgot to remove.

The use case LinkedIn rules out by name. Even with organization read access, the most common reason people want it is disallowed. Asked whether you can build a social feed display, LinkedIn’s Marketing FAQ answers: “No – displaying a company page feed on your website or any other digital channel off LinkedIn is not an Approved use case”.

Webhooks narrow it further. An organization can subscribe to social-action notifications, and two conditions apply: “The subscription request will only succeed if the subscribing member is an administrator of the organization being subscribed to”, and “Webhook events for LIKE, COMMENT, and SHARE actions are only triggered for posts with visibility set to PUBLIC.”

Comments and reactions, and the scope family nobody notices

Comments, reactions and engagement counts are not part of the Posts API. They are three separate APIs, and they use a different set of scope names, which is where a working integration quietly breaks.

  • Comments API. LinkedIn’s summary is short: “The socialActions/comments API enables you to write and read comments on shares.” Seven methods, covering get, batch get, comments on shares, replies to comments, create, edit and delete.
  • Reactions API. Six operations, including one that surprises people, Create a Reaction on a Comment, so reactions apply to comments and to posts.
  • Social Metadata API. The newer surface for reading engagement: “The new service provides access to the reactions content type, which is an expansion of likes and replaces the functionality provided by the existing socialActions endpoint.” It carries the aggregate counters, including a comment count that separates top-level comments from replies.

Here is the part that costs debugging time. Those three run on w_organization_social_feed, r_organization_social_feed, w_member_social_feed and r_member_social_feed, a rename LinkedIn dated June 2023 in its Community Management migration guide. An app holding w_organization_social can publish a post and be refused on a comment, because the comment needs the _feed twin of the same name. And the member read variant is gated the same way its sibling is, “granted to select developers only”.

Reading posts you do not own

No official permission covers it, so the market answers in two shapes, and both should be judged on what they cost when LinkedIn notices.

The first is bought data. Bright Data sells a LinkedIn post scraper billed per successful record, with a free tier of 5,000 records a month and a pay-as-you-go rate per 1,000 it publishes no number for. It returns URL, id, user id, title, headline, post text and date posted, and its documentation says the collection happens on demand: “Each request triggers a live scrape. There is no cached or stale data.” Apify hosts independently maintained post-scraper actors, and the two most-used ones split on a revealing line. One runs without a LinkedIn account at all and prices from $1.50 per 1,000 posts. The other rents at $30 a month and requires you to hand it your LinkedIn cookies.

That second arrangement is the one to think about carefully, because the account carrying the risk is yours. Scraping sits outside LinkedIn’s terms whichever tool performs it, and the enforcement history is not theoretical. The full comparison, including what breaks first and what a ban actually costs, is on LinkedIn scraping vs a safe API.

The second shape is an account-based API, where the read happens under a LinkedIn account you connect and the platform paces it. That is the route gtm-api.com takes, and posts are one of the better-covered surfaces on it. Publishing takes text up to LinkedIn’s own 3,000-character cap, with up to twenty images or one video, an optional schedule, group posting, and mention spans that turn names into profile links. Commenting and reacting are their own calls, on any post, without the post being owned or tracked first.

Reading is where the account model earns its keep. A resolver turns any post URL or lnkd.in shortlink into its stable activity URN. Post details returns the body, author, media, engagement counters and the per-reaction breakdown. Person and company feeds return what an account or a Page has published. Content search finds posts by keyword, by recency or by author, either from filters or from a pasted LinkedIn content-search URL. And the engagement trio returns who commented, who reacted and who reshared, which is the data that has no official equivalent at any tier.

resolve a post URL, then read who commentedbash
# 1. any post URL or lnkd.in shortlink to a stable activity URN
curl -X POST https://app.gtm-api.com/linkedin/v4/api/linkedin-enrichment/get-activity-urn-by-url \
  -H "Authorization: Bearer $GTM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://www.linkedin.com/posts/..." }'

# 2. one page of commenters, each row carrying the comment and its author
curl -X POST https://app.gtm-api.com/linkedin/v4/api/linkedin-scraping/get-post-comments \
  -H "Authorization: Bearer $GTM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "post": "urn:li:activity:7234..." }'

Publishing and engaging both spend a per-account daily budget that the server enforces, on the same warm-up curve as every other action type, so a scheduler cannot push an account past what it has earned. The published caps and how capacity is earned are on LinkedIn limits. What the rest of the surface covers, from search to messaging, is on LinkedIn API: the developer guide.

Frequently Asked Questions

Is there a LinkedIn API to publish a post?

Yes, and it is the most open thing on the platform. The Posts API creates posts for a member on the w_member_social permission, which arrives with the self-serve Share on LinkedIn product and needs no approval. Publishing as an organization uses w_organization_social instead, which requires Community Management review and a Page admin role for the authenticated member.

Can I read other people’s LinkedIn posts through the API?

No. The Posts API retrieves posts by author, and the author has to be either an organization whose Page the authenticated member administers or the authenticated member themselves. The member read permission, r_member_social, is described by LinkedIn as closed with requests not being accepted. There is no documented endpoint that returns an arbitrary third party’s posts at any access tier.

What is the difference between the Posts API and the UGC Posts API?

The Posts API replaced ugcPosts for creating posts on behalf of an organization or a member, in LinkedIn’s own words. Both sets of pages are still published and both still appear in the Shares overview, which is why old tutorials still reference ugcPosts. For new work, create through the Posts API.

Which permission do I need to read LinkedIn comments and reactions?

One of the _feed scopes, which are separate from the Posts API scopes. Comments, reactions and social metadata use r_organization_social_feed and w_organization_social_feed for organizations, and the member equivalents for members, after a rename LinkedIn dated June 2023. An app that can publish a post can still be refused on a comment, because the two use different scope names.

How do I get a LinkedIn post’s URN from its URL?

LinkedIn’s own API gives you no resolver, since the finder takes an author URN rather than a post link. On an account-based API the resolution is one call: pass the feed permalink, the slug link or a lnkd.in shortlink and get back the stable activity URN, which then addresses post details, commenters, reactors and resharers.

Sources & Further Reading

Publish, engage, and read the engagement back.

Post, comment and react from one typed contract, resolve any post URL to its URN, and pull the people who commented, reacted and reshared. On that stack, gtm-api.com reports 20,000+ accounts at under a 1% ban rate. Free plan, then from $10 per account at volume.

Get your API key →

Michael SalamatovMichael SalamatovGTM engineerRuns the gtm-api.com blog. Covers LinkedIn limits, account health and the API side of outbound.in

Last updated: September 2026 · Permissions, access states and endpoint behaviour re-read on learn.microsoft.com, and every request field checked against the published API contract, on 1 and 4 September 2026