"Facebook API" isn't one thing to evaluate. Ad spend, page identity, and marketplace listings live on three different surfaces with three different input shapes, three different price points, and three different maintenance problems if you try to pull them yourself. Picking one vendor for "Facebook data" without checking which surface it actually covers is how a team ends up with an ads tool when what they needed was a marketplace price feed.
If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.
What should you actually check before picking a Facebook API?
Four things, in order of how often they get skipped:
- Which surface it covers. Ads, pages, and marketplace are separate products on Facebook's own backend. A vendor that's strong on ad transparency data may have never built a marketplace scraper at all.
- Whether it batches. Some inputs take one URL per call; others take a whole list in one request. That difference changes how you'd architect a daily pull across dozens of pages.
- Whether it needs a login. Facebook gates a lot behind an authenticated session. An API that needs one inherits every session problem a DIY scraper has — expiring cookies, account flags, CAPTCHAs.
- What it actually returns. "Ad data" can mean a headline and a CTA, or it can mean full EU transparency disclosures and reach breakdowns. Check the field list, not the marketing copy.
How do you check whether an API needs a login?
Try pulling one row without ever authenticating. If the vendor's own docs require you to connect a Facebook account before the first call works, that's a session dependency you're inheriting, not one you're avoiding.
curl -X POST "https://api.mindcase.co/v1/data/facebook/pages/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"params": {
"pageUrls": ["nike", "adidas", "puma"]
}
}'
# $0.01 per pageNo login step, no account to connect — just a page handle in, a row back. That's true across all three Facebook APIs covered here: Ads, Pages, and Marketplace all run against public data only.
Why does batching matter more than it sounds?
Say you're benchmarking three competitor brands across all three surfaces — ads, page identity, and marketplace listings — once a week. The Pages endpoint takes an array, so three brands is one call. Ads and Marketplace each take a single URL per call, so the same three-brand sweep is three separate ad-library calls and, if each brand runs its own marketplace storefront, three more. The batching difference doesn't change what data you get — it changes whether your weekly job is 1 request or 7.
What does each endpoint actually return?
Facebook Ads returns 21 fields per ad — headline,
body text, CTA, destination URL, format, start/end dates, days active, and
EU reach data where Meta discloses it. It's built for one page's ad
library at a time: urls takes a single page handle or URL, with
activeStatus to filter for currently-running vs. retired ads.
Facebook Pages returns 31 fields — followers,
category, contact details, business hours, review count, whether the page
is currently running ads, and links out to the brand's other social
profiles. pageUrls takes an array, so this is the one endpoint here
built for a batch pull from the start.
Facebook Marketplace returns 21 fields per listing — price, condition, location, delivery options, photos. It takes one category or search URL per call, so covering multiple cities or categories means one call each.
Which endpoint should you use for which job?
| Endpoint | Input | Price | Best for |
|---|---|---|---|
| Facebook Ads | One page URL per call | $0.005 / ad | Competitive ad-spend and creative research |
| Facebook Pages | Array of page URLs | $0.01 / page | Batch brand-identity benchmarking |
| Facebook Marketplace | One category/search URL per call | $0.01 / listing | Local price and listing data |
What can't you get from any of these?
Two cases.
Private pages and groups. Every endpoint here reads public data only — a private profile, a closed group, or a page that's blocked from public view returns nothing, by design, not a gap in coverage.
Ad data outside what a page discloses. The Ads endpoint returns what's actually in the public Ad Library for a given page. It doesn't reconstruct spend figures Meta itself doesn't publish for commercial (non-political) ads — that level of detail simply isn't public anywhere.
FAQ
No. All three endpoints — Ads, Pages, and Marketplace — run against public data with no login and no account connection required.
Not in a single call — the Ads endpoint takes one page URL per request. The Pages endpoint does take an array, so brand-identity data batches; ad and marketplace data currently doesn't.
No. The Ads endpoint returns what Meta's own Ad Library discloses publicly — creative, dates, reach where shown — not internal spend figures, which Meta doesn't publish for ordinary commercial ads.
Each of the three endpoints fetches live at request time rather than serving a cached snapshot, so a page's current follower count or an ad's current status reflects what's on Facebook right now.
