Facebook ad library api

The Facebook Ad Library API was launched alongside the public Ad Library UI in 2018 as part of Meta's regulatory response to the 2016 election disinformation cycle. The original target audience was journalists, academic researchers, and civil-society organizations auditing political and issue advertising at scale - use cases where manual UI review would have been impossibly slow. Commercial-ad coverage was added later, primarily in jurisdictions where regulators mandated commercial advertising transparency (EU under the Digital Services Act, Brazil under similar laws).

This regulatory origin shapes the API's access model. Business verification, the documentation tone, the rate limits, and the EU/Brazil-only commercial scope all flow from 'this is a transparency tool we built because regulators required us to', not 'this is a developer platform we want third parties to build on'. Meta has no commercial incentive to make the API friction-free for competitive marketing; the API exists to satisfy regulators while disclosing the minimum required data.

Practical consequence: if you're a marketer in the US, UK (post-Brexit), Canada, Australia, or anywhere outside the EU/Brazil, the API will not give you commercial-ad data even after you complete business verification. You'll get political ads. For commercial research you'll need the UI (manual or scraped) or a paid third-party tool that maintains the scrape layer at scale.

Meta's commercial-ad API coverage is bound by the regulatory regimes that mandate the disclosure. EU member states are covered because the Digital Services Act (DSA) requires Very Large Online Platforms (Meta qualifies) to maintain a queryable repository of all advertising shown to EU users, including commercial ads. Brazil is covered because Brazilian election and advertising transparency law requires similar disclosure. No other jurisdiction has mandated commercial-ad disclosure at the same level, so Meta has not extended the API's commercial coverage outside these regions.

The practical workflow split: if your competitors run ads in the EU or Brazil, you can query their commercial-ad data programmatically via the API by setting ad_reached_countries to those regions. The data you get back includes the full creative metadata (copy, snapshot URL, platforms, dates) and the same gaps as the UI (no spend, no engagement, no targeting). If your competitors run ads only in non-covered regions, the API will return their political ads (typically none for commercial brands) and nothing else.

Workaround for non-EU/Brazil markets: route your research through EU-targeted queries when the competitor is multinational. A US brand that also runs ads in Germany will have those German-targeted ads exposed via the API; you can use the German data as a proxy for what the brand is doing globally. Imperfect (the creative may be localized) but better than nothing.

The 200-calls-per-hour-per-token rate limit is the operational bottleneck most teams hit first. The limit resets on a rolling hour, not at the top of the hour - so burst queries get throttled even if you 'spread' them across calendar hours.

Three patterns that survive the rate limit. Multi-token rotation: maintain 4-8 access tokens (each tied to a separate App, all owned by the same Business Manager) and rotate calls across them. The 200/hour limit is per-token, not per-app. Aggressive caching: most competitive monitoring queries don't need real-time data. Cache responses for 12-24 hours and serve from cache rather than re-hitting the API on every internal request. Incremental queries: instead of refetching a full competitor's ad set every run, query only ad_delivery_date_min={yesterday} to get new launches, and re-fetch the full set weekly. Cuts call volume by 90%+ for steady-state monitoring.

If you have a documented use case (research project, agency client deliverable, internal product), you can request a quota increase through the App dashboard. Meta rarely denies legitimate requests but adds a 1-2 week review cycle. For most agencies and research projects, the rate limit is a real constraint worth planning around rather than ignoring.

Three viable paths for programmatic library access in 2026, each with a different fit. The official API is the right path when you're operating in EU/Brazil markets (where commercial coverage exists), you need clean structured data, you can absorb the business-verification timeline, and you can engineer around the rate limits. Strong fit for academic research, regulatory-compliance audits, and EU-focused competitive monitoring.

UI scraping is the de facto path when you're operating outside EU/Brazil markets and need commercial-ad data. It's against Meta's terms of service - which has not stopped a multi-hundred-million-dollar third-party tool industry from doing it at scale - but exposes you to IP blocks, DOM-change breakage, and CAPTCHA challenges. Building and maintaining a scraper internally typically requires a dedicated engineering resource. For most teams it's not worth the maintenance overhead vs paying for a third-party tool that has already solved the scraping problem.

Third-party tools (Foreplay, Atria, Motion, AdSpy, Minea) maintain the scrape infrastructure, layer hook-tagging and AI classification on top, and resell access at $50-500/mo per seat. For competitive marketing teams this is almost always the right choice over building yourself - you get the data plus the tagging layer plus the maintenance team, without the engineering burden. Pair with the official API for EU/Brazil markets if you need structured exports for academic or compliance use cases.

Internal: Foreplay deep dive, Atria deep dive, Motion deep dive cover the leading paid tools and how they layer on top of the API.