Facebook API Without the Graph API: How We Get Data in 2026

The last time I opened the Facebook Graph API changelog I noticed something funny: Meta now deprecates a major version about every twelve months, and every deprecation breaks at least one endpoint we used to rely on. Page Insights for unowned pages went first. Public reactions counts went next. Hashtag search has been gated behind a permission flow that takes weeks to get approved, and the approval has been getting harder, not easier.

If you've been writing code against graph.facebook.com for a while, you know what I mean. The endpoints you actually want — public page data, posts on a competitor's page, marketplace listings, ad transparency — are the ones Meta progressively removed, gated, or scoped out of the v15 → v22 migration path.

This is the post I wish I'd had two years ago, when I started looking for an alternative.

What "Facebook API" actually means today

There are three different things people call "the Facebook API," and conflating them costs developers weeks of unnecessary OAuth work.

1. The Graph API. Official, OAuth-gated, app-review-gated. Great for first-party data: your own page, your own ads, your own users who logged in with Facebook. Terrible for everything else. The endpoints for public data on pages you don't own have been shrinking every release since the 2018 Cambridge Analytica response, and nothing about that direction has reversed.

2. The Marketing API. A subset of Graph that costs nothing extra in licensing but requires Business Verification, an active ad account, and a use case that maps to "you spend money on ads." If you're trying to read someone else's page data without spending on their ads, this is not your path.

3. The Ad Library API. Real, useful, public, and the only Meta-sanctioned route to political/social-issue ad data. It works. It also covers nothing outside that vertical, which is the whole point of it existing.

If the data you want is in one of those three buckets, use them. Stop reading this post.

If the data you want is on a public page that you don't own, on a marketplace listing, on a public reel, in a public group, or returned by Facebook's own search — none of those buckets help you. That's where this post starts.

Why developers stop using the Graph API for public data

The four pain points I hear from every customer who migrated to us:

1. App review. A real human at Meta reads your data-use justification and decides. The median timeline to get pages_read_engagement approved went from two days in 2019 to over three weeks in 2024. The rejection rate climbed alongside.

2. OAuth for data you can read in a browser without logging in. This is the absurd one. You can open facebook.com/nike in an incognito window and see the page, posts, follower count, and reactions. To read the same data through Graph you need the page owner to install your app and grant scopes. The mismatch between what's publicly visible and what's API-accessible has grown wider every year.

3. Version churn. v22 broke a query I was running against v20 in production. The breaking change was in the response shape — a field went from string to object with value and currency keys. Tests caught it but only because we had end-to-end ones; the Graph SDK didn't type-error.

4. Scope creep on permissions. Permissions that used to be Standard Access (no review) get bumped to Advanced Access (review required) over time. user_posts did this. pages_read_engagement did this. Plan for the scope you use today to require review tomorrow.

This is not a complaint piece — it's a statement of what we observed. Meta is optimizing the platform for ad sales, not for third-party developers reading public data. That's a defensible product decision. It also means if you're building anything that depends on public Facebook data, the Graph API is a slow path to a closed door.

What developers used before we existed

Three approaches predate us. I want to name them because they shaped how I think about ours.

kevinzg/facebook-scraper — 9.5k stars on GitHub. The most-starred OSS Facebook scraper, written by Kevin Zg, last commit 2022. It still works for some endpoints, breaks on others, and is maintained by one human against Meta's full anti-scraping team. The repo isn't "dead" — it's just an asymmetric fight.

arc298/instagram-scraper — same shape on the Instagram side. 8.5k stars, sporadic maintenance, runs on instaloader under the hood. Works for account-level data, less so for hashtag and location endpoints.

Selenium + BeautifulSoup pipelines. The DIY route. Spin up a headless Chrome, log in with a burner account, scrape the rendered HTML. There's a popular Medium post from AbdelRhman Sabry that walks through the 2025 version of this approach. It works. It also costs you a maintenance budget you didn't sign up for: Facebook ships DOM changes every four to six weeks, and every change breaks your selectors.

The honest summary: these tools work for small-scale, low-frequency use. The moment you cross into production-grade traffic — 50+ requests per second, 24/7 uptime, real customer SLAs — the maintenance bill exceeds the cost of a paid API by a wide margin.

We chose to build that paid API.

What we built: SocialAPIs

The product is a REST API that wraps the public data layer of Facebook and Instagram into stable, versioned endpoints. We maintain the scraping layer (proxies, rotation, anti-bot handling, DOM-change resilience); you make HTTP calls and get JSON back.

The shape of the API was designed to be the opposite of Graph:

• No OAuth, no app review. You sign up, get an API token, start calling. The token authenticates you (so we can meter usage); the data you read is the same public data Facebook serves to a logged-out browser.
• One endpoint per resource. /facebook/pages/details, /facebook/pages/posts, /facebook/marketplace/search, /facebook/ads-library/search. Read the full endpoint reference if you want the surface map.
• Stable response shapes. When Facebook changes a DOM ID, we update the scraper, not your code. The JSON shape we return is versioned and tested.
• Free tier for evaluation. 200 calls per month, no credit card. Enough to integration-test before you decide whether to pay.

We officially launched the platform in 2024. As of June 2026, we serve 7.2M+ API calls per month across 364 paying customers. That's the traction screenshot on our about page, with the actual RapidAPI dashboard.

Working code

You should run these against the free tier before deciding whether the API maps to your use case. Generate a token at socialapis.io/auth/signup and replace YOUR_API_TOKEN below.

curl

1# Page details — name, followers, category, contact info
2curl --request GET \
3  --url 'https://api.socialapis.io/facebook/pages/details?link=https%3A%2F%2Ffacebook.com%2Fnike' \
4  --header 'x-api-token: YOUR_API_TOKEN'
5
6# Page posts — last few public posts with reactions + media
7curl --request GET \
8  --url 'https://api.socialapis.io/facebook/pages/posts?link=https%3A%2F%2Ffacebook.com%2Fnike&limit=3' \
9  --header 'x-api-token: YOUR_API_TOKEN'
10
11# Marketplace search — public listings
12curl --request GET \
13  --url 'https://api.socialapis.io/facebook/marketplace/search?query=playstation' \
14  --header 'x-api-token: YOUR_API_TOKEN'

The first call returns within 1–2 seconds and looks like this (truncated):

1{
2  "page_id": "15087023444",
3  "name": "Nike",
4  "username": "nike",
5  "followers_display": "38M followers",
6  "verified": true,
7  "category": "Sports & Recreation",
8  "website": "http://www.nike.com",
9  "address": null
10}

Python

We ship an official SDK at pypi.org/project/socialapis-sdk. It covers all 51 endpoints across Facebook + Instagram + your usage account.

1# pip install socialapis-sdk
2from socialapis import SocialAPIs
3
4client = SocialAPIs(api_token="YOUR_API_TOKEN")
5
6# Page details
7page = client.facebook.pages.details(link="https://facebook.com/nike")
8print(page["followers_display"], page["category"])
9
10# Page posts — limit caps at 9, charges scale with what's actually returned
11posts = client.facebook.pages.posts(link="https://facebook.com/nike", limit=3)
12for p in posts["data"]["posts"]:
13    print(p["details"]["post_id"], p["values"].get("text", "")[:80])

The Python SDK's source is on GitHub — MIT-licensed, Trusted-Publishing via OIDC, no external runtime dependencies beyond requests. If you're migrating from kevinzg/facebook-scraper, the companion landing repo has a side-by-side migration example.

JavaScript / TypeScript

1// npm install socialapis-sdk
2import { SocialAPIs } from "socialapis-sdk";
3
4const client = new SocialAPIs({ apiToken: process.env.SOCIALAPIS_TOKEN });
5
6const page = await client.facebook.pages.details({
7  link: "https://facebook.com/nike",
8});
9console.log(page.followers_display);
10
11// Promise-based, camelCase, ESM-first. Runs on Node 18+, Bun, Deno, browser.

Source: github.com/SocialAPIsHub/socialapis-js. Published to npm at v0.1.1 (June 2026).

Go

1// go get github.com/SocialAPIsHub/socialapis-go
2import (
3    "context"
4    "github.com/SocialAPIsHub/socialapis-go/socialapis"
5)
6
7client := socialapis.New(socialapis.WithToken(os.Getenv("SOCIALAPIS_TOKEN")))
8
9page, err := client.Facebook.Pages.Details(ctx, &socialapis.PageDetailsRequest{
10    Link: "https://facebook.com/nike",
11})

Idiomatic Go: context-first arg, functional options, typed errors via errors.As, zero external deps. Source repo.

When the Graph API is still the right answer

This isn't a "Graph API is bad, use ours instead" post. There are real cases where Graph wins:

• You're publishing data, not reading it. Posting to your own page, scheduling content, replying to messages — Graph is the only path. We don't compete here.
• You're reading data on a Page you own and admin. Page Insights for your page (impressions, demographics) is in Graph and we don't replicate it. We can't — that data is auth-walled by design.
• You're integrating Login With Facebook. OAuth identity flow → Graph.
• You need Meta's official ad transparency dataset. Use the Ad Library API directly. We do offer a /facebook/ads-library/search endpoint that wraps the same underlying data with the structure that's easier to query, but if you only need ad-library data and don't mind Meta's response format, hit them directly.

The pattern: first-party data (yours) → Graph. Public data on someone else's page → us, or a self-maintained scraper.

What this costs

The free tier is 200 calls/month, intended for integration testing. Paid plans start at $4.99/month (Free → Pro → Ultra → Mega). Detailed pricing including per-call breakdowns is on the pricing page. Variable-priced endpoints (where the cost depends on how much data you actually receive) report the resolved charge in an X-SocialAPIs-Credits-Deducted response header, so you can reconcile usage directly from your client without opening the dashboard.

If you're wondering how that compares to Bright Data / Apify / RapidAPI / ScraperAPI, we have a comparison hub with one page per competitor. The short version: we're typically 50–90% cheaper than Bright Data for the same data, and our latency is lower than most managed-scraper alternatives because the API itself is single-purpose (we don't proxy generic HTTP, we serve scoped endpoints).

A note on durability

The risk in any "wrapped scraper as a service" model is: what happens when Facebook breaks the scraper? Our answer is operational. We have a real engineering team monitoring Meta's DOM changes, multi-region proxy rotation, and we eat the cost of fixing breakage so you don't have to write code for it. When Meta shipped the November 2024 follower-count DOM change that broke every OSS scraper, our SLA was a 4-hour fix window. The Mongo-stored request log on our admin side caught it, we patched, and our customers' integrations kept working. That kind of operational resilience is the actual product, not the API surface.

If you want to read more about how we built that infrastructure, the MCP launch post covers the AI-agent side, and the API best practices post walks through how we recommend customers structure their own clients on top of our API.

TL;DR

If you've been fighting the Graph API for permissions you can't get, scopes that keep moving, or app reviews that don't complete — there's a real alternative now. It's REST, it's documented, it has SDKs in Python / JS / Go, and it has a free tier you can use to evaluate before paying anything.

If you want to try it: create a free account, grab a token, and run one of the curl commands above. Should take about three minutes start to finish.

If you'd rather email about a specific use case before you start: contact us or DM on Telegram — both reach the founding team directly.