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.
Frequently asked questions
What is changing with Meta's Delivery Estimate API on October 27, 2026?
Meta is removing three response fields from the Delivery Estimate endpoint: daily_outcomes_curve, budget_guardrail, and estimate_dau. The service that powered these values was deprecated, and there is no replacement API. The fields stopped returning on versioned Graph API and Marketing API v26.0 calls on July 29, 2026, and are removed from all remaining supported versions, including unversioned calls, on October 27, 2026. Affected endpoints include GET /{ad-account-id}/delivery_estimate and GET /{adset-id}/delivery_estimate.
Will my integration throw an error when these fields are removed?
No. The Delivery Estimate endpoint is not being removed, so the call still returns a successful response. The three fields simply no longer appear in that response. Code that reads them receives null or undefined and continues running, which is why this tends to surface as blank forecasts, broken budget guardrails, or wrong delivery projections downstream rather than as an obvious API failure.
Does pinning to an older Marketing API version protect me?
No. Both the Delivery Estimate field removal and the Messenger Stories placement change are explicitly scoped to apply to all remaining supported versions, including unversioned calls, on October 27, 2026. Pinning to an older version defers many Meta changes but does not defer these two. The three month window between the v26.0 announcement and the October 27 date is the migration window for everyone.
What is the Messenger Stories silent removal?
In Marketing API v26.0, the story value in messenger_positions is, in Meta's own wording, silently removed from the targeting specification when creating or updating ad sets. No dedicated error is returned, so a write that includes story succeeds while the resulting ad set no longer targets that placement. This also applies to all versions, including unversioned calls, on October 27, 2026. To catch it, read back the effective targeting after a write and compare it to what you sent.