On October 27, Meta's Ad API Stops Returning Three Delivery Estimate Fields. Pinning Your Version Won't Save You.

On October 27, 2026, three fields disappear from Meta's Delivery Estimate API response: daily_outcomes_curve, budget_guardrail, and estimate_dau. If your code reads them to forecast reach, size a budget, or show an advertiser what a campaign might deliver, here is what happens that day. The call to GET /{ad-account-id}/delivery_estimate still returns a 200. The response object is still valid. The three fields are just gone, and there is no replacement API for them. Your code reads null, your forecast logic runs on nothing, and nothing errors to tell you.

Meta announced this in July with the v26.0 release, and the fields already stopped returning on versioned v26.0 calls on July 29. But the date that catches people is October 27, because that is when the change applies to all remaining supported versions, including unversioned calls. If your integration is pinned to an older Marketing API version and you assumed that bought you time, it did not. Pinning defers a lot of Meta changes. It does not defer this one.

The quiet failure most teams will miss

Ad tech is full of code that reads delivery estimates. Budget pacing tools, campaign planners, advertiser dashboards, automated bidding systems, agency reporting layers. A large amount of that code reads estimate_dau to show projected daily reach, or budget_guardrail to warn when a budget is out of a sane range, or daily_outcomes_curve to plot how outcomes scale with spend. None of that code is going to throw an exception on October 27. The Delivery Estimate endpoint is not being removed. The request still succeeds. The three fields simply stop appearing in a response that otherwise looks exactly the same as it did the day before.

So the failure lands downstream, quietly. A planning tool shows a projected reach of zero or blank, and an account manager makes a decision on it. A guardrail that used to flag a misconfigured budget silently stops flagging, because the value it checks is now null, and a campaign ships with a budget nobody sanity checked. An outcomes curve renders as a flat line, and someone reads that as "this campaign will not deliver" when the truth is "the API stopped sending the data." Every one of these is a 200. Every one of these passes a smoke test that only checks whether the call succeeded.

Meta is doing the other one out loud, in writing: silently

The Delivery Estimate removal is the headline, but the same v26.0 release has a second change that is worth reading carefully, because Meta describes it with a word API providers almost never use about themselves.

The story value in messenger_positions is being deprecated. Here is how Meta's own announcement describes the behavior: the value will be "silently removed from the targeting specification." No dedicated error is returned. If your code sends story as a Messenger placement when creating or updating an ad set, the value is stripped, the ad set is created or updated without it, and you get a success response. Your targeting is now different from the targeting you specified, and the API did not tell you.

This also lands fully on October 27, across all Marketing API versions including unversioned calls. It is the purest form of the problem: not a field you read going missing, but a value you wrote being dropped, with the write still reported as successful. The only way to know your ad set targets what you intended is to read back the effective targeting and compare it to what you sent, because the success of the write tells you nothing.

Why "we pinned the version" is not protection here

Version pinning is the standard defense against provider breaking changes, and for a lot of Meta changes it works: the old behavior stays on the old version while you migrate on your own schedule. That is exactly why these two changes are worth singling out. Both of them explicitly apply to all remaining supported versions, including unversioned calls, on October 27. Pinning to an older Marketing API version does not keep the Delivery Estimate fields coming, and it does not keep story from being stripped. The migration window is the pin, and it closes for everyone on the same day.

This is the trap inside version pinning in general. A pinned version feels like a frozen contract, but the provider decides how long the freeze lasts, and some changes are explicitly scoped to hit every version at once. The pin tells you nothing about which of a provider's changes honor it and which do not. You have to read each announcement to know, and "we are pinned, we are fine" is an assumption that is true right up until the one change that was scoped to every version.

This is contract drift, documented a quarter in advance

Strip away the Meta specifics and this is the same failure behind every silent integration break. The live API stops matching the contract your code was written against, while still returning a valid response. Meta did this the responsible way: a named release, a changelog, a three month runway between the v26.0 announcement and the all-version date. It is still contract drift, because the Delivery Estimate response your code parses on October 28 contains less than the one it parsed on October 26, and the 200 says nothing about the difference.

This is API contract drift, and a documented changelog does not protect you from it. The announcement tells you three fields are going away. It does not tell you which of your pacing jobs, planning tools, or reporting pipelines read estimate_dau, or which ad set creation calls send story. Finding those is a different task from reading the announcement, and it is the task that decides whether October 27 is a non event or a week of debugging why the forecasts went blank.

Contract testing helps at build time, but it validates your code against your assumptions about the response, and "the Delivery Estimate always returns these three fields" is exactly the assumption that stops being true. A test built on a mock delivery estimate with those fields populated keeps passing, because the mock encodes the old contract. The gap between "my fixture has these fields" and "the live API still returns them" is the job of runtime monitoring that checks real responses instead of fixtures.

What to actually do before October 27

Whether or not you have moved to v26.0, the defense is the same.

Search your codebase for every read of daily_outcomes_curve, budget_guardrail, and estimate_dau, including indirect reads through the Meta Business SDK and any wrapper that parses delivery estimates, and decide what each one does when the field is gone, since there is no replacement to migrate to. Search equally for every place you send story in messenger_positions, and read back effective targeting after writes so a silently stripped value fails loudly in your own system. Validate the responses you depend on against a schema at the boundary, so a missing field surfaces as an error in your pipeline instead of a null in a forecast. And do not assume your pinned version protects you here, because both of these changes are scoped to all versions on the same day.

The lesson outlives the fields

Three fields on one endpoint of one ad platform is a narrow change. If you never read delivery estimates, this specific removal is not your problem. But the shape of it is everyone's problem, and Meta is the well documented case: a named release, a public changelog, a quarter of runway. Even with all of that, the change that will actually bite is a field quietly vanishing from a response that still returns 200, or a value you wrote being silently dropped from a request that still succeeds, on a date that applies to every version whether you pinned or not. If this is what a carefully announced deprecation looks like from the outside, assume the providers you depend on that announce less are doing the same thing with no runway at all, and that the only reliable way to know your integrations still match reality is to check the live responses, not the release notes.

This post was originally published on the DriftSignal blog. DriftSignal continuously checks your live APIs against their OpenAPI specs and alerts you the moment they drift, see how it works at driftsignal.io.