MCC Connected but Campaigns Won't Load? How to Fix It

You connect a reporting, automation, or fraud-protection tool to your Google Ads manager account. The connection looks successful — no error, no red warning. You enter your MCC's Customer ID, click something like "load campaigns," and nothing comes back. Maybe the tool shows your MCC ID reflected back as the only "available account," with no child accounts listed underneath it, even though you can see a dozen client accounts clearly linked when you check Google Ads directly.

This is a specific, common, and fixable problem — not a sign your MCC is set up wrong. It comes from how the Google Ads API is structured, and most third-party tools simply weren't built to handle it. Here's exactly what's happening, what to check on your end, and what a properly-built tool's fix actually looks like.

What's actually happening, in plain terms

A Google Ads manager account (MCC) doesn't own campaigns itself. Campaigns live on the child accounts underneath it. When a tool asks Google's API for campaigns on your MCC's ID directly, Google correctly returns nothing — not an error, just an empty result — because the ID it was given genuinely has no campaigns attached to it.

To see a child account's data through an MCC, a request needs two separate pieces of information: which account's data you want, and which manager you're acting as when you ask. That second piece is sent as a header called login-customer-id, set to your MCC's own ID. Without it, Google has no way to know you're asking on behalf of the manager relationship — even though your login genuinely has access, the request itself doesn't say so.

Finding out which child accounts exist under an MCC in the first place is a separate step too, and it requires a different kind of request specifically built for that purpose — one that asks Google to list everything nested under a given manager ID, again with that same login-customer-id header attached. A tool that only knows how to check "which accounts does this login have direct access to" (a simpler, more common request) will correctly find your MCC itself, and stop there — it never asks the follow-up question of what's underneath it.

Put together: a tool built only for connecting to a single, standalone account works perfectly for exactly that case, and returns nothing useful the moment you point it at a manager account instead. That's not a coincidence or a bug in your account — it's a feature the tool's developer never built, because it's genuinely easy to overlook if you're not specifically testing against an MCC during development.

It helps to picture the two requests as genuinely separate questions being asked of Google. "Which accounts does this login have access to" is one question, and it correctly returns your MCC's own ID when you've authenticated with a login that manages that MCC. "What child accounts exist underneath this specific manager, and can I see their campaign data" is a second, entirely different question — one that has to be asked explicitly, with the manager's ID attached as context, or Google has no reason to walk down into the hierarchy at all.

What to check yourself, in order

First, confirm what you're actually looking at. Log into Google Ads directly with the same account the tool is using to connect. Check the account switcher — if the ID you entered sits at the top with child accounts nested beneath it, it's genuinely a manager account. If it's a standalone account with no children listed, the fix is different: you've simply pointed the tool at the wrong ID, and entering your actual MCC ID (if you have one) or a direct child account ID instead should resolve it immediately.

Second, confirm the login has real access at the manager level, not just to one child account. A Google login that only has direct access to a single client account under the MCC will only ever see that one account, no matter how the tool queries things — Google is correctly reporting the actual limits of what that specific login can see. Check Admin, then Access and security, on the MCC itself to confirm the account you authorized with shows up with Admin or Standard access at that level.

Third, check whether the specific child account you're trying to reach shows as Active, not Pending. Linking a client account to an MCC is a two-sided process — sending the link request isn't enough on its own; the client has to accept it from their side. An unaccepted pending link can look connected in some interfaces while carrying no actual usable access yet, which produces exactly the same "connected but empty" symptom as the API header issue, for a completely different reason.

If all three of those check out — genuine manager account, real access at the manager level, child account status showing Active — the cause is very likely the backend integration issue described above, and it's worth reporting to the tool's support directly rather than continuing to troubleshoot from the Google Ads side, since there's nothing further to fix in your account settings at that point.

It's worth doing these three checks in this specific order, since each one rules out a progressively narrower explanation — starting with whether you're even looking at a manager account at all (the broadest, easiest thing to get wrong) before moving to access permissions, and only then to link status, which is the most specific and least common of the three.

Why this specific gap is so common

It's worth understanding why so many tools trip on exactly this, rather than assuming it reflects carelessness on any particular vendor's part. Most tools are built and tested first against a single, standalone Google Ads account, since that's the simpler, more common case and the one a developer's own test account usually looks like. MCC support often gets added afterward, as a secondary feature, once real customers start asking to connect agency or multi-account setups.

The trouble is that MCC support done properly isn't just "accept a different kind of ID" — it requires an entirely separate code path: a distinct API call to discover child accounts, a header that has to be threaded through every subsequent request touching that child account, and handling for the case where a login has access to some but not all of an MCC's children. It's genuinely more work than it looks like from the outside, and it's easy for a team to ship something that handles the common cases (direct account access) well while leaving the manager-account path only partially built, especially if their own internal testing never included a large multi-client MCC to catch it.

None of this is a reason to avoid MCC-connected tools generally, covered again in the FAQ below — it's simply useful context for why this specific, oddly common failure mode exists, rather than treating it as a mysterious or unusual glitch unique to your setup.

Two patterns that look similar but aren't

Pattern one: the tool shows your MCC ID as the only available account, with no children listed at all. This usually means the tool never ran the child-account discovery step described above — it checked what the login has direct access to, found your MCC, and stopped there without ever asking what's nested underneath it.

Pattern two: the tool shows a list of child accounts correctly, but selecting one and trying to load its campaigns returns nothing. This usually means discovery is working, but the actual campaign-data request for the child account isn't attaching the login-customer-id header — the tool knows the child account exists, it just isn't asking Google's API for data the right way once it gets there.

The distinction matters mainly for reporting the issue accurately if you're raising it with a tool's support team — "I can't see any accounts under my MCC" and "I can see the accounts but campaigns won't load for any of them" point at two different parts of the same underlying gap, and giving the specific symptom helps whoever's fixing it find the actual broken piece faster.

A third, less common variant is worth a brief mention: a tool that shows child accounts and successfully loads campaigns for most of them, but fails specifically on accounts nested under a sub-manager (covered in more detail further down). This tends to look like an inconsistent, account-by-account bug rather than a clean pattern, and it's the hierarchy-depth issue rather than either of the two main patterns above.

What a properly-built fix actually looks like

If you're evaluating whether a tool has genuinely fixed this, or vetting a new tool before connecting it to an MCC in the first place, here's what correct behavior looks like: entering a manager account ID should return a clear list of the child accounts underneath it, not an empty result and not just the manager ID echoed back. Selecting a specific child account and requesting its campaigns should return real campaign data, with the tool transparently handling the login-customer-id requirement in the background — you shouldn't need to configure that header yourself; a properly built tool handles it automatically once it knows which manager a given child account sits under.

It's a reasonable, specific question to ask directly during evaluation: "does this support manager account discovery and the login-customer-id header for child accounts?" A vendor who understands the question and answers confidently and specifically has almost certainly built this correctly. A vague answer, or one that requires you to explain what login-customer-id even is, is a real signal worth taking seriously before you invest time connecting an MCC-managed account and hitting exactly the empty-result symptom this piece is about.

It's also reasonable to ask what happens when a login has access to some, but not all, of an MCC's child accounts — a genuinely common real-world situation, since not every user on a team needs visibility into every client. A properly built tool should surface exactly the subset that login can actually see, not error out entirely or incorrectly claim there are no accessible children just because the full list isn't available to that particular login.

If you're several levels deep in a sub-MCC structure

Agencies managing a large enough client roster sometimes organize accounts into a manager account with sub-manager accounts underneath it, rather than one flat level of clients directly under a single top-level MCC. This adds another layer the same discovery process has to walk through correctly — a tool has to be able to follow the hierarchy down through an intermediate manager level, not just one level from a top MCC straight to its direct children.

If your setup includes this kind of nested structure and a tool is only picking up accounts at the first level, stopping before it reaches accounts nested under a sub-manager, that's a variation of the same underlying gap — the discovery step needs to recurse through the full hierarchy, not just check one level down. Worth mentioning this specifically if you're reporting the issue to a tool's support team, since it's a detail that changes what needs fixing on their end.

This is a less common configuration than a flat single-level MCC, so it's worth checking whether your own setup actually includes nested sub-managers before assuming this section applies — most small-to-mid-size agencies run a flat structure and can skip straight to the checks above without this added layer of complexity.

When it's not a bug at all

Not every empty-result situation traces back to the API integration gap — a couple of genuinely different, unrelated causes produce a similar-looking symptom and are worth ruling out too.

A child account with zero active campaigns, or all campaigns currently paused, will correctly show no campaign data even with a perfectly working integration — there's simply nothing to display. Check the account directly in Google Ads to confirm campaigns actually exist and are enabled before assuming the connection itself is broken.

A recently linked account can occasionally take a short period to fully propagate through Google's systems after the link is accepted, though this is uncommon and usually resolves within a few minutes to an hour on its own — worth a brief wait and a retry before escalating, particularly if the link was accepted very recently.

Why does this work fine for my individual, standalone accounts but not through my MCC?

Because a standalone account query doesn't need the login-customer-id header or the manager-level discovery step at all — you're asking directly for an account's own data, with no manager relationship involved. This is exactly why the symptom is so specific: the same tool can work perfectly for one connection type and return nothing for the other, since they're genuinely different kinds of requests under the hood, not the same request pointed at a different ID.

Is there anything I can change in Google Ads itself to fix this?

If the three checks above (genuine manager account, real manager-level access, Active link status) all come back clean, no — there's no setting inside Google Ads that resolves a tool's own missing API implementation. The fix has to happen on the tool's side, in how it constructs its requests to Google's API.

Does this affect every third-party tool, or just some?

Just tools that weren't specifically built and tested against manager accounts. Plenty of established, well-built reporting and management tools handle this correctly, since MCC support is a common, well-understood requirement for anything targeting agencies or multi-account advertisers. It's more often an issue with newer tools, or ones originally built for single-account use that added MCC support later without fully testing the manager-account discovery path specifically.

How to report this clearly to a tool's support team

A specific, well-described report gets fixed faster than a vague one. Include: your manager account ID (not a child account ID), whether the tool shows any child accounts at all or shows none (pattern one versus pattern two from above), and confirmation that you've already checked the three items in the "what to check yourself" section — this immediately tells whoever's investigating that the issue isn't a permissions or link-status problem on your end, and points them straight at the actual integration code.

If the support team's first response is to ask you to re-check your own account permissions or link status, that's a reasonable first question on their part, not a brush-off — but if you've already confirmed those and communicated that clearly, a competent team should move past it quickly to looking at their own API calls rather than repeating the same basic troubleshooting steps back to you.

A screenshot of exactly what the tool shows when you attempt the connection — the empty account list, or the specific error if one appears — adds real value to a report too, since it removes any ambiguity about which of the two patterns you're actually looking at.

I fixed the three things listed above and it's still not working — what now?

Disconnect and reconnect the integration entirely first — some tools cache the results of an early, failed connection attempt and don't automatically retry the discovery step just because the underlying issue was fixed. If a fresh reconnection still doesn't surface your child accounts, the remaining explanation is almost certainly the tool's own API implementation, and the most productive next step is contacting their support with the specific symptom pattern (from the two-patterns section above) and your manager account ID, rather than continuing to adjust settings on the Google Ads side.

Should I just avoid connecting third-party tools to my MCC entirely?

That's a wider trade-off than this specific issue justifies on its own. Plenty of tools handle MCC connections correctly, and the alternative — manually managing reporting, automation, or protection separately for each child account — becomes genuinely impractical once you're past a handful of accounts. The more proportionate response is testing a new tool's MCC support specifically during evaluation (the questions covered in the section above), rather than avoiding MCC-connected tools as a category.

If protecting against wasted spend or invalid traffic across every client account under your MCC is the specific goal, this evaluation step matters more than usual — a protection tool that silently fails to see most of your child accounts isn't just inconvenient, it means those accounts are effectively unmonitored while the dashboard may still look like everything's connected and working.

The short version

"Connected but empty" under an MCC almost always traces back to one of a small number of specific, checkable causes: a tool that never asks Google's API which child accounts exist under a manager, a tool that finds the children but doesn't attach the required header when requesting their data, a login that lacks real manager-level access, or a child-account link that was sent but never accepted. Work through the checks in order, and if everything on the Google Ads side genuinely checks out, the fix has to happen in the tool itself — which is worth raising directly and specifically with whoever built it, rather than assuming the problem is something wrong with your account.

This is a narrow, specific technical gap, not a reflection of anything wrong with how you've set up your Google Ads account — the fix belongs with whoever built the tool, and a clear, specific report is usually all it takes to get it addressed.