Meta Ad Library API Limitations: 7 Walls Developers Hit in 2026

Meta Ad Library API limitations follow a pattern that catches almost every developer who integrates it: the API is genuinely good at the job it was designed for, and quietly frustrating for the job most marketers hire it to do. Meta built it so journalists, researchers, and regulators could audit ad transparency around elections. It did not build it so you could watch a competitor scale a video hook across four markets.

That one distinction explains every wall in this article. Point the API at a competitive intelligence workload and you will hit seven of them, usually in the same order.

TL;DR: Meta's free Ad Library API is a political-ad transparency instrument, not a commercial research feed. Expect identity verification and a developer app before your first call, commercial ad coverage only for the EU and UK (a Digital Services Act requirement), spend and impressions as coarse buckets on political ads only, zero engagement metrics, roughly 200 Graph API calls per hour, and nothing from TikTok, LinkedIn, or YouTube. Each wall has a free workaround. Once research turns recurring and multi-platform, a paid option like the AdLibrary API (Business plan, €329/mo) is the upgrade path.

What Meta's Ad Library API was built for

The Ad Library API exists because of 2018. After Cambridge Analytica and a wave of election-interference scrutiny, Meta needed a way for outsiders to verify who was paying for political persuasion on its platforms. The API is that audit mechanism, and judged on those terms it holds up well.

Political and social-issue ads are archived worldwide and retained for seven years. Each record names the page, shows the creative text, discloses the payer, and publishes spend and impressions as ranges. For an election researcher, ranges are plenty. Nobody auditing a Senate race needs to know whether an ad got 12,400 or 13,100 impressions.

The EU's Digital Services Act then pushed the scope wider. Since the DSA's ad-repository rules took effect, every ad delivered to EU users appears in the archive regardless of topic, with reach data attached, for roughly twelve months. The UK gets similar treatment.

Technically, you query one Graph API endpoint: ads_archive. You pass search_terms or search_page_ids, a required ad_reached_countries, an ad_type, and a fields list. It returns paginated JSON.

The fields list is where the scope first shows itself. You can request page_name, ad_creative_bodies, ad_creative_link_titles, the delivery timestamps, publisher_platforms, languages, and the demographic and regional breakdowns that exist for political ads. Useful columns, all of them. What you cannot request matters more, and the seven walls below are essentially a tour of the missing ones.

None of this is a flaw. It is scope. Most Meta Ad Library API limitations are what happens when you ask a transparency instrument to behave like a research product, which is exactly what the next seven sections are about. The walls look much the same in the Ad Library web interface, so consider this the programmatic edition of that story.

Wall 1: App review, identity confirmation, and a token that expires

You cannot simply request an API key. Access to the Ad Library API starts with confirming your identity to Meta, government ID and location verification included, a process that routinely takes days. Then you create a developer account, register an app, and generate an access token.

That token is the part people underestimate. Long-lived user tokens expire after about 60 days, so every integration eventually faces the same Tuesday morning: the nightly job failed, the logs say the token is no longer valid, and someone has to re-authenticate before data flows again. You can build a refresh flow, and serious integrations do, but it is real engineering work for what is marketed as an open archive.

Here is a minimal first call once you are through the gate:

curl -G "https://graph.facebook.com/v21.0/ads_archive" \
  --data-urlencode "search_terms=protein powder" \
  --data-urlencode "ad_type=ALL" \
  --data-urlencode "ad_reached_countries=['DE']" \
  --data-urlencode "fields=page_name,ad_creative_bodies,ad_delivery_start_time,eu_total_reach,publisher_platforms" \
  --data-urlencode "access_token=$META_ACCESS_TOKEN"

Compare that with any commercial API where signup ends in a key. The Meta Ad Library API access requirements are not malicious. They are a transparency program's fraud controls. But if you budgeted an afternoon for the integration, budget a week instead. We covered the full setup sequence, quotas, and field list in our free API walkthrough.

Wall 2: Commercial coverage stops at the EU border

Of all the Meta Ad Library API limitations, this one ends the most commercial projects. The ad_type=ALL parameter, the one that returns regular product ads, only delivers results when ad_reached_countries points at EU member states or the UK. Everywhere else, the API serves political and social-issue ads exclusively.

The implication is brutal for competitor research. A US DTC brand running Facebook ads only to US audiences is invisible to the API. So is a Canadian SaaS company, an Australian retailer, or any advertiser that never targets Europe. You can see their ads in the consumer-facing Ad Library website. The programmatic surface returns nothing.

The EU exception exists because the DSA forces it, not because Meta chose to open commercial data. Which means the coverage follows the regulation's logic: ads delivered to EU users, kept for about a year, with EU-specific reach numbers. If the brand you track runs identical creatives globally, the EU window is a usable proxy. If they geo-split their strategy, you are reading the European edition and guessing at the rest.

Plenty of teams discover this wall only after shipping code, because the docs technically mention it while most tutorials skip it. The deeper inventory of hidden data is its own topic, and we wrote it up in what Meta Ad Library doesn't show you.

Wall 3: Spend and impressions arrive as buckets, when they arrive at all

Ask the API how an ad performed and you get one of three answers depending on the ad's category. Political and social-issue ads return impressions and spend as bounded ranges, something like {"lower_bound":"10000","upper_bound":"14999"}. Commercial ads delivered to the EU return eu_total_reach, a single number with no spend attached. Commercial ads outside the EU return nothing, because they are absent from the API entirely.

For transparency, buckets are fine. For creative research, they are nearly useless. You cannot rank a competitor's ads by spend when the field only exists on political ads. You cannot compute frequency without both reach and a real impression count. And you cannot compare two ads when both report "10,000 to 14,999."

What you can do is triangulate. A reach number plus market CPM benchmarks gives a defensible spend band: run the math with a CPM calculator or sanity-check the result against an ad spend estimator. Be honest with stakeholders that every figure produced this way is modeled. Paid tools that show per-ad spend do the same triangulation at scale, which is why credible ones label the number an estimate rather than a fact. We walk through the modeling approach in fixing the missing spend data problem.

Wall 4: No engagement data, full stop

Likes, comments, shares, saves, click-through rate: none of it exists anywhere in the Ad Library API. There is no bucketed version of these numbers and no review tier that unlocks them. The fields are simply absent.

That absence guts the most common research question, which is "which of these ads is working?" Public engagement rate is an imperfect performance signal, but it is a signal, and the consumer Ad Library at least renders the ad so a human can glance at social proof on the original post. The API hands you creative text and delivery dates, then leaves you blind.

The one performance proxy that survives is runtime. ad_delivery_start_time is always present, ad_delivery_stop_time appears when the ad stops, and the difference is the strongest free signal in the dataset. Advertisers kill losing creatives in days. An ad still delivering after 60 or 90 days is an ad somebody's budget keeps voting for. Sorting fetched results by computed runtime is the closest the free API gets to a winners list, and it is the backbone of any serious competitor ad monitoring workflow.

It works. It is also one-dimensional, and it tells you nothing about how hard an ad resonated, only how long it survived.

Wall 5: Rate limits built for audits, not pipelines

Ad Library API calls draw from your app's standard Graph API rate limit budget, which for a typical development-tier app works out to roughly 200 calls per hour per user token. Two hundred sounds workable until you remember that pagination counts.

Results come back about 25 per page by default. Pulling 10,000 ads for a broad keyword means around 400 paginated calls, which is two hours of budget gone on a single query, assuming nothing else touches the app. A nightly sweep across 20 competitor brands with a few hundred ads each will brush the ceiling regularly, and the API answers with throttling errors rather than slower service.

The Meta Ad Library API rate limits make complete sense for the intended audience. A journalist verifying one campaign's spend does not need a thousand calls an hour. A growth team monitoring a category does, and the budget math never closes. Note that this is a separate constraint from the Marketing API's quota system, which governs your own ad account data rather than the public archive, a distinction we unpack in the Meta Marketing API guide.

Survival tactics exist: narrow search_terms, filter by ad_delivery_date_min so you only page through new ads, cache everything keyed on ad ID, and honor throttling responses with real backoff. Watch the X-App-Usage response header while you page, too. It reports consumed quota as a percentage, and treating 80 percent as a stop signal is far cheaper than discovering the ceiling through error responses. These tactics reduce the pain. They do not raise the ceiling.

Wall 6: Meta platforms only, by definition

The Ad Library API covers Facebook, Instagram, Messenger, and Audience Network placements. That is the whole list, and it always will be, because Meta has no reason to index its competitors' ads.

Your competitors are less disciplined about staying on one network. The median DTC brand worth tracking runs Meta plus TikTok. B2B players concentrate budget on LinkedIn. Anyone serious about video is on YouTube. Each platform maintains its own transparency surface with its own rules: Google's Ads Transparency Center covers Google and YouTube ads, TikTok's Commercial Content Library covers EU-targeted TikTok ads, and LinkedIn's Ad Library covers sponsored content. Coverage depth, searchability, and API availability differ on every one.

So multi-platform research by free means is N separate projects, several of which offer no programmatic access at all and must be checked by hand. We have platform-specific guides for the gaps: the TikTok ad library, the LinkedIn ad library, and the YouTube coverage problem each get their own treatment.

If your category lives entirely inside Facebook and Instagram, this wall costs you nothing. For everyone else it is the quiet reason the "free" research stack ends up consuming the most engineer hours.

Wall 7: The record keeps shrinking behind you

The archive is permanent only for political ads, which stay seven years. Commercial EU ads persist for roughly a year after delivery. Commercial ads outside the EU were never in the API to begin with, and even in the consumer interface they vanish once the advertiser turns them off.

For research, that means the past is mostly unrecoverable. You cannot reconstruct what a competitor ran last Black Friday unless you captured it last Black Friday. Seasonal pattern analysis, arguably the most valuable use of ad history, only works if someone was archiving while the season happened.

The defense is boring and effective: snapshot everything your pipeline touches. Store the creative text, the delivery dates, the reach figures, and the ad_snapshot_url the day you fetch them, and your own database becomes the historical archive Meta does not offer. Practical export patterns are covered in how to export Meta Ad Library data, and the results slot naturally into a swipe file your creative team can actually search.

One tempting shortcut deserves a warning. Scraping the consumer Ad Library website to dodge the API's gaps violates Meta's terms, breaks whenever the markup shifts, and still only yields Meta data. We compared the scraping tools landscape if you want the long version. The short version: do not build a business process on it.

Working around Meta Ad Library API limitations without paying

Every wall above has a free mitigation. Stacked together, they form a workable research setup for a narrow set of use cases.

1. Route commercial queries through the EU. Set ad_type=ALL and point ad_reached_countries at major EU markets like ['DE','FR','NL']. Any brand advertising in Europe shows its commercial ads there, with eu_total_reach attached.
2. Treat runtime as your ranking signal. Compute days between ad_delivery_start_time and stop time (or today). Long-runners are your winners list.
3. Archive on every fetch. Your own snapshots are the only durable history. Key on ad ID, store dates and reach, never overwrite old rows.
4. Design for the rate limit. Narrow keywords, ad_delivery_date_min for incremental pulls, nightly batches instead of on-demand queries.
5. Track pages, not keywords. Once you know which brands you are watching, query search_page_ids (up to ten page IDs per call) instead of search_terms. Page-scoped pulls return tighter result sets, burn fewer paginated calls, and never miss an ad because the copy dodged your keyword.
6. Cover other platforms manually. A weekly 30-minute pass through the TikTok, Google, and LinkedIn transparency pages fills the multi-platform hole at zero cost, for a small competitor set.

A compact Python example combining tactics 1 through 4:

import requests, time

URL = "https://graph.facebook.com/v21.0/ads_archive"
params = {
    "search_terms": "running shoes",
    "ad_type": "ALL",
    "ad_reached_countries": "['DE']",
    "ad_delivery_date_min": "2026-06-01",
    "fields": "id,page_name,ad_creative_bodies,ad_delivery_start_time,eu_total_reach",
    "limit": 100,
    "access_token": ACCESS_TOKEN,
}
while True:
    r = requests.get(URL, params=params)
    if r.status_code == 429:
        time.sleep(60)
        continue
    data = r.json()
    archive_rows(data.get("data", []))   # your snapshot store
    nxt = data.get("paging", {}).get("next")
    if not nxt:
        break
    URL, params = nxt, {}

This setup genuinely suffices when your research is EU-centric, Meta-only, low-frequency, and tolerant of modeled performance numbers. That describes more teams than the tooling industry likes to admit. Stay clear-eyed about which constraints you accepted, though, because the workarounds patch the walls without removing them.

When Meta Ad Library API limitations justify a paid upgrade

The honest dividing line is recurrence and breadth. A one-off audit, an EU-focused project, or political-ad compliance work belongs on Meta's free API, no contest. It is the originator of programmatic ad transparency and the correct tool for transparency jobs.

The calculus flips when three things become true at once: the research repeats on a schedule, it spans platforms beyond Meta, and decisions depend on performance signals the free API does not carry. Meta's free API is fine for one platform. The moment you want TikTok, YouTube, or LinkedIn data in the same query, you need something else.

That something else is what the AdLibrary API is for. It is a paid REST API, deliberately positioned as the power-user upgrade rather than a replacement, and it answers each wall directly. One adl_ key created in your dashboard, with no app review, no identity verification, and no 60-day token rotation. Eleven platforms in one call: Facebook, Instagram, TikTok, YouTube, Google, LinkedIn, Twitter, Pinterest, Yahoo, Unity Ads, and AdMob. Every ad carries engagement counts, impressions, an estimated spend figure (estimated, always), runtime, and a heat score for momentum. An AI enrichment endpoint turns any single ad into a full creative teardown plus a replication brief.

One search costs one credit, a failed search refunds automatically, and the search response includes a total count so you know the size of a market before paging deeper:

curl "https://adlibrary.com/api/search" \
  -H "Authorization: Bearer adl_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "keyword": "running shoes",
    "platform": ["facebook", "tiktok", "youtube"],
    "geo": ["USA"],
    "adsType": ["2"],
    "sortField": "-days",
    "daysBack": 90
  }'

That sortField: "-days" sorts by runtime, the same winners-by-survival logic from Wall 4, except computed across platforms and paired with engagement so the signal is two-dimensional. Teams wire it into automated competitor monitoring, scheduled n8n recipes, Claude Code research workflows, or a self-built MCP server. The full endpoint catalog lives in the API documentation guide.

API access sits on the Business plan at €329/mo, which includes 1000+ monthly credits, dedicated team seats, and free integration help, meaning someone from the team helps wire the API into your stack. If you want to inspect the data before committing to automation, the Starter tier at €29/mo lets you run real searches in the app first.

Run the build-vs-buy math on the free stack honestly before deciding. Budget a day of engineering for the token refresh flow, another for the snapshot store, recurring hours every time Meta renames a field, and a weekly manual pass across three other transparency sites that nobody enjoys owning. At typical contractor rates that maintenance burn crosses €329 well before the first month ends. For agencies and in-house teams doing daily competitor ad research, the math usually resolves within one billing cycle.

Frequently Asked Questions

Does the Meta Ad Library API show commercial ads?

Only for ads delivered to the EU and UK, where the Digital Services Act requires Meta to publish all ad types for roughly twelve months. Everywhere else the API returns political and social-issue ads exclusively. A brand that only targets US audiences will not appear in API results at all, even though its ads are visible in the consumer Ad Library website.

Why doesn't the Meta Ad Library API show spend or impressions for competitor ads?

Exact performance data was never in scope. Political and social-issue ads carry spend and impressions as bounded ranges, like 10,000 to 14,999. Commercial EU ads carry a single eu_total_reach number with no spend field. Commercial ads outside the EU return nothing. Tools that display per-ad spend for commercial ads are modeling an estimate from reach and CPM benchmarks, not reading a disclosed figure.

What are the Meta Ad Library API rate limits?

Calls share your app's standard Graph API budget, roughly 200 calls per hour per user token for a development-tier app, and every pagination request counts against it. Paging through 10,000 results at 25 per page consumes about 400 calls. Throttling responses include retry guidance, so production integrations need backoff logic, caching, and incremental date-filtered pulls.

Does the Meta Ad Library API cover TikTok, LinkedIn, or YouTube ads?

No. It covers Meta placements only: Facebook, Instagram, Messenger, and Audience Network. TikTok, Google/YouTube, and LinkedIn each run separate transparency surfaces with different coverage rules and, in several cases, no public API. Getting every platform into one programmatic feed requires a third-party aggregation API.

Is there a paid alternative to the Meta Ad Library API?

Yes. The AdLibrary API is a paid upgrade designed for commercial research rather than transparency auditing. It returns ads from eleven platforms through one API key, with engagement counts, impressions, estimated spend, runtime, and a heat score per ad, plus AI creative teardowns. It requires a Business subscription at €329/mo and is not a replacement for Meta's free API in political-transparency work.

Which side of the line is your use case on?

Meta's Ad Library API deserves more respect than it gets in marketing circles. It costs nothing, and as the original programmatic window into ad spy territory it remains the canonical source for political-ad transparency. The Meta Ad Library API limitations that frustrate developers are mostly the visible edges of a deliberate scope decision, not negligence.

So draw the line honestly. For transparency work, EU-scoped research, or a one-off audit, stay on the free API — the workarounds above will carry you, and archiving as you go covers the history problem. Recurring multi-platform competitive research with performance signals is a different job, one that was never inside the free API's scope, and no amount of clever pagination will put it there. When your use case lands in that second category, API access on the Business plan is where the upgrade starts.