LinkedIn Post Reactions Scraper - [✅ No Cookies]

What is LinkedIn Post Reactions Scraper - Likes & Engagement?

This Apify Actor is built for analysts, marketers, lead researchers, and AI agents that need structured data from public LinkedIn post URLs. It accepts LinkedIn post, feed update, article, and company post URLs, plus numeric activity IDs and urn:li:activity values. Each saved record represents one post reaction summary row or one visible reactor profile row. The returned fields can include like count, reaction count, comment count, share count, engagement count, post author details, and visible reactor profile metadata when the provider payload exposes them. The outcome is a clean dataset, plus OUTPUT and RUN_SUMMARY records for automation and agent workflows.

Best fit and connected workflows

This Actor fits workflows that begin with known LinkedIn post URLs and end with structured engagement data. It is a strong match for:

• post engagement tracking for campaigns, launches, and creator content
• lead research based on public post interaction signals
• workflow automation that enriches records with public LinkedIn engagement metrics
• AI agents that need one-row-per-post summaries or visible reactor rows from provider payloads

When a workflow centers on post-level reporting, summaries mode gives a compact dataset. When a workflow benefits from visible reactor rows returned by provider payloads, reactors or both can save those rows alongside the summary records.

Practical scenario

Maya, a growth marketer, has a LinkedIn article URL from a recent product announcement. She submits that URL through startUrls, keeps outputMode set to summaries, and limits the run to the article she is reviewing. The dataset returns the post URL, author name, publication time, reaction count, like count, comment count, share count, and engagement count. Maya uses the engagement totals to compare the article with other launch posts, then opens the OUTPUT record to hand the row set to her reporting workflow.

Input fields

Field	Type	Description
startUrls	array	LinkedIn post, feed update, article, or company post URLs to inspect.
postUrls	array	Optional line-separated list of LinkedIn post URLs, numeric activity IDs, or urn:li:activity values.
maxPosts	integer	Maximum number of unique post URLs to process.
maxReactors	integer	Maximum number of visible reactor profile rows to save if the provider exposes reactor identities.
outputMode	string	Choose post reaction summaries, visible reactor profile rows only, or both.
providerOrder	string	Choose which managed public-data provider to try first.
includeRawData	boolean	Attach raw provider post or reaction objects to dataset rows for debugging.

Focused input example

{
  "postUrls": [
    "https://www.linkedin.com/feed/update/urn:li:activity:7312345678901234567/"
  ],
  "outputMode": "summaries",
  "maxPosts": 1,
  "maxReactors": 100,
  "includeRawData": false
}

Output fields

Field	Type	Description
recordType	string	post for reaction summary rows, reactor for visible reactor profile rows.
postUrl	string	Canonical or provider-returned LinkedIn post URL.
postId	string	LinkedIn activity, share, article, or provider post identifier when available.
postTitle	string	Post title, article name, or headline when available.
postText	string	Visible post body, article description, or provider text.
postAuthorName	string	Visible author name for the LinkedIn post.
postAuthorUrl	string	LinkedIn profile or page URL for the post author.
postAuthorFollowers	integer	Follower count for the post author when exposed.
postPublishedAt	string	Provider-returned publication date or timestamp.
likeCount	integer	Like count when exposed by the provider.
reactionCount	integer	Total reaction count when exposed by the provider.
reactionBreakdown	object	Reaction counts by type when the provider exposes a breakdown.
commentCount	integer	Total post comment count when exposed by the provider.
shareCount	integer	Share or repost count when exposed by the provider.
engagementCount	integer	Convenience total of available reactions, comments, and shares.
reactorProfilesFound	integer	Number of provider-returned visible reactor profile objects found for this post.
reactorProfilesSaved	integer	Number of visible reactor profile rows saved for this post.
reactionType	string	Reaction type for reactor rows, such as like, celebrate, support, love, insightful, or curious.
name	string	Visible reactor name when a provider exposes reactor identities.
headline	string	Visible reactor headline or occupation when available.
profileUrl	string	LinkedIn profile URL for a visible reactor when available.
profileImage	string	Profile image URL for a visible reactor when available.
actorUrn	string	Provider or LinkedIn actor identifier when available.
source	string	Provider used for this row.
scrapedAt	string	ISO timestamp when the row was saved.

Illustrative output record

{
  "recordType": "post",
  "postUrl": "https://www.linkedin.com/pulse/being-father-has-made-me-better-leader-vice-versa-austen-allred/",
  "postTitle": "Being a Father Has Made me a Better Leader, and Vice Versa",
  "postAuthorName": "Austen Allred",
  "postAuthorUrl": "https://www.linkedin.com/in/austenallred",
  "postPublishedAt": "2020-06-21T14:35:59.000+00:00",
  "likeCount": 215,
  "reactionCount": 215,
  "commentCount": 17,
  "shareCount": 0,
  "engagementCount": 232,
  "reactorProfilesFound": 0,
  "reactorProfilesSaved": 0,
  "scrapedAt": "2026-06-10T00:00:00.000Z"
}

How it works

This Actor uses owner-managed public-data providers to read public LinkedIn post payloads. The live contract shows the provider label as the default provider order and the provider label as the alternate provider, with environment variables available for both provider API keys. The Actor saves one dataset row per post summary, and saves reactor rows when provider payloads expose visible reactor identities. It also writes OUTPUT and RUN_SUMMARY records to the default key-value store for automation and monitoring.

Evergreen pricing

This Actor uses Pay per event pricing with Apify platform usage included.

Charged events include:

• Actor start
• LinkedIn post reactions scraped
• LinkedIn reactor profile scraped

The primary event is charged for each LinkedIn post reaction summary row saved. For example, a run that saves one hundred summary rows and twenty visible reactor rows is billed for those saved events in addition to the Actor start event, while Apify platform usage is included in the event price. For current pricing details, open the live Pricing tab on the Actor page.

Use with AI agents (MCP)

This Actor is usable through Apify MCP as a tool that accepts public LinkedIn post URLs and returns structured reaction data. The exact Actor identity is khadinakbar/linkedin-post-reactions-scraper.

Tool description: submit LinkedIn post URLs, activity IDs, or URNs and retrieve post-level reaction summaries, optional visible reactor profile rows, dataset URLs, and execution summaries.

Inspect these LinkedIn post URLs, return the post-level reaction summaries, and include visible reactor rows if the provider payload exposes them. Use summaries unless I explicitly ask for reactor rows. Summarize the output using the dataset and the OUTPUT record, and mention the provider source for each row.

Output interpretation:

• post rows represent summary records for each LinkedIn post.
• reactor rows represent visible reactor profile rows returned by provider payloads.
• source shows which managed provider supplied the row.
• scrapedAt gives the save timestamp in ISO format.
• RUN_SUMMARY and OUTPUT help agents read totals, provider usage, warnings, and the dataset URL.

Provenance and scope:

• Inputs are public LinkedIn post URLs, activity IDs, or URNs.
• Output reflects provider-returned public post data and visible reactor rows when exposed.
• OUTPUT and RUN_SUMMARY are stored in the default key-value store for downstream agents.

Pagination and cost guidance:

• maxPosts controls how many unique post URLs are processed.
• maxReactors controls how many visible reactor rows are saved.
• outputMode selects summaries, reactor rows, or both.
• Saved rows drive event charges, so keeping the input set focused helps keep runs predictable.

Apify API example

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({
  token: process.env.APIFY_TOKEN,
});

const actor = client.actor('khadinakbar/linkedin-post-reactions-scraper');

const run = await actor.call({
  postUrls: [
    'https://www.linkedin.com/feed/update/urn:li:activity:7312345678901234567/'
  ],
  outputMode: 'summaries',
  maxPosts: 1,
  includeRawData: false,
});

const datasetId = run.defaultDatasetId;
const { items } = await client.dataset(datasetId).listItems({ clean: true });

console.log('Run ID:', run.id);
console.log('Dataset items:', items);

Best results and outcome guidance

Use one LinkedIn post URL per record when you want a precise engagement snapshot. Set outputMode to summaries for post-level reporting, or use both when visible reactor rows are part of the workflow. Choose the provider order that matches your operational preference, and keep maxReactors aligned with the number of visible reactor rows you plan to store. If you are reading the output with an agent, start with the dataset rows and then inspect OUTPUT for a compact run summary.

Continue the workflow

• Then use LinkedIn Post Search Scraper to extend LinkedIn Post Reactions Scraper - Likes & Engagement research with a complementary discovery contract.
• Then use LinkedIn Posts Scraper to extend LinkedIn Post Reactions Scraper - Likes & Engagement research with a complementary content contract.

Design note

I found that the dataset contract uses one shared row shape for both summary and reactor records, with recordType distinguishing the row type and postUrl, source, and scrapedAt required on every record.

FAQ

Can I send LinkedIn post URLs directly?

Yes. startUrls accepts LinkedIn post, feed update, article, and company post URLs, and postUrls also accepts numeric activity IDs and urn:li:activity values.

When should I use summaries versus reactors?

Use summaries when you want reaction counts, comments, shares, and engagement totals. Use reactors when you want visible reactor profile rows from provider payloads. Use both when you want both row types in one run.

Which provider is tried first by default?

The live contract sets the default provider order as the default providerOrder, with the provider label available as an alternate option.

Where are execution summaries stored?

The live output contract stores RUN_SUMMARY and OUTPUT in the default key-value store.

Can AI agents access this Actor through Apify MCP?

Yes. The Actor is MCP-ready and can be called through Apify MCP using the exact Actor identity khadinakbar/linkedin-post-reactions-scraper.

Responsible use

Use this Actor for public LinkedIn post data and provider-exposed visible reactor rows. Keep inputs focused on known post URLs, review the provider source in each row, and handle the output according to your own data governance, privacy, and platform policy requirements.