Pricing

from $0.60 / 1,000 comments

Try for free

Go to Apify Store

Facebook Comments Scraper — Post Comments, Facebook Reactions

Try for free

Facebook reactions and comments for any post, reel, watch or fb.watch link — text, author, date, reply count and the ten-way reaction breakdown (like, love, care, haha, wow, sad, angry). No login, no cookies. Top-level comments only. Exact limit per link. No start fee, nothing undelivered charged.

Pricing

from $0.60 / 1,000 comments

Rating

0.0

(0)

Developer

Steadyfetch Team

Actor stats

Bookmarked

Total users

Monthly active users

a day ago

Last modified

Changelog

1.0.8 — 2026-09-14

The "what to do next" line that arrived in 1.0.7 now actually reaches you on every run that collected nothing. In 1.0.7 the run page gained one plain sentence telling you what to change when a run delivered no comments. On some of those runs it did not appear: when the page also had to tell you that this run's API token could not use your account's repeat memory, and that the run stopped at one of your own limits, there was no room left for it inside the length the run page allows — so the sentence was dropped silently and the page went back to naming only the symptom. The sentence now has a shorter form for exactly those crowded runs, and on the most crowded of all it is the "something off, open an issue" line that gives way instead, since that ask is on every row and on the Issues tab already while the next step is on neither. Nothing about what a run collects or charges changed. No price, input field, output column or charged event changed.
And it is never said twice in two different wordings. If the page is already telling you that a field name is not one this actor has — which names the box to use — the next-step sentence about that same box stands down and the page answers the next biggest reason instead. The same applies when a run stopped at this actor's own monthly collection allowance, which the stop line already names.

1.0.7 — 2026-09-14

A run that collected nothing now tells you what to change, instead of only that it collected nothing. A link this actor could not read ended the run cleanly, so the run page said "Delivered 0 comments of 1 asked for across 0 posts." and stopped there — 51 characters, no cause and no next step. Two things were wrong. The count of values it could not read was kept on the run's own record and never printed, so the likeliest mistake of all, pasting a page or profile link instead of a post link, named nothing at all. And nothing on the page said what to paste instead. The line now carries that count, and on a run that delivered nothing it adds one plain sentence for the biggest cause: the field to use and a working link to copy for an unreadable value, what a dead link means, what a post with no comments means, and which of those a second run would change. A run that did deliver is unchanged — it is not lectured about the one comment that missed. No price, input field, output column or charged event changed.
The price and a real comment row now sit on the first screen. What a run costs was three screens down, and the page listed every column without ever showing one — so a buyer comparing listings could neither price the job nor see the goods without running it. The opening paragraph now carries the per-1,000 price on both the cheapest paid tier and the Apify free plan, and a real delivered row — the comment text, its permalink, the reply count and the full ten-way reaction breakdown — sits above the column table, built by this actor's own parser from a harvested comment page. No price, input field, output column or charged event changed.

1.0.6 — 2026-09-14

A run whose token can read your account memory but not write to it now says so, instead of quietly charging you for the same comments again next time. The memory that stops you paying twice lives in a key-value store in your own Apify account, and a scoped API token can be allowed to READ it and not to write it — or to write it but not to create it the first time. Such a run looked perfect: it skipped the comments you already had, delivered the new ones, and recorded none of them, so your very next run collected and charged for that whole delivery all over again. The run now says it on the run page, in the run log and on one uncharged row in the dataset, each naming exactly what to grant (key-value store Write, and Create, under Settings → API & Integrations) or the alternative of setting Actor runs to Full access. Runs on a full-access token are unchanged. No price, input field, output column or charged event changed.
A re-started run no longer collects past the number of comments you asked for. Apify sometimes moves a run to another server part-way through; the run picks up where it left off. To know how many comments it had already handed you, it was counting the ones it had CHARGED for — and a comment can be delivered without being charged, on a run that bills nothing or once your maximum cost per run is reached. So it read its own tally low and kept collecting past your limit. It now counts the rows you actually have. If your run is never moved, nothing changes: this only ever showed up after a restart.
A run started with a limited API token now tells you the repeat check could not run — before it charges you for comments you already had. The memory that stops you paying twice for the same comment lives in a key-value store in your own Apify account. A run started through the API with a token whose permissions are restricted cannot open it, so every comment you already had was collected and charged again, and nothing said so. That run now says it on the run page, in the run log, and on one uncharged row at the top of the dataset — each naming the permission to grant (key-value store Read, Write and Create, under Settings → API & Integrations) or the alternative, running it from the console. Runs from the console, and API runs on a full-access token, are unchanged: the check runs as before and a comment you already have is still never charged twice. No price, input field, output column or charged event changed.
Nothing else moved: no input field, output column, charged event or price changed.

1.0.5 — 2026-09-13

A field name this actor does not have is now named on the run page, and recorded as your field name. A run that arrived carrying only a name this actor neither has on its form nor reads as an alternative spelling already got one uncharged row explaining it — but the run page said nothing about which name, and internally the run was filed in the same slot as a problem that names no field at all. The run page now quotes the name you sent beside the field this actor reads, and the record names it properly. A post link this actor could not use, and a "Post URLs" field you set and left empty, still report against "Post URLs" — those really are about that field. Nothing about pricing, the form, the output columns or what gets charged changed.

1.0.4 — 2026-09-13

Post links sent under a slightly different field name are now read instead of ignored. If your call put the links under a name this actor does not have on its form — postUrl, url, urls, link, links, postLink, permalink, startUrl, reelUrl, videoUrl and their plurals — the run had nothing to collect and answered with the built-in sample rows, which reads as if your call had worked. Those names are now read as the field this actor does use, your links are collected exactly as if you had typed them into "Post URLs", and one uncharged row tells you the name to use next time. A post sent under two names is still one post and one result fee. If a link cannot be used at all, the row now names the field you put it in as well as the one this actor reads. Nothing about pricing, the form itself, or the output columns changed.

1.0.3 — 2026-09-12

An aborted or migrated run now leaves its receipt from the first moment of the run, instead of only after start-up finishes. The record that says how a run ended was only put in place once the run had finished starting up — reading your input, opening its stores, working out what a previous attempt had already delivered and charged. A run stopped inside that window ended with nothing written about it at all, which mattered most on a re-started run, where the thing not written about was the earlier attempt's work. It is now in place from the run's first moment. Nothing else moved: no input field, output column, event or price changed, and a run that reaches its work behaves exactly as before.
An answer this actor has already paid for is never bought a second time. Last build taught the run to wait out a brief refusal from the data feed and ask for the same page again. That is right for a rate limit, a server error or a dropped connection — those cost nothing and clear in seconds. It was wrong when the feed had already answered and billed us in a shape this actor cannot read: waiting and asking again cannot change that answer, so the run spent part of its own upstream allowance and up to fourteen seconds of your run clock buying the same dead page three times. From this build only the refusals that cost nothing are waited out. Nothing about what you are charged moves — only delivered comments are charged, the comments collected before a refusal are still delivered, and everything that did not arrive still carries no result fee — but a post whose feed has changed shape now finishes sooner instead of spending your run clock on it.
The same post pasted two different ways is now read once and charged once. Facebook gives one post several links — /reel/…, /watch/?v=…, /YourPage/posts/…, /photo.php?fbid=…, a group post link — and this actor also takes the feed's own feedback_id. A list that named one post two of those ways used to treat them as two posts: the post was read twice and its comments were charged twice, and the two rows looked like duplicates because they were. The run now recognises the post itself rather than the kind of link it arrived in, whichever order you pasted them, so one post is one read and one charge. The line it folded is not dropped in silence: it comes back as an uncharged note saying which earlier line already named that post. Two genuinely different posts are unaffected, and a short /share/… or fb.watch link is still treated as its own post, because those give us nothing to prove they are the same one.

1.0.2 — 2026-09-12

A brief "slow down" from the data feed no longer costs you the rest of the post. When the feed behind this actor answered with a rate limit, a server error or an unreadable reply part-way through a post's comments, the run used to give up on that post within a few seconds: you kept the comments collected up to that point and the rest of your result limit came back as something to re-run. From this build the run waits the refusal out, up to twice per post, and asks for the same page again; a feed that clears carries on to your result limit, and only a feed that still refuses afterwards ends the walk. The waiting is bounded by your run clock — no wait is taken that the remaining time cannot fit — and it stops immediately at your maximum cost per run. A verdict about the post itself (deleted, behind a login, no more comments) is never waited on, because waiting cannot change it.
A refusal and an outage are no longer recorded as the same thing. When the data feed refuses a request outright, the row has always told you the run would not try again — but the run's own machine-readable record filed it beside the temporary failures that are worth a re-run. It now carries its own word, so a run you read through the API says the same thing as the row in front of you. Nothing about what is delivered or charged changes; that row was, and stays, uncharged.
A post that really was cut short is unchanged: the comments already collected are still delivered, the row still says how many, and nothing that did not arrive carries a result fee.
An uncharged row can no longer deny a result fee you were already charged, and a run that stopped at one of this actor's own bounds no longer blames Facebook for it. When a post delivered its first pages and the read then stopped working, the row closing the rest said "there was no result fee — please re-run", over rows sitting charged in the same dataset; it now opens with how many comments had already been delivered and scopes the re-run to what is left. And three different endings used to share one sentence — "has no more comments to return … that is a definitive answer" — when only one of them was Facebook's answer: the other two are this actor walking at most 500 pages of comments for one link, and this actor stopping after three pages in a row that held only comments you already have. Each now names the bound as ours and the setting that moves it.
One link can now really reach the 5,000 comments this actor promises per post. The limit you can ask for per link has always been 5,000, and the walk behind it stopped at 400 pages — ten comments a page, so 4,000. A deep ask on a busy post could therefore be cut by a bound of ours at 80% of the number the actor sells, and the row said so honestly, which only made the gap plainer. The walk now goes to 500 pages, so the full 5,000 is reachable on one link. Nothing about your input, your prices or your rows changes, and nothing you have already collected needs re-running.
A run that stopped at one of this actor's own bounds now says so in the run's summary too, not only on the row. Last build the uncharged row learned to name which of the three endings cut a post's walk — Facebook having no next page, this actor's page ceiling, or this actor stopping after pages that held only comments you already have. The run's own summary still filed all three under the post having no more comments to give, so the row and the summary said different things about the same post. The two bounds that are ours are now counted separately in the summary, as stops rather than as the post running out: nothing failed, nothing ran out, and nothing behind either bound was collected or charged. "No comments" from now on means only what it says.
An address fragment that could reach a row is now stripped in every shape. A link arriving with your rows can carry the address the fetch came from, and it is written several different ways depending on how the page served it. Only one of those spellings was being removed, so a link in a comment's text — or the link you pasted in yourself, echoed back on a row — could still carry one into your dataset and your exports. Every spelling is stripped now, wherever it sits in a row. A link that carries no address comes back exactly as it was, and nothing else in any link moves.

1.0.1 — 2026-09-13

First public build.

Comments from any Facebook post, reel, watch or fb.watch link: text, a permalink to the comment, the author's name, id and profile link, when it was posted, the reaction total, the ten-way reaction breakdown (like, love, care, haha, wow, sad, angry, thankful, pride, confused) and the number of replies under each comment.
Top-level comments only. Replies are counted on the row they belong to and never pulled — Facebook's own reply feed hands back a subset of a thread rather than the thread, and a subset sold as a thread would be a lie.
resultsLimit is exact and per link; maxItems caps the whole run and also answers to limit and count, the names other Facebook comment scrapers use. The smallest limit present binds, and one uncharged note row says which name was read.
An over-ask never refuses the run. The input schema declares no maximum on any number and no minimum above 1, so a caller asking for 50,000 comments per post — or a 5-second run clock — still starts a run: the actor's own ceiling binds (5,000 per post, 100,000 rows, a 30-3,600 second clock) and one uncharged row says what was asked and what bound it. A schema ceiling is validated by the platform before a container boots, so it returns an error and no run at all — invisible to the buyer and to us.
Never charged: a link that does not resolve, a post behind a login, a post with no comments, a read that failed, comments dropped by your own cap or the run clock, and starting a run.
A cost cap or a time limit ends the collecting, never the delivering: rows already in hand ship in full and the last row says what stopped the run and what is left.
Re-runs skip the comments your account already had — remembered in the key-value store fb-comments-account in your own account — so a daily watch on the same posts pays only for what is new. Turn on Include comments you already have to get them back anyway, marked repeat: true and still uncharged.

Facebook Comment Scraper - Posts & Reels [NO COOKIES] ✅

unseenuser/fb-comments

Pull every comment from any public Facebook post or reel: text, timestamp, reply count, author, and a full per-reaction breakdown (like, love, care, haha, wow, sad, anger and more). Fetch threaded replies on demand. No login, no cookies. Built for sentiment, NLP and social listening.

Unseen User

5.0

(3)

Facebook Comments Scraper

leadsbrary/facebook-comments-scraper

Extract comments from any public Facebook post, reel, or video. Get comment text, date, author name, profile link, reaction count, and reply count. Configure output fields, filter by date, sort results. Export as JSON, CSV, or Excel.

Alexandre Manguis

5.0

(1)

Facebook Comments Scraper Lite

alpha-scraper/facebook-comments-scraper-lite

Facebook Comment Scraper Lite extracts structured comment data from public Facebook posts. Get ALL Details Reactions, comment text, author profiles, reactions, replies, timestamps, attachments, and engagement metrics in clean JSON for research, analytics, marketing, and AI applications.

Alpha Scraper

Facebook Comment Scraper Pro

alpha-scraper/facebook-comment-scraper-pro

Facebook Comment Scraper Pro extracts public comments, replies, reactions, engagement metrics, author details, timestamps, and attachment data from Facebook posts. Analyze audience sentiment, monitor engagement, track discussions, and export structured comment data for research, marketing, analytic.

Alpha Scraper

RedNote (Xiaohongshu) Comments Scraper 🔍

easyapi/rednote-xiaohongshu-comments-scraper

Scrape comments from RedNote (Xiaohongshu) posts efficiently. Extract detailed comment data including user info, timestamps, locations, and nested replies. Perfect for social media analysis, user research, and engagement tracking.

EasyApi

385

1.0

(1)

Facebook Comments Scraper - Replies & Reactions

chronometrica/facebook-comments-scraper

Scrape public Facebook comments and replies from posts, Reels, photos, Watch URLs, and supported share links. Get text, authors, dates, reaction breakdowns, profile pictures, attachments, and threads. Sort and filter results, set exact maximums or remove the numeric cap—without login or cookies.

Chronometrica

788

Facebook Comments Scraper - Posts & Pages

makework36/facebook-comments-scraper

Scrape Facebook comments from any public post or page. No login needed. Get comment text, author, date, reactions, reply count. Also extracts post info: text, reactions, shares. Pure HTTP.

deusex machine

Facebook Comments Scraper - $0.25 per 1,000

dami_studio/facebook-comments-scraper

Get comments from any public Facebook post or reel. Paste the URLs. Each row has the author, comment text, date, like count and reply count. Nested replies are included if you want them. You never log in, and no browser is used. $0.25 per 1,000 comments, the same rate on every plan.

Dami's Studio

Facebook Comments Scraper

axesso_data/facebook-comments-scraper

Scrape real-time comments from public Facebook posts including text, timestamps, author info, and engagement metrics. Fresh data fetched directly from Facebook on every run - no caching layer in between. Pass multiple feedbackIds to collect comments from many posts in a single run.

AxCrawler

Facebook Groups Scraper – Posts, Comments & Replies [No Login]✅

unseenuser/fb-groups

Scrape public Facebook group posts with full comment threads and replies - no login, no cookies, never member data. The only Groups scraper that returns complete comment threads. Export JSON, CSV, or Excel.

Unseen User

5.0

(3)

Facebook Posts & Comments Scraper

krazee_kaushik/facebook-posts-and-comments-scraper

Scrape Facebook posts, photos, videos, and reels from multiple profiles and pages. Retrieves every photo from multi-photo posts, processes 50+ posts per minute, and collects hundreds of comments per post. No login required.