On 27 October Meta changes every Graph API version at once, including the one you pinned

The one change a pinned version does not shield you from

Most of what Meta announces in a Graph API changelog reaches an integration only when someone edits the version string in its URL. A script on v22.0 today behaves the way v22.0 behaved when it was written, and the changelog entries for v23, v24, v25 and v26 are somebody else's problem until 20 May 2027, when v22.0 is switched off. That is the arrangement, and it is why the version is in the URL at all.

The entry Meta published with v26.0 on 29 July carries a second date that breaks the arrangement:

Applies to v26.0+ beginning July 29, 2026. Applies to all remaining supported Graph API versions beginning October 27, 2026.

Graph API no longer supports these legacy protocol behaviors:

• The pretty query parameter is ignored, and JSON responses use compact formatting.

• The debug query parameter is ignored, and no debug response envelope is added. The debug_token endpoint is unaffected.

• Requests that include date_format return an error. Use the default date format and convert values in client code if needed.

• Root requests using GET /?ids=... return an error. Use per-object requests or supported batching.

• The If-None-Match query parameter is ignored. Legacy ETag response headers and 304 Not Modified behavior are removed, and requests return full responses.

• Graph API changelog, version 26.0, "Legacy Graph API protocol features deprecated", Meta for Developers, read 12 September 2026

"All remaining supported Graph API versions" on 27 October means v21.0 through v26.0 - v20.0 was removed on 24 September - and it also means calls that carry no version at all, which Meta's versioning guide says use "the version set in the app dashboard". There is no version string that lands outside that set. Eight days after this is published, the five behaviours above are gone everywhere.

Two of the five are loud and three are quiet, and it is worth being exact about which is which, because the loud ones are the easy ones.

date_format and GET /?ids= turn into what Meta's blog post for the release calls "a parameter error". A request that has carried date_format=U for years to get Unix timestamps fails on 27 October, and so does a request that fetched five pages or fifty posts in one round trip with ?ids=. Both fail on every run, with a response body we could not find posted anywhere, because on the versions most integrations are pinned to it has not happened yet.

pretty, debug and If-None-Match do not fail. pretty=1 gets compact JSON back, which no parser cares about. debug=all gets a response with no __debug__ envelope, so anything reading warnings out of that key reads nothing. And a client that has been sending If-None-Match with the ETag it saved last time - the cheap way to poll for changes - gets 200 and a full body on every poll instead of 304 on most of them. The request count is unchanged; the bytes and the parse time are not, and neither shows up as an error anywhere.

Meta's suggested replacements for ?ids= are per-object requests or batching: a POST with up to 50 requests in a batch parameter, one object per entry. The batching page notes that "each call within the batch is counted separately for the purposes of calculating API call limits" - which is no worse than before, since Meta's rate-limiting guide already counted each ID in a ?ids= request as its own call. What changes is the number of requests your code has to assemble and the shape of the response it has to read.

Forty-seven endpoints and no replacement

The same v26 changelog carries a second all-versions entry with the same date:

Checkout directly on Facebook and Instagram for Shops has been sunset. Because the underlying commerce-order infrastructure is being retired, the Commerce Order Management API is deprecated. Calls on v26.0 and later are blocked beginning July 29, 2026. The affected surfaces are removed from all remaining versions on October 27, 2026. No replacement API is available.

The complete deprecation covers 47 endpoints.

• same page, "Commerce Order Management API deprecation"

The list that follows, which Meta labels "affected and representative", is 47 lines long, and every one is a GET: orders, items, payments, refunds, shipments, cancellations, returns, tax settings, fulfillment locations. This is the API a shop used to pull orders placed through Facebook or Instagram checkout into its own order system. A sync built on GET /{page-id}/commerce_orders has already stopped for anyone who moved to v26, and on 27 October it stops for the rest. None of the three automation platforms has a module for it, so anything doing this is a script, and the script's author is the one who will notice.

The Marketing API entries on the same page follow the same pattern with the same date, for a narrower audience: three fields disappear from Delivery Estimate responses "because the service powering these values has been deprecated", the story value in messenger_positions is "silently removed", and poll components in ads are no longer accepted. The Delivery Estimate one is the quiet kind - Meta says the fields "are removed", not that the request fails.

Where the automation platforms stand

n8n's Facebook Graph API node is a thin wrapper and passes on exactly what you type. Its "Query Parameters" and "Query Parameters JSON" fields go straight into the request, so a node with date_format in them fails on 27 October regardless of what the version dropdown says. (A root ?ids= request is harder to make from this node, since its Node field is mandatory and n8n will not run a workflow with it empty; it would have to be typed into that field itself.) That dropdown, in the node's source on 12 September, runs from v3.0 to v25.0, and v26.0 is not in it - v24 and v25 were added in May. Its first option, "Default", sends no version segment at all, which by Meta's guide means the version chosen in your app's dashboard, so "Default" is not a way out either. The two Facebook trigger nodes carry fixed versions in their source - v23.0 for the Facebook Trigger, v21.0 for Facebook Lead Ads - and use none of the five behaviours, so 27 October does not touch them.

Make's Facebook Pages app offers a fixed set of modules for posts, videos, photos, comments and the page itself, with no user-supplied query parameters, so the only way to send ?ids= or date_format from Make is a generic HTTP module with the URL typed by hand. Which Graph API version the app itself uses is not published.

Zapier's Facebook Pages app is the same shape, with one action of interest covered in the next section.

Neither n8n's forum nor Make's had a thread about date_format, ?ids= or v26 on 12 September, and n8n's issue tracker had none either. That is consistent with a change that has only happened so far on a version nobody was forced onto.

The June precedent, and three documents that disagree

Meta has already done this once in 2026 - the same v25 changelog switched off the metadata=1 parameter everywhere on 19 May. The larger earlier one is Page Insights, and it is a useful precedent for how much to trust the dates.

The v25.0 changelog, published 18 February, lists 43 lines of Page, Post, Video and Stories metrics, 41 distinct names - page_impressions_unique, page_posts_impressions, post_video_views_unique, total_video_impressions and the rest - under this heading:

Will apply to all versions when v26.0 is released.

When v26.0 is released later this year, page reach, page post reach, video impressions, and story impressions metrics listed below will be deprecated. Once deprecated, these metrics will return an error if requested using any API version.

• Graph API changelog, version 25.0, "Insights", Meta for Developers, read 12 September 2026

v26.0 was released on 29 July. The metrics were removed on 15 June. Meta's blog post for v25 had said "June 2026 for all API versions"; a Meta reference page titled "Deprecated Facebook Page Insights Metrics", updated 2 March, says "By June 15, 2025 [sic], the following Facebook Page Insights metrics were deprecated for all API versions"; two analytics vendors that resell the data recorded the switch in their documentation on 15 and 17 June and a third relayed the 15 June date, one of them noting that "Meta moved up the originally communicated timeline from June 30 to June 15"; and a pull request in one open-source connector's repository on 14 August describes what the error looks like from a client's side - "Graph API rejects the entire insights request when any single requested metric is invalid: (#100) The value must be a valid insights metric" - and adds that "the old metrics return a 400, not old data". The v26.0 changelog, the document that should record the event, does not mention Insights at all. And the v26.0 reference page for Page Insights marks seven of the 41 "Deprecated above Graph API v25" - plus an eighth from the November wave - which is neither the right count nor, if the vendors are right, the right versions.

So a reach report that has been empty since mid-June is not a 27 October problem, and its fix is a different metric - Meta names page_total_media_view_unique as the replacement for page_impressions_unique, names page_media_view for the paid-and-organic split, and says of any metric without a named alternative that "data that the metric would normally return will no longer be available". One vendor's assessment is that the paid and organic unique reach figures have "no like-for-like replacement at the unique-user level". Zapier's "Page Post Insights" action takes its metric names as a free-text field, with a help link to the reference for Graph API v3.2; any of the names above typed in there in 2024 has been returning the error since June, and takes the rest of the request down with it.

What the precedent says about October is narrower. On the all-versions change this year most like this one, Meta's changelog gave a trigger that turned out not to be the trigger, a reference page gave a year that cannot be right, and the blog post was the document that matched what the servers did. For 27 October there are two documents, the changelog and the blog, and they agree. That is better than June. It is still a date to test against, not to rely on.

The strings to search for

There are only a handful of things to look for, and all of them are strings. If the integration is a workflow, the search is in the node or module settings; if it is code, it is a text search across the repository.

1. Search for date_format. Any hit is a request that fails on 27 October on every version. The fix is to drop the parameter and convert the ISO-8601 string Meta returns by default; on n8n that is one expression, in code it is one line.
2. Search for ?ids= and for ids as a query parameter with no object in the path. Each hit is a root request. Replace it with a batch (POST with a batch array of GET entries, one object per entry), and rewrite the code that reads the response, because a batch returns a list of responses rather than a map keyed by ID.
3. Search for If-None-Match and for any code that saves an ETag header. These do not fail; they stop saving anything. If a poller was sized on the assumption that most responses are 304, size it again on full bodies. If nothing reads the header, delete the code so the next person does not size on it either.
4. Search for debug= and __debug__. Logging that reads Meta's warnings out of the envelope goes silent. Nothing breaks; you lose a signal you may have been relying on without knowing it.
5. Search for commerce_orders. If it is there, the sync has been dead since July or dies on 27 October, and Meta says there is no replacement. What to do about Facebook and Instagram checkout orders after that is a business question, not an API one.
6. Search for the metric names in Meta's June list - page_impressions_unique, post_impressions_unique, the page_posts_impressions family, the total_video_impressions family. A hit here has been failing since 15 June, and the request returns the error for every metric in it, not just the dead one.

If the search turns up hits in an integration nobody on your side wrote, removing them is a short piece of work at a known price, whether it lives in n8n, Make or a script: each of the five has exactly one fix, and the fix is the same on every version.

Test on the day, not on the changelog

Meta's own blog post for v26 ends its section on the five behaviours with the advice to "review runtime request logs", which is the right advice, since the request log is the only document in this story that describes what your integration actually sends. The blog post is also, on 12 September, still carrying an editor's note that was never meant to ship - "Developer blog post draft. Target release: Graph API v26.0" - under a heading whose all-versions date is "to be confirmed". The changelog entry for the same item reads "Will apply to all versions approximately 90 days after the v26.0 launch; date to be confirmed". Ninety days after 29 July is 27 October. Meta has not said that it is.

Sources

• Graph API changelog, version 26.0 - Meta for Developers, released 29 July 2026, read 12 September 2026. The "Legacy Graph API protocol features deprecated" entry with its two dates and five behaviours, the Commerce Order Management deprecation with its 47-line endpoint list, the Marketing API entries dated 27 October 2026, the "approximately 90 days" entry for Page fields, and the absence of any Insights entry.
• Introducing Graph API v26.0 and Marketing API v26.0 - Meta for Developers blog, 29 July 2026, read 12 September 2026. "Return a parameter error", "review runtime request logs", and the draft marker left in the published text.
• Graph API changelog - Meta for Developers, read 12 September 2026. The version table: v20.0 available until 24 September 2026, v21.0 until 21 January 2027, v22.0 until 20 May 2027; Marketing API v24.0 until 6 October 2026.
• Versioning - Meta for Developers, read 12 September 2026. Unversioned calls use "the version set in the app dashboard"; calls to a removed version are "defaulted to the next oldest, usable version".
• Batch Requests - Meta for Developers, read 12 September 2026. The 50-request limit and "each call within the batch is counted separately". The Rate Limiting guide, read the same day: "you can make a single API request specifying multiple IDs, but each ID counts as one API call".
• Graph API changelog, version 25.0 - Meta for Developers, released 18 February 2026, read 12 September 2026. The Insights entry, its "when v26.0 is released" trigger, the 43 metric lines and the named replacements.
• Introducing Graph API v25.0 and Marketing API v25.0 - Meta for Developers blog, 18 February 2026, read 12 September 2026. "The following metrics will be deprecated in June 2026 for all API versions."
• Deprecated Facebook Page Insights Metrics - Meta for Developers, page updated 2 March 2026, read 12 September 2026. "By June 15, 2025, the following Facebook Page Insights metrics were deprecated for all API versions", and the earlier 15 November 2025 wave.
• Page Insights reference, v26.0 - Meta for Developers, read 12 September 2026. The "Deprecated above Graph API v25" marker on eight metrics.
• Three analytics vendors' documentation pages on the June Insights change, read 12 September 2026 - "Now live as of June 15, 2026", "Meta moved up the originally communicated timeline from June 30 to June 15", a switch observed 17 June 2026, "no like-for-like replacement at the unique-user level", and "effective from June 15, 2026 ... across all API versions"; given without names
• One open-source Facebook Pages connector's pull request removing the deprecated Insights metrics, opened 14 August 2026 and merged 17 August 2026, read 12 September 2026 through the GitHub API - the (#100) The value must be a valid insights metric error and the observation that one invalid metric fails the entire request; given without the project's name
• FacebookGraphApi.node.ts - n8n source, read 12 September 2026 on master. The version options from v3.0 to v25.0 with "Default" as an empty string (lines 107-223), the URL built without a version segment when it is empty (lines 389-398), and the query parameters passed through unfiltered (lines 424-448). The fixed versions in nodes/Facebook/GenericFunctions.ts (v23.0) and nodes/FacebookLeadAds/GenericFunctions.ts (v21.0), read the same day. v24.0 and v25.0 were added in PR #27112, merged 12 May 2026.
• Facebook Pages - Make app documentation, read 12 September 2026. The module list, with no Insights module and no free-form query parameters. Make's separate Facebook Insights app is the Marketing API's Ads Insights and requires an ad account.
• Facebook Pages integrations on Zapier - read 12 September 2026 from the page's embedded data. The "Page Post Insights" action, its free-text metrics field and its help link to the v3.2 reference.
• community.n8n.io, community.make.com and the n8n GitHub issue tracker - searched 12 September 2026 for date_format, ?ids=, page_impressions_unique, commerce_orders and v26. No thread or issue from 2026 on any of them.