Find Any Brand's Advertiser ID (Meta, Google, LinkedIn)

Before you can pull a single competitor ad programmatically, you have to find the advertiser ID that the platform actually keys its ads on. Meta uses one system, Google uses another, and LinkedIn uses a third. Feed the wrong type into the wrong endpoint and your workflow errors out or, worse, returns data for a completely different company. ID resolution is step zero of every competitor ad research pipeline, and it should cost you nothing.

TL;DR: Every ad platform keys advertisers differently. Meta uses a numeric page ID, Google's Ads Transparency Center uses an AR-prefixed advertiser ID, and LinkedIn uses a numeric company ID. You can find each one manually through the platform's own transparency surface, or resolve all three with one free call to the AdLibrary API's advertisers/search endpoint. Store the result in a saved-advertiser watchlist and you never resolve the same brand twice.

This guide covers what each ID looks like, where each platform exposes it, how to find advertiser IDs manually per platform, the one-call API route, and the ID mix-ups that quietly break otherwise solid automation.

Why finding the advertiser ID is step zero

Brand names are for humans. Ad platforms don't index ads under "Nike" or "Gymshark" — they index them under stable identifiers that survive rebrands and disambiguate the seventeen other pages that also have "Nike" in their name.

That matters the moment your research becomes programmatic. A human scrolling the Meta Ad Library can eyeball which "Gymshark" result is the real one. A script cannot. Your script needs the exact numeric page ID, and it needs to know that the same brand answers to a totally different identifier on Google and a third one on LinkedIn.

Get this wrong and the failure is rarely loud. A keyword search for a brand name returns ads from resellers and fan pages mixed in with the brand's own creatives. Your competitor monitoring job runs every night and reports numbers that are quietly polluted. Nobody notices for a month.

Get it right once, and every downstream call becomes precise. A search scoped to a page ID returns that advertiser's ads and nothing else. That precision is the entire difference between ad intelligence and noise.

Three platforms, three ID systems

Here is the core problem in one table:

Three formats, zero overlap. A Meta page ID is pure digits. A Google advertiser ID always starts with AR. A LinkedIn company ID is also pure digits, which is exactly why it gets confused with Meta page IDs — more on that failure mode below.

There is no universal advertiser registry. Each platform built its ad transparency surface independently, under different regulatory pressure, with different internal data models. The EU's Digital Services Act forced ad repositories into existence, but it never standardized the keys. So resolution (mapping one brand name to all three advertiser IDs) is a job you have to do yourself, or delegate to an API that does it for you.

Meta: the page ID

On Meta, ads belong to a Facebook Page, not to an ad account. The page ID is the identifier the Meta Ad Transparency Center and the Ad Library both key on.

Manual lookup route:

1. Open the Meta Ad Library and search the brand name.
2. Click through to the page's ads. Look at the URL: it now contains view_all_page_id=<digits>. That number is the page ID.
3. Cross-check on the brand's Facebook Page itself. Scroll to the Page transparency section in the About tab — Meta displays the page ID there along with the page's creation date and name history.

The name-history detail is underrated. A page that was called "Best Deals Store" eight months ago and is now a "premium watch brand" tells you something the ads never will.

One brand is rarely one page. Nike alone operates Nike, Nike Football, Nike Run Club, and more, each with its own page ID and its own ad portfolio. If you only resolve the flagship page, your analysis silently excludes entire product lines. Collect every page ID the brand operates before you call the research done.

If you plan to query Meta's own Ad Library API (the free one), the page ID goes into the search_page_ids parameter. Worth knowing before you build on it: outside the EU and UK, Meta's free API only returns political and social-issue ads, and access requires identity verification plus an app review. The full trade-offs are in our breakdown of the Meta Ad Library free API.

Google: the AR… advertiser ID

Google's transparency surface is the Ads Transparency Center, and it keys advertisers on verified advertiser IDs that start with AR followed by a long string of digits.

Manual lookup route:

1. Go to adstransparency.google.com and search the brand.
2. Pick the right advertiser from the results — check the verified legal name, not only the display name.
3. Click through to the advertiser's page. The URL now reads adstransparency.google.com/advertiser/AR…. Copy everything from AR onward. That's the advertiser ID.

The legal-name check matters more on Google than anywhere else. Google verifies advertisers against registered business entities, so the brand you know as "Vuori" might be listed under "Vuori, Inc." while a European reseller shows up under an unrelated GmbH. Two entities, two AR IDs, two completely different ad portfolios. The Google Ads ecosystem also spans Search, YouTube, Display, and Shopping, all rolled up under that one advertiser ID, which makes it the densest single identifier of the three.

Regional entities are the other trap. Multinationals often verify separate legal entities per market. If your research targets German ad activity, resolve the brand with a German country context, or you may pull the US entity's ID and wonder why the geo-filtered results look thin.

LinkedIn: the numeric company ID

LinkedIn is the platform that hides its ID best. Every company page has a numeric company ID, but the public page URL usually shows a vanity slug instead: linkedin.com/company/gymshark rather than linkedin.com/company/3217425. Both resolve to the same page. Only the number works as an API key.

Manual lookup routes:

1. The redirect trick. If you can find any link to the company in its numeric form (old embeds and job postings often use it), linkedin.com/company/<digits> redirects to the vanity URL, confirming the mapping.
2. Page source. Open the company page, view source, and search for urn:li:organization:. The digits after the final colon are the company ID. LinkedIn's own Marketing API documentation confirms this URN format, urn:li:organization:<id>, as the canonical organization identifier.
3. The LinkedIn Ad Library. Search the brand at linkedin.com/ad-library to confirm the company actually runs ads before you bother extracting the ID. Our LinkedIn Ad Library guide covers what that surface shows and what it withholds.

Two LinkedIn-specific gotchas. First, search results mix companies with people, and a person profile has no usable company ID at all. Second, some company entries are restricted and expose no ID publicly. Any resolution workflow needs to detect both cases instead of blindly grabbing the first result. If most of your competitor set is B2B, it's worth the effort — LinkedIn ads carry spend signals that rarely show up anywhere else, and you can now search the LinkedIn Ad Library by company URL directly inside AdLibrary.

Find all three advertiser IDs in one free call

The manual routes work. They also take ten to fifteen minutes per brand once you include cross-checking, and they don't compose into a script. If you're resolving one competitor, do it by hand. If you're resolving forty for an agency client audit, you want one call per brand.

The AdLibrary API has an endpoint built for exactly this, and it costs zero credits:

curl -G "https://adlibrary.com/api/advertisers/search" \
  -H "Authorization: Bearer adl_your_api_key" \
  --data-urlencode "q=gymshark" \
  --data-urlencode "country=US"

The endpoint fans out to Meta typeahead, Google, and LinkedIn in parallel and returns every candidate per platform, plus a best_match when at least two platforms agree on the normalized brand name:

{
  "query": "gymshark",
  "country": "US",
  "best_match": {
    "name": "Gymshark",
    "confidence": 1.0,
    "meta": {
      "id": "100690651963843",
      "name": "Gymshark",
      "verified": true,
      "likes": 2400000,
      "ig_username": "gymshark"
    },
    "google": {
      "id": "AR06463633633054818305",
      "name": "Gymshark",
      "legal_name": "Gymshark Ltd",
      "ad_count": 412
    },
    "linkedin": {
      "id": "3217425",
      "name": "Gymshark",
      "ad_count": 25
    }
  },
  "candidates": {
    "meta": ["…full candidate list…"],
    "google": ["…"],
    "linkedin": ["…"]
  }
}

One request, all three identifiers, in the exact formats every downstream endpoint expects. This is the kind of quality-of-life difference between building on a paid research API and stitching together three free transparency surfaces yourself. Meta's free Ad Library API is the originator here and remains the right tool for single-platform political-ad transparency work. The moment you add Google or LinkedIn data into the same query, you need something that resolves across platforms — which is what the multi-platform coverage in AdLibrary is for.

The resolution call requires an API key (format adl_…, created in your dashboard on the Business plan), but the call itself never deducts credits. You can resolve a thousand brands without spending one. The full endpoint list and auth details live in the adlibrary API documentation.

Reading the resolution response

A few fields in that response deserve attention before you wire it into anything automated.

confidence tells you how much the platforms agree. A value of 1.0 means all three platforms matched the same normalized brand name. 0.66 means two of three agreed. No best_match at all means the platforms disagree, and you should inspect the candidates arrays manually rather than trusting an automated pick. Disagreement is common with generic brand names, holding companies, and brands that operate under different trading names per region.

legal_name is your Google sanity check. When the display name matches but the legal name is an entity you've never heard of, slow down. You may be looking at a reseller or a regional licensee.

ad_count is a free activity signal. A LinkedIn match with ad_count: 0 resolved correctly but has nothing for you to research there. Use that to skip platforms per brand instead of paying for empty searches later.

LinkedIn entries flagged is_person or is_restricted carry no usable ID. The endpoint already excludes them from best_match, but if you parse the raw candidates yourself, filter them out before saving anything.

country changes the answer. Resolution defaults to US context. A brand with separate regional entities can return different Google advertiser IDs for country=US versus country=DE. If your research is market-specific, resolve per market.

The five ID mix-ups that kill workflows

Almost every broken programmatic research pipeline I've seen traces back to one of five confusions. Check your own setup against each.

1. Feeding a Google AR… ID where a Meta page ID belongs. The classic. Both are "the advertiser ID" in casual conversation, so they end up in the same spreadsheet column, and eventually an AR-prefixed string gets posted to an endpoint that validates ^\d+$ and rejects it. Best case you get a 400. Worst case a truncation step strips the letters and you query a random numeric ID that happens to exist. Keep the three ID types in three separate fields, always.

2. Confusing Meta page IDs with Meta ad account IDs. Meta's Marketing API identifies ad accounts as act_<digits> — that's the buying side. Transparency surfaces key on the page, not the account. An act_ ID is useless in any ad library context, and a page ID is useless in the Marketing API's account endpoints. If your team also runs ads through the Marketing API, label the columns explicitly, because both are "the Facebook ID" to whoever inherits the sheet.

3. Using LinkedIn vanity slugs as IDs. gymshark is a slug, not an ID. APIs want 3217425. Slugs also get rebranded (companies change vanity URLs after acquisitions) while the numeric company ID stays stable. Store the number.

4. Resolving the flagship page and calling it done. The Nike problem. Multi-page brands need every page ID collected, or your "complete portfolio analysis" covers a third of the portfolio. This is also why a proper watchlist entry holds arrays of IDs per platform rather than a single value.

5. Trusting a name match without a verification check. "Ray-Ban" in an ad library search returns the brand plus a wall of counterfeit stores. The verified badge, the legal name, the follower count, and the page's ad volume are your authenticity signals. A script that picks result number one by string similarity will eventually save a counterfeiter's page ID into your competitor watchlist and faithfully monitor it for months. Our guide on finding competitor ads walks through brand verification in the manual workflow too.

Store what you resolved: build a watchlist

Resolution output is too valuable to throw away after one search. The pattern that works: resolve once, persist the IDs, and run every future pull against the stored record.

The AdLibrary API bakes this in with saved advertisers. Saving is free:

curl -X POST "https://adlibrary.com/api/advertisers" \
  -H "Authorization: Bearer adl_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Gymshark",
    "domain": "gymshark.com",
    "meta_page_ids": ["100690651963843"],
    "google_advertiser_ids": ["AR06463633633054818305"],
    "linkedin_company_ids": ["3217425"]
  }'

Each platform field accepts an array, which solves the multi-page brand problem directly: one watchlist entry for Nike holds every Nike page ID. At least one platform array must be non-empty, and you can PATCH the record later as you discover additional pages or the brand verifies a new regional entity.

The payoff comes at pull time. One request fans out across every stored ID on every platform and returns each platform's ads alongside pagination cursors:

curl -X POST "https://adlibrary.com/api/advertisers/<advertiser-uuid>/curate" \
  -H "Authorization: Bearer adl_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{}'

That curate call costs 1 credit and opens a 30-minute session in which continued pagination is free. Compare that to running separate per-platform searches at 1 credit each per page, and the watchlist pattern pays for itself the first morning you run it. It's the same mechanism behind the saved ads workflow in the app, exposed as an endpoint.

If you'd rather scope a one-off search than maintain a watchlist, the ID short-circuits on /api/search do that: metaPageId restricts the search to that Meta page, linkedinCompanyId to that LinkedIn company, and googleAtcAdvertiserId to that Google advertiser. Same IDs, different entry point.

Wiring resolution into scripts and agents

Here's the whole step-zero pattern in one Python loop — resolve a brand list, verify the match, persist the watchlist:

import requests

BASE = "https://adlibrary.com"
HEADERS = {"Authorization": "Bearer adl_your_api_key"}

brands = ["Gymshark", "Alo Yoga", "Vuori"]

for brand in brands:
    r = requests.get(
        f"{BASE}/api/advertisers/search",
        headers=HEADERS,
        params={"q": brand, "country": "US"},
    )
    data = r.json()
    match = data.get("best_match")

    if not match or match["confidence"] < 0.66:
        print(f"{brand}: platforms disagree, review candidates manually")
        continue

    payload = {"name": match["name"]}
    if match.get("meta"):
        payload["meta_page_ids"] = [match["meta"]["id"]]
    if match.get("google"):
        payload["google_advertiser_ids"] = [match["google"]["id"]]
    if match.get("linkedin") and match["linkedin"].get("id"):
        payload["linkedin_company_ids"] = [match["linkedin"]["id"]]

    saved = requests.post(f"{BASE}/api/advertisers",
                          headers=HEADERS, json=payload)
    print(f"{brand}: watchlisted as {saved.json()['advertiser']['id']}")

Forty brands, forty free resolution calls, forty free saves, zero credits. The paid work starts only when you actually pull ads.

This is also the natural first tool for an AI agent doing ad research. An agent that monitors competitors needs deterministic identifiers before it can do anything useful, and a free resolution endpoint means the agent can self-correct on ambiguous brands without burning budget. The Claude Code + adlibrary API workflows guide builds on exactly this step-zero call, the agentic marketing workflows piece shows the always-on version, and if you want it as a native tool you can build your own MCP server around it in an afternoon. The same resolve-then-pull pattern drops into n8n automation recipes if visual workflows are more your team's speed, or into a scheduled competitor monitoring setup.

Once the IDs flow, the downstream analysis gets interesting fast. Pull a brand's full footprint, then run the volume through the ad spend estimator to gauge what their presence costs, or sanity-check their Meta investment against benchmarks with the Facebook ads cost calculator. None of that works without correct IDs underneath.

What ID resolution costs (and what it doesn't)

Worth stating plainly, because pricing anxiety makes people skip step zero and regret it.

On the AdLibrary API, resolution is free. advertisers/search costs 0 credits, saving and updating watchlist entries costs 0 credits, and a curate pull costs 1 credit per 30-minute session. Searches cost 1 credit per page. AI creative enrichment costs 1 credit per ad. The metering starts where the data starts, never at resolution.

API access itself sits on the Business plan at €329/mo with 1000+ monthly credits, which is the tier built for exactly the scripted and agent-driven workflows this article describes. If you're weighing that against Meta's free API, the honest framing: Meta's API costs nothing and is the right choice if political and social-issue ads on Meta are all you need. It also requires identity verification, an app review, and a token that expires every 60 days. The paid route exists for commercial ads, for the other platforms, and for teams whose time is the actual expensive resource. The comparison details are on the API access feature page, and pricing has the full tier breakdown.

For ongoing competitive intelligence programs, the kind where you automate competitor ad monitoring across a whole client roster, the resolution layer is what makes the spend efficient. Free step zero, precise paid steps after.

Frequently Asked Questions

What does an advertiser ID look like on Meta, Google, and LinkedIn?

Meta uses a numeric page ID of roughly 9–16 digits (for example 100690651963843). Google's Ads Transparency Center uses an advertiser ID starting with AR followed by about 20 digits. LinkedIn uses a numeric company ID, the same number that appears in linkedin.com/company/<id> URLs and in urn:li:organization:<id> URNs. The three formats are never interchangeable.

Is finding an advertiser ID free?

Yes, on every route. The manual lookups through the Meta Ad Library, Google's Ads Transparency Center, and LinkedIn's company pages cost nothing. On the AdLibrary API, the advertisers/search resolution endpoint costs 0 credits, so you can resolve unlimited brands before spending anything. Credits only apply when you pull actual ad data.

Can I use a Facebook ad account ID (act_…) to look up a brand's ads?

No. The act_ identifier is a Meta Marketing API ad account ID, used for buying and managing your own ads. Ad transparency surfaces key on the Facebook page ID instead. To research a brand's ads you need the numeric page ID from the Ad Library URL or the Page transparency section, never the ad account ID.

How do I find a LinkedIn company's numeric ID?

The public page shows a vanity slug, so you have to dig one layer down. View the company page source and search for urn:li:organization: — the trailing digits are the company ID. Alternatively, resolve the brand through the AdLibrary API's free advertisers/search endpoint, which returns the numeric LinkedIn ID directly alongside the Meta and Google identifiers.

What if a brand runs ads from multiple pages or accounts?

Treat the brand as a set of IDs, not one ID. Large brands commonly run separate Meta pages per product line and separate verified Google entities per region. Collect every identifier, store them as arrays in a watchlist entry, and query against the full set. The AdLibrary API's saved-advertiser records accept arrays per platform for exactly this reason.

Resolve once, then go research

The unglamorous truth about programmatic ad research is that the sophisticated parts (winner detection, creative teardowns, spend estimation) all sit on top of a lookup table. The lookup table is the advertiser ID per platform. Find the advertiser ID correctly for each platform and keep the three formats separate. Store them once, and everything downstream just works. Skip the step and every result you generate carries a quiet asterisk.

So make it step zero, literally. Run the free resolution call before any paid call. Gate your automation on the confidence score, and let the watchlist remember so you never resolve the same brand twice. If you're ready to make that one-call resolution part of your stack, API access on the Business plan (€329/mo, 1000+ credits, keys created in your dashboard in minutes) is where it lives — no app review, no token expiry, one adl_ key and you're resolving brands before lunch.