Meta today published a case for replacing API polling with webhooks across its advertising infrastructure, documenting five standalone webhook fields and a single ads subscription endpoint that the company says carries more than 88 notifications tied to ad object changes and insights updates. The post, written by Sydney Levitan and John Holstein and filed under the Business Tools and Developer Tools tags on the Meta for Developers blog, arrives six days after the company opened its ads Model Context Protocol server to any developer holding a Meta app.

The framing is unusually plain for a platform announcement. According to Meta, API users currently set up polling to frequently request updates and ensure they hold the most current data, and while that pattern is common, it is inefficient and chips away at rate limits. That last clause is the operative one. Rate limits govern how many calls an application may make against Meta's Graph API within a given window, and an integration that burns its allowance checking for changes that have not occurred has less headroom left for the calls that actually matter.

What the announcement actually contains

Webhooks are not new, and Meta does not claim otherwise. The company dates the mechanism to roughly two decades ago, describing it as a method by which one application provides real-time information to another by pushing data immediately once an event occurs, rather than waiting to be asked. The analogy offered in the post is domestic: instead of walking to a mailbox every hour to check for new mail, the delivery company sends a text the minute something is dropped off.

What is new is narrower than the framing suggests. Of the five standalone webhooks listed, one is marked as new and one as improved. The remaining three were already available. According to Meta, the company increasingly hears about API challenges that can be solved through webhooks, and the post is positioned as a showcase of existing capability alongside the newly available fields.

The five standalone webhooks

The new field is effective_status, which covers ad delivery status changes. According to Meta's documentation table, it fires an alert when an ad is not being delivered due to delivery blocks, policy rejections, or sync delays. For an agency running campaigns across dozens of accounts, that is the difference between discovering a policy rejection during a scheduled morning check and receiving it at the moment the rejection lands.

The improved field is ad_recommendations, which alerts when an ad account receives a new recommendation.

Three fields carry no status marker. in_process_ad_objects signals when an ad exits publishing or processing. with_issues_ad_objects covers ad status where something went wrong during operation or publishing. creative_fatiguealerts when an ad's creative fatigue level is increasing, which according to the documentation indicates a creative refresh may be needed to maintain optimal performance.

That last field connects to a measurement problem the industry has debated for some time. Creative fatigue has been cited as one of several possible causes when Meta campaign performance drops, and the difficulty has been that the platform's automated delivery systems make it hard to separate fatigue from audience saturation, competitive pressure, or algorithmic changes. Advertisers have described needing constant monitoring despite automation, with performance working well on some days and poorly on others. A push notification tied specifically to rising fatigue levels does not resolve that diagnostic ambiguity, but it does put a platform-generated signal where previously there was inference.

Two calls, two tokens

Enabling a standalone webhook requires two API calls using two different access tokens, a design that carries a specific security logic.

The first call hits the subscriptions endpoint on the app ID using an app access token, and specifies the object type as ad_account, a callback URL, the fields to subscribe to, and a verify token. The second call hits the subscribed_apps edge on a specific ad account, using the access token of an Ad Account Admin, which may be either a system user token or a user token.

According to Meta, the initial call activates the webhook for the application and instructs the system to prepare all relevant updates for delivery, but those updates remain undelivered until specific ad accounts are identified and access is verified. The second call unblocks actual delivery for the accounts a developer manages. By providing an Ad Account Admin's access token, a developer authenticates permissions and maintains precise control over specific ad accounts.

The separation matters for agencies and technology providers. An application cannot subscribe itself to accounts it does not administer. Activation and authorisation are decoupled, which means a compromised app token alone does not open a data channel into advertiser accounts.

The subscription endpoint and its filter grammar

The second component is structurally different from the five fields. According to Meta, the ads subscription endpoint provides real-time updates on multiple ad object metrics and insights metrics, and a single setup flow enables over 88 notifications related to ad object changes and insights updates.

Setup begins the same way, with a subscription to the subscriptions field on the ad_account topic using an app access token. What follows is where the endpoint diverges: developers set trigger thresholds and filters for the insights they want.

The example Meta publishes uses a POST call against the v25.0 subscriptions edge on an ad account, carrying a bearer token belonging to an admin of the ad account, a system user, or a user access token. The request body specifies an event_type of OBJECT_CREATED and a filters array containing two conditions: entity_type equals CAMPAIGN, and objective equals OUTCOME_SALES. The result, according to the documentation, notifies the developer whenever a campaign is created with a sales objective in the specified account.

The grammar is worth noting. Each filter is an object with a field, a value, and an operator, and the published example uses EQUAL. That structure implies other operators exist, though the post does not enumerate them, nor does it list what the 88-plus notifications actually are. Subscriptions can then be retrieved individually by subscription ID or listed in full through GET calls against the same edge.

The version string in every published example is v25.0. Meta released Graph API v25.0 and Marketing API v25.0 on February 18, 2026, a release that carried breaking changes prohibiting creation of legacy Advantage Shopping Campaign and Advantage App Campaign structures across all API versions.

Why rate limits are the real subject

Strip away the mailbox analogy and the announcement is about API economics.

An integration that polls is making calls whose value is unknown before they return. Most return nothing new. A reporting dashboard checking ad delivery status every fifteen minutes across five hundred ads issues the same volume of calls whether every ad is running normally or half of them have been rejected. The cost is fixed; the information yield is not.

Meta has been tightening what the Marketing API returns, which raises the cost of every wasted call. Restrictions announced in October 2025 eliminated two view-through attribution windows and imposed historical data retention limitsacross eight Ads Insights API endpoints, effective January 12, 2026, applying to all API versions simultaneously. Applications requesting deprecated attribution windows receive empty data sets rather than error messages. Marketing mix modelling breakdowns were restricted to asynchronous jobs exclusively.

Set against that, the appeal of an event-driven model is arithmetic rather than architectural preference. Push delivery consumes no rate limit allowance on the receiving side. According to Meta, the automatic push means a developer still receives updated information without a hit to the rate limit.

One thing the announcement does not do is deprecate anything. No date is given for polling restrictions, no endpoint is scheduled for removal, and no migration deadline appears anywhere in the post. This is an availability announcement, not an enforcement action. Under Future plans, Meta states only that it will continue to build out its API webhooks portfolio based on customer needs and feedback.

Where this sits in Meta's developer sequence

The timing places the post inside a dense run of platform releases.

Six days earlier, on July 16, 2026, Meta opened its ads MCP server to any developer holding a Meta app, removing the custom integration code the platform had previously required to connect AI agents to advertising accounts. Sydney Levitan, co-author of the webhooks post, was credited on that announcement as well.

The two systems solve adjacent problems from opposite directions. The ads MCP server handles the request path, letting an agent ask questions and issue instructions against a live account. Webhooks handle the notification path, telling an application when something has changed without being asked. An agent connected through MCP still has to be prompted before it acts; a webhook subscription fires on its own.

That pairing is visible in Meta's own developer tooling. When the company launched its Developer Tools MCP server at the end of June 2026, it kept nearly the entire ten-tool surface read-only, with webhook subscription management as the sole write capability. Three of those ten tools are webhook-specific: one lists available topics and existing subscriptions, one creates, updates, and deletes subscriptions, and one sends a sample payload to a configured endpoint so a developer can confirm the receiving system behaves correctly. Meta chose webhooks as the single thing an AI agent may modify on the developer side of its platform.

The write-access question runs through the whole sequence. Meta opened its ad system to Claude and ChatGPT on April 29, 2026, pairing an ads MCP server with a companion command-line tool that gave external agents write access to campaign creation, ad set management, and catalog operations. The Ads CLI shipped the same day with a notable default: every resource created through it is set to PAUSED status, requiring an explicit status update before delivery begins.

What the announcement leaves open

Several operational details are absent from the published post.

The figure of over 88 notifications is given without a list. Developers cannot determine from the announcement which ad object changes and which insights metrics are covered, or where the boundary between the two categories falls.

Delivery guarantees are not addressed. The post does not describe retry behaviour when a callback endpoint is unavailable, whether events are delivered at least once or exactly once, or whether ordering is preserved. For an application acting automatically on a delivery-status alert, those properties determine whether the alert can be trusted as a trigger.

Latency is characterised only as real time. No figure is given for the interval between an event occurring inside Meta's systems and the corresponding POST arriving at a subscriber endpoint.

Nor does the post state whether the five standalone fields and the ads subscription endpoint overlap. If effective_status changes are among the 88-plus notifications on the unified endpoint, a developer subscribing to both would receive duplicates. The documentation as published does not resolve the question.

The creative_fatigue field carries a further ambiguity. Fatigue level is described as increasing, but no scale, threshold, or measurement window is defined. What constitutes an increase, and against what baseline, is left to the linked developer documentation rather than stated in the announcement.

Why this matters for the marketing community

For agencies and in-house teams running custom Meta Ads integrations, the practical consequence sits in the gap between when something breaks and when someone notices.

A polling architecture defines that gap by its interval. An ad rejected for policy reasons at 02:00 on a system that checks hourly is discovered at 03:00 at the earliest, and on a system that checks every six hours, potentially not until the working day begins. Budget continues to be allocated against ad sets whose ads are not delivering. The effective_status webhook collapses that interval to the event itself.

The rate limit argument compounds for larger operations. A platform managing thousands of merchant advertisers faces a polling volume that scales linearly with account count while the underlying rate limit does not. Meta has been formalising how such platforms structure their account relationships: rules taking effect from February 2027 require separate ad accounts for end advertisers, with a technical alternative permitting a vendor_id or brand field in Product Catalog, Pixel, or Conversions API data for platforms operating at volume. More accounts under management means more objects to monitor, and the arithmetic of polling deteriorates accordingly.

There is a second-order effect worth noting. Push notification is the delivery model an autonomous system needs. An AI agent that must poll is an agent that must be scheduled and must consume rate limit allowance to discover that nothing has changed. An agent subscribed to a webhook is dormant until an event arrives. Meta has spent 2026 building agent access paths into its advertising platform, and event-driven notification is the layer that lets those agents respond rather than merely be asked.

The announcement stops short of the harder commitments. There is no service level, no deprecation date for polling, no enumeration of the 88-plus notifications, and no delivery guarantee. What Meta has published is an inventory of available capability with one new field and one improved field inside it. For teams already maintaining Marketing API integrations, that inventory is actionable. For teams weighing whether an event-driven architecture is worth building, the post supplies the argument without supplying the operational specifications that would let the decision be made on evidence.

Timeline

Summary

Who: Meta, through its Meta for Developers division, in a blog post authored by Sydney Levitan and John Holstein. The audience is developers, agencies, and marketing technology teams maintaining custom integrations against the Meta Marketing API.

What: A documented case for replacing API polling with webhooks, covering five standalone webhook fields on the ad_account object and one unified ads subscription endpoint that Meta says carries more than 88 notifications tied to ad object changes and insights updates. The effective_status field, which alerts on delivery blocks, policy rejections, and sync delays, is marked new; ad_recommendations is marked improved. Enabling a standalone webhook requires two API calls using two different access tokens, an app access token and an Ad Account Admin token.

When: Today, July 22, 2026, filed under the 2026, Business Tools, and Developer Tools tags. Every code example in the announcement targets Graph API v25.0, released February 18, 2026.

Where: Through the Meta Graph API, using the subscriptions endpoint on an app ID and the subscribed_apps and subscriptions edges on individual ad accounts, with delivery to a developer-supplied HTTPS callback URL.

Why: Meta frames polling as inefficient and as consuming rate limit allowance that could be spent on calls returning new information. Push delivery removes that cost on the receiving side. No deprecation date, migration deadline, or endpoint removal accompanies the announcement, and Meta states only that it will continue expanding its webhooks portfolio based on customer needs and feedback.