Meta Insights API: Breakdowns Only After the Ad Account Is Enabled

Since 6 August 2026 certain Insights API breakdowns require enabling at the level of the individual ad account. Accounts without that enablement can still make the request. It succeeds. The values are simply not in the response.

An error would have been better. An error stops a job, writes a line in a log and produces someone to look at it. A successful response with a hole in it flows onward and gets charted.

Why absence beats an error at causing damage

Reporting pipelines are built to notice failure, and they are good at it. A non-200 status, a malformed payload, a timeout: all of these have handling, alerting and usually a retry. What almost no pipeline checks is whether a valid response contained everything it was supposed to contain.

The result is a report that renders correctly, sums correctly, and describes a smaller world than the real one. Regional spend looks lower for one market. A demographic split shows a skew that reflects which accounts answered rather than who saw the advertising. Nothing anywhere says so.

It is worth separating this from the other well-known way an API can lie. A tracking endpoint that returns 200 to everything is failing on the way in: data was sent and never stored. This is the opposite direction. The data exists, the request succeeded, and the answer is incomplete on the way out. The first loses records; the second produces a wrong number from records that are all still there.

The reconciliation check

There is one property a breakdown cannot escape: its parts have to add up to the whole. That gives a test which needs no knowledge of which accounts are enabled and no maintenance when the rules change again.

for every breakdown request, also request the same
metric for the same period with no breakdown at all

  total_without_breakdown      184,300
  sum(rows of the breakdown)   121,940
  difference                    62,360   -> 33.8 percent

tolerance     a small gap is normal. Rows below a privacy
              threshold are withheld by design, and rounding
              differs between aggregate and detail

              a gap of a third is not that

what to do    fail the load, or load it with a flag on the
              row. Never silently store the smaller number
              as if it were the total

The extra request costs one call per breakdown and it is the only check that keeps working when Meta changes the rules again, because it tests the arithmetic rather than the policy.

Why it varies between accounts

The enablement is attached to the ad account, not to the application or the credentials. A pipeline pulling twelve accounts through one integration will therefore see the same code path succeed fully for ten of them and come back short for two, with no difference in the request.

Which rules out the diagnostic instinct that usually works here. There is nothing wrong with the token, nothing wrong with the permissions on the app, nothing wrong with the API version. The account is the unit, and it has to be handled one by one.

What to put in place

Three things, in order of what they cost. The reconciliation check goes in first, because it is a few lines and it covers cases nobody has thought of yet. A per-account status column comes second, so that a report can say which accounts contributed complete data for a period rather than leaving a reader to assume all of them did.

Third, and least urgent, is the enablement itself for the accounts that need it. It is the real fix, but it takes as long as it takes, and until it lands the first two are what stop a number from being presented as though nothing were missing.