Works with your stack
cURL Python Node.js 
MCP
One key · one credit balance · plain REST MCP One URL in. Clean JSON out.
Give this endpoint a Facebook Page URL or handle and it returns that Page's recent public posts as a JSON array — text, reaction and comment counts, timestamps, thumbnails. It reads the same Page feed anyone can open logged out, so no Page admin role and no Graph API app review are involved. Billing is 3 credits per post returned, not per call.
MCP The difference
On the left, what a headless browser hands you. On the right, what the endpoint hands you.
<div class="x1yztbdb x1n2onr6 xh8yej3" data-visualcompletion="ignore"><div class="x78zum5 xdt5ytf"><div dir="auto" class="xdj266r x11i5rnm x1mh8g0r">Weekend build: three settings we changed after your feedback</div></div><div class="x9f619 x1ja2u2z x78zum5"><span class="xt0b8zv x1jx94hy" aria-label="5.2K reactions"><i data-visualcompletion="css-img"></i></span><span class="x193iq5w">331 comments</span><span class="x1s688f">128 shares</span></div><abbr data-utime="1751630400" class="x1i10hfl">3d</abbr><script>requireLazy(["CometResourceScheduler"],function(f){f().schedule({"__bbox":{"require":[["adp_Comet... {"data": [{"id": "1093831344793765","url": "https://www.facebook.com/watch/?v=1093831344793765","caption": "Weekend build: three settings we changed after your feedback","posted_at": "2026-07-04T12:00:00Z","metrics": {"likes": 5210,"comments": 331,"shares": 128}}],"meta": {"count": 2,"limit": 20,"item": "post"},"request_id": "req_01JZX4M8Q2TE9W"}
The payload
An array of post objects in the order the Page feed presents them, which is newest first in practice. Each item carries the post id and canonical URL, the message text, the public counters, when it went up, a nested author block for the Page, and a thumbnail link when the post has media attached.
Set `limit` to control how many posts come back. The default is 20. Because pricing is per post, `limit` is also your cost dial: 20 posts is 60 credits, 100 posts is 300. Ask for what you will actually store.
One call returns one batch and that is the whole response. There is no cursor, no page token and no offset — nothing in the response lets you ask for the next slice, so the only way to get more posts is a single call with a larger `limit`.
Items fetched here also warm the per-post cache used by the Facebook Post Stats API. If you pull a Page's feed and then look up an individual post from that same feed shortly after, the second call is usually served from cache.
Public reaction count. Facebook usually reports this as the total across all reaction types, not likes alone; there is no per-reaction breakdown here.
Pricing
Each returned post is 3 credits — about 1.5¢ on the monthly plan. A default 20-post pull runs about 30¢, and a Page that returns nothing still costs 1 credit.
Estimate only, on a full-year basis. 3 credits per returned post. Monthly: $5 per 1,000 credits with $4/1,000 top-ups. Annual: $54 per 12,000 credits with $3/1,000 top-ups. We show whichever plan is cheaper for your annual volume, divided by 12. Failed calls are never charged; cache hits cost the same as fresh calls.
Entry price, side by side
Credits are not equivalent units across vendors — each meters differently. Price your own workload on both before deciding on entry price alone. At high volume, several of these are cheaper per credit than we are.
Engineering notes
We document exactly how every endpoint behaves — nulls, caching, billing — so what you ship on day one is still running in month six. No surprises, no support tickets.
You are billed 3 credits for each post the API actually returns. Asking for 50 and getting 31 back — because the Page has only 31 public posts, or the feed ended early — charges you for 31. That is the intended behaviour: you pay for data, not for requests.
Set limit deliberately. A monitoring job that only needs to spot new posts rarely needs more than 10 per poll, and running that hourly at limit=100 is a fast way to burn credits on data you already have.
Facebook does not render a share count on every Page, and view counts only exist on video posts. Both fields come back null when the platform is not publishing them. This is not a partial failure and it is not something a different scraper would fix — the number is simply not on the page.
If your dashboard needs a single engagement figure, build it from likes and comments and treat shares and views as bonus signal when present.
The `likes` field carries Facebook's public reaction total, which lumps likes, loves, angry and the rest together. If your analysis depends on separating a wave of angry reactions from genuine approval, this endpoint cannot give you that split, and neither can the public Page view it reads from.
Items arrive in the order Facebook lays out the Page feed. That is usually reverse-chronological, but a pinned post can sit at the top regardless of its date, so the first item is not reliably the newest. Sort by `posted_at` yourself before you compute anything time-based, and skip items where `posted_at` is null.
Responses sit in the medium cache class, so a repeat pull of the same Page within the window returns in milliseconds with x-cache: hit and costs the same credits. Pass fresh=true when you specifically need to catch a post published in the last few minutes. For daily competitor tracking the cache is fine and you should leave it alone.
Questions
GET /v1/facebook/channel-posts with the Page URL or handle and your API key. The Graph API route requires a reviewed app plus a Page access token that only a Page admin can issue, which rules it out for competitor research and for most internal tools. This endpoint reads the public Page feed logged out and returns normalised JSON, so there is no app review and no token handoff.
300 credits — 3 credits per post returned. Credits are $0.005 each on monthly billing and $0.0045 on annual, so 100 posts is about $1.50, or $1.35 annual. You are charged for posts actually returned, so a Page with only 40 public posts costs 120 credits even if you asked for 100. Failed calls are not charged.
As far as the public Page feed goes, controlled by the limit parameter — and limit is the only control you have. There is no date-range filter and no pagination, so a second call cannot resume where the first stopped; historical pulls mean one call with a larger limit and discarding items older than your cutoff, which you pay for. If you want a deep archive, do one large backfill once, store it, then poll with a small limit for new posts.
No. Only public Pages work. Personal profiles and private or closed groups are not reachable, because we never log in and only read what an anonymous visitor sees. A profile or group URL returns an error rather than a partial result, and the call is not billed.
Facebook does not display a share count on every Page or every post. When the number is not published, we return null rather than inventing a zero, since zero and unknown mean different things for engagement analysis. The same applies to views, which only exist on video posts. Write your consumers to accept null on both fields.
No, only the comment count. Comment text is a separate call to the Facebook Comments API, which takes an individual post URL and returns the comment bodies, authors, like counts and timestamps. The split is deliberate: most feed pulls never need the comment text, and charging everyone for it would make this endpoint several times more expensive.
Match your poll rate to the Page's posting rate. Most brand Pages publish a few times a week, so a daily pull at limit=10 catches everything with room to spare. News Pages posting hourly justify hourly polls. Deduplicate on the post id, since every pull will re-return posts you already have and you pay for them each time.
Next
100 trial credits on signup — no card, key on screen immediately.