Build1 publisher2 min readPublished
Meta strips three Delivery Estimate fields from every Marketing API version on October 27
Meta stops returning three Delivery Estimate fields on all Marketing API versions, pinned and unversioned, on October 27. The endpoint keeps answering 200, so forecasting code reads nulls and raises no error.
The Engineer · Build desk
What happened
- Meta announced the removal with the v26.0 release in July, and versioned v26.0 calls have omitted the three fields since July 29.
- Integrations read estimate_dau for projected daily reach, budget_guardrail to flag out-of-range budgets, and daily_outcomes_curve to plot outcomes against spend.
- The same release deprecates the story value in messenger_positions, which Meta says will be "silently removed from the targeting specification."
- An ad set created or updated with story as a Messenger placement is written without it, and the API still reports success.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision With no replacement API from Meta, teams that show projected reach or outcome curves have to find estimates elsewhere or retire those features before October 27.
- exposure Budget checks built on budget_guardrail stop flagging bad budgets once the value is null, so campaigns can launch with budgets no one sanity checked.
- constraint Monitoring that only asserts a successful call will stay green through the cutoff, so detection depends on checking field presence and reading back written targeting.
The failure happens after the HTTP layer has already reported success. According to a dev.to post that walks through the v26.0 notes, the delivery estimate response stays a valid object with the three fields missing [2]. Client code that does a plain property read gets null and carries on without an error [2]. A planning tool then shows projected reach as zero or blank [10]. An outcomes curve draws as a flat line, and someone reads it as a campaign that will not deliver [10].
Pinning is the usual defense, and for many Meta changes it holds. The old behavior stays on the old version while a team migrates on its own schedule [13]. For this removal, teams on an older pin got 90 days of grace, the gap between the v26.0 cutoff and October 27 [1]. The post's broader point is one I agree with. A pin does not tell you which of a provider's changes will honor it, and the only way to find out is to read each announcement [14].
Meta's notes use the word "silently" to describe what happens to the story value [6]. The post observes that providers almost never say that about their own APIs [15]. Meta deserves credit for saying it plainly, though an adverb in a changelog is the only warning a client gets, since no dedicated error comes back [6].
The July 29 cutoff is useful for testing [4]. A staging client pinned to v26.0 already receives the response every version will return after October 27 [2]. I would run the forecasting and pacing paths against that client first. The check I'd add asserts that all three field names are present in each delivery estimate response and fails the job when one is missing. For the story value, the post's prescription is the only test that works: read back the effective targeting after each ad set write and compare it with what was sent [11].
What to watch
- Any replacement source Meta publishes for reach or outcome estimates before October 27; the dev.to post says none exists.
- Whether Meta adds a dedicated error for stripped story placements in messenger_positions before the all-version cutoff.
- How many later Marketing API changes Meta scopes to all supported versions and unversioned calls at once.