Meta API Changes: Review Integrations, Ad Defaults and Metrics

A practical breakdown of Meta’s reported API restrictions, ad defaults and video metric changes, with workflow checks for agencies and creators.

Meta API Changes: Review Integrations, Ad Defaults and Metrics cover image

On November 5, 2026, Social Media Today reported that Meta had announced Graph and Marketing API changes affecting third-party tools for Facebook and Instagram. Its report places restrictions on several legacy request and formatting features in effect from November 4.

The reported changes

Social Media Today describes changes across API requests, post disclosures, ad settings and video measurement:

  • Legacy request and formatting restrictions. From November 4, new apps cannot use multi-ID requests; date/time formatting; HTTP method override; field aliases; JSONP callbacks; or asynchronous batch requests. Existing apps cannot introduce new use cases for those features. The report says these restrictions apply across all Graph API versions.
  • AI-generated-content disclosure controls. Apps using Graph API v27.0 will have an option to add or remove an AI-generated-content disclosure on a post. This is a reported API capability rather than confirmation that every connected publishing tool offers the control.
  • Broader device targeting by default. New sales ad sets targeting specific mobile devices or operating systems will expand reach to people on other mobile devices by default. Advertisers can manually change that setting.
  • Product showcase defaults. Meta may automatically enable product showcase on ads created through the API. The report says it can be switched off.
  • Video metric deprecation. Meta is deprecating total video consumption rate. Social Media Today places this after the deprecation of 3-second video viewers and video reach with Graph API v26.0.

The restriction on legacy features is not described as a blanket shutdown. The distinction is between new apps and existing apps introducing new use cases. That scope matters when deciding whether an established workflow needs attention or a proposed integration needs a different approach.

The report does not include Meta’s underlying developer documentation or implementation timelines for every change. It leaves migration obligations for existing use cases and vendor-specific controls unresolved. It also gives no retirement date for total video consumption rate and identifies no replacement metrics. Confirm implementation details against Meta’s current documentation and your vendor’s notices before changing production behavior.

Review the workflow

For multi-brand teams, the practical response is to separate integration questions from publishing decisions and campaign settings. A change to an API request feature is not the same as a change to an ad default or a reporting metric.

Faryen’s positioning starts with that separation: people should be able to see the plan, understand each destination’s status and know what needs attention next. Use that standard to make the review specific rather than treating every connected account as equally affected.

Check integration scope

The immediate integration question is whether your software depends on any of the six restricted features. Agencies and vendors should distinguish established uses from proposed additions before deciding what needs to change.

Ask the provider to identify affected workflows rather than supplying only an API version number. Because the reported restriction spans Graph API versions, version information alone does not answer the dependency question. The useful answer connects a restricted feature to a particular operation in the tool.

For agencies extending an integration, the boundary around new use cases deserves attention before that work becomes part of a client commitment. For creators using an existing publishing tool, the priority is understanding the provider’s assessment of the workflows they actually use.

Keep the discussion concrete: which feature is involved and which operation depends on it? That is more useful than a general assurance that the integration remains connected.

Keep scheduling specific

Use confirmed workflow impact to decide whether a schedule needs attention. The reported restrictions alone are not a reason to describe every scheduled Facebook or Instagram post as affected.

For a multi-brand calendar, keep the account and destination visible when reviewing vendor notices. A broad statement about a platform connection should lead to a more precise question about the publishing operation your team relies on.

This is also a useful moment to revisit how your calendar supports planning. The operational goal is to preserve a clear plan while identifying the particular items that require attention.

Faryen’s product direction supports multiple accounts with destination-specific formats and separate publishing outcomes. Connector availability rolls out by network and needs to be verified before making availability claims. A calendar’s clarity should not depend on assuming that every connection has identical capabilities.

Inspect ad defaults

Teams creating sales ad sets through third-party tools should check the reported device-expansion setting against campaign intent. Device or operating-system targeting should not be treated as sufficient confirmation of the final setting when the report describes expansion as the default.

The practical task is to confirm the setting used by the tool. Where the campaign requires device-specific targeting, verify that the reported manual control is available and reflects that intention.

Product showcase needs a separate review. Check whether it is enabled on API-created ads and whether the tool exposes the option to switch it off. Do not combine this question with device expansion merely because both concern ad creation.

These are campaign-management checks rather than evidence of a change to organic publishing formats. Keeping those workstreams separate helps teams direct questions to the relevant provider and reviewer without widening the issue unnecessarily.

Review disclosure support

The reported disclosure option belongs to Graph API v27.0. Teams that need it should confirm whether their publishing provider supports that capability and how the control appears in the relevant workflow.

Avoid treating an API announcement as proof that a particular publishing interface has changed. The useful operational answer is whether the team can use the control in its chosen tool.

Keep disclosure support distinct from the ad-setting review. One concerns a post disclosure while the others concern campaign defaults. Related coverage on reviewing live creative behavior offers another place to consider how platform changes enter content review without collapsing different controls into a single approval question.

Preserve reporting meaning

Review dashboards and exports that depend on total video consumption rate, 3-second video viewers or video reach. The task is to understand what the reporting workflow now returns and what replacement reporting the provider offers.

Do not turn a missing metric into an apparent performance result. Faryen’s analytics direction is to bring available account and post data together while retaining provider-specific context. Under that approach, unavailable data should be marked unavailable rather than presented as zero.

Apply the same clarity when discussing reports with clients or internal stakeholders. Separate a change in metric availability from a conclusion about content performance. A reporting field’s status and the performance of the underlying content are different questions.

Any replacement reporting should be described on its own terms. Confirm what the provider makes available before presenting it as a continuation of the previous measurement.

Keep ownership visible

The update calls for different answers from different parts of the workflow. Integration questions belong with the provider or technical owner. Ad-setting questions belong with the people responsible for campaign configuration. Reporting questions belong with whoever maintains the dashboard or export.

That separation is an operational recommendation, not a claim that a particular vendor has already changed its product. The goal is to make each unresolved question visible without turning a focused API review into a general publishing pause.

For Faryen, reliability means a workspace where the next required action is understandable. The product’s publishing focus is a useful frame for this update: preserve a clear plan and keep destination-specific behavior explicit.

Today’s review should therefore produce a focused account of affected dependencies, campaign settings and reporting fields. Use vendor-confirmed behavior to guide any changes to the schedule rather than treating the announcement itself as a delivery failure.

Watch the connectors

The next technical milestone to watch is vendor-confirmed implementation of the reported changes, with clear behavior for affected connections, ad controls and reporting.

Sources

  1. Meta adds new capabilities to Graph and Marketing API

Plan your first week in Faryen.

Choose your accounts, schedule the week, and plan what happens after each post goes live.

Create your workspace