A row in your monthly report goes empty. Not wrong, not lower than last month, empty. A field your dashboard pulls has stopped returning anything at all, and nobody can say which week it stopped. The platform’s status page shows no outage. Nothing changed on the account. The metric did not break. It was removed on a date published in advance, in a document your reporting workflow was never built around.
The platforms that expose social data through an API also publish a separate technical record of changes to that API. That record states, in plain dated entries, when a named field will stop being returned and when an endpoint will stop working. It is not the newsroom, it is not the help centre, and it is not the notification panel in the platform’s own business tools. It is written for the engineers who build against the API, not for the person whose report depends on it. This is a different failure from the one where two dashboards show three different numbers for the same account, a problem of definitions rather than dates, covered in when the same account reports three different numbers. This piece is about absence, and about the fact that the absence was dated in public before it happened.
What a developer changelog is, and what it is not
A developer changelog is a rolling, dated technical record of changes to an API, maintained inside the platform’s developer documentation and addressed to the people writing code against it. New entries are appended as changes are announced. Each entry names what is changing, which API versions it affects, and when it takes effect. It is a working document, and it carries no explanation of why the change matters to anyone downstream.
It is worth drawing one line clearly, because the two documents get confused. A transparency report, the subject of an earlier piece on reading a platform transparency report, is periodic and retrospective: it describes enforcement that already happened, in a batch, after the fact. A developer changelog is rolling and forward dated: it describes a change before it takes effect, with the effective date printed in the entry. One tells you what a platform did. The other tells you what a platform is about to do to the data you rely on.
Second line, equally worth drawing: the release notes a software vendor publishes about its own product are a different document entirely. They are not the platform’s record, they do not carry the platform’s sunset dates, and a tool updating its own changelog tells you nothing about when a platform field disappears. Everything below is about the platform’s document.
Two entry types, and what each one predicts
Two structures in these documents matter for anyone whose numbers come out of an API. The first is a field removal, where a named field is deprecated or renamed. The second is a versioned endpoint sunset, where an endpoint or an entire surface stops working as of a stated version and date. Both examples below come from Meta’s Graph API changelog page for version 26.0, read on 30 August 2026.
| Entry type | The entry, as published | Dates given | What it predicts |
|---|---|---|---|
| Field removal | “Rights Manager owner fields migrated to RightsHolderOwner”. The reference_owner, matched_reference_owner, sending_rights_holder and receiving_rights_holder fields are deprecated, with named replacements given for each: reference_owner_rh_owner, matched_reference_owner_rh_owner, sending_rights_holder_owner and receiving_rights_holder_owner. | Applies to v26.0 and later. The deprecated fields remain available on v25.0 and earlier for two years after launch. | A named column stops populating on the newer version while still working on the older one. The replacement is named, so the fix is a mapping job to verify with testing tools before the deadline |
| Versioned endpoint sunset | “Commerce Order Management API deprecation”. The page states that the underlying commerce order infrastructure is being retired, that the deprecation covers 47 endpoints, and that no replacement API is available. | Calls on v26.0 and later are blocked beginning July 29, 2026. The affected surfaces are removed from all remaining Graph API versions on October 27, 2026. | Two distinct deadlines, not one. Anything reading those endpoints breaks on the first date if it has moved to the new version, and on the second date regardless. |
Note what the second entry does that the first does not: it gives a version cutoff and then a hard floor for everyone else. Read only the first date and you conclude you have until October. Read only the second and you miss that the newer version is already blocked. These are two entries on one page of one platform’s document, not a description of how deprecations work in general.
The entry type that ignores your API version entirely
There is a third category, and it defeats the assumption that staying on an older, still supported version buys you time. Meta publishes non-versioned changes on a separate page, and those entries apply to every API version at once.
The 2025 page, read on 30 August 2026, carries an entry dated April 8, 2025, under the heading “oEmbed Response Updates”. It states that the author_name, author_url, thumbnail_url, thumbnail_width and thumbnail_height fields will be removed from the Facebook post, Facebook video and Instagram post oEmbed response, and that the Facebook page post oEmbed endpoint will be deprecated. The entry says these changes apply across all API versions on November 3, 2025.
Across all versions. Nobody had to upgrade anything for those fields to stop returning. An integration pinned to an older version, deliberately, for stability, was not exempt. Any report leaning on an embedded thumbnail or an author name from that response went blank on the same day as everyone else’s. The entry itself sat there dated April 8, 2025 for the effective date of November 3, 2025, a gap of 209 days in that instance. Not an industry average, not a guarantee about the next one. Just the arithmetic on one entry that was public the entire time.
Reading a sunset date on the page
The index page of Meta’s Graph API changelog carries a table headed “Available Graph API Versions” with three columns: Version, Date Introduced, Available Until. One row per version. That third column is the whole exercise.
As read on 30 August 2026, the table shows v20.0 with a Date Introduced of May 21, 2024 and an Available Until of September 24, 2026. That is under four weeks away from the day it was read. Two rows below, v18.0 shows September 12, 2023 and January 26, 2026, a date already in the past, so that version was no longer inside its stated support window at the time of reading. The newest row, v26.0, introduced July 29, 2026, lists its Available Until as TBD.
The instruction is narrow and worth stating plainly: the Available Until date is the one you copy onto a calendar, and it belongs to the specific API version a given integration is pinned to. It is not a property of the account, and it is not a property of the report. Two integrations feeding the same report can sit on different versions with different expiry dates. Find out which version each one uses, then read the row that matches. And check the table yourself rather than trusting the figures above indefinitely, because it is rewritten every time a new version ships.
The same discipline, a different platform’s document
The practice carries across platforms. The format does not. X publishes its own changelog as a reverse chronological list of dated entries, each tagged with a product label such as X API v2.
Read on 30 August 2026, the entry dated Mar 20, 2026 announces the deprecation of POST /2/account_activity/replay/webhooks/{webhook_id}/subscriptions/all, effective March 25, 2026 at 12:00 PM ET, and points to a new consolidated POST /2/webhooks/replay endpoint offering identical functionality.
Two things differ from the Meta examples. The lead time is five days, not months. And the effective moment is stated to the hour, in a named timezone, rather than as a calendar date. If you were watching for a date, you would have missed the morning. That is the actual lesson of a second example: read each platform’s document on its own terms rather than carrying an assumption formed on one platform over to another.
Making this a kept habit, not a rescue mission
The alternative to reading these documents is finding out from an empty cell in a report you already sent. So pick a fixed point on the calendar, one your team actually keeps, and on that day open the developer changelog for every platform a report depends on. Read the entries added since the last check. Copy any date that names a field or an endpoint you use onto the same calendar, with the field name written out.
What makes this practical is boring: bookmark the exact changelog URL for each platform in use, and the non-versioned changes page where one exists, rather than searching for it each time. These pages are not usually pushed to you through a platform’s ordinary notifications. It sits in the same family of work as how the LinkedIn feed ranks posts, according to LinkedIn’s own engineering posts: reading what a platform says about itself, in the platform’s own document, before anyone else interprets it for you.
FAQ
If my team hasn’t upgraded our API version, are we safe from a change in the changelog?
Not automatically. Some changes are versioned and only bite when you move, but others are published as non-versioned changes and apply everywhere at once. The entry dated April 8, 2025 on Meta’s 2025 non-versioned changes page removed author_name, author_url, thumbnail_url, thumbnail_width and thumbnail_height from the Facebook post, Facebook video and Instagram post oEmbed responses, stated as applying across all API versions on November 3, 2025. Staying on an older version offered no protection from it.
Where do I find the changelog for the platforms I report on?
Three documents were read directly for this piece: Meta’s Graph API changelog at developers.facebook.com/docs/graph-api/changelog, which also links its non-versioned changes pages; the Instagram Platform changelog at developers.facebook.com/documentation/instagram-platform/changelog, a separate document that carries its own entries including the same oEmbed change; and X’s changelog at docs.x.com/changelog, reachable from the X API documentation entry point. Other platforms publish their own equivalents, and the way to find them is through the developer documentation rather than the help centre.
Sources
- Meta, Graph API Changelog, including the Available Graph API Versions table. Fetched 30 August 2026.
- Meta, Graph API Changelog, Version 26.0, including the Rights Manager and Commerce Order Management API entries. Fetched 30 August 2026.
- Meta, 2025 Non-versioned Changes for Graph API, entry dated April 8, 2025. Fetched 30 August 2026.
- Meta, Changelog for Instagram Platform. Fetched 30 August 2026.
- X, Changelog, entry dated Mar 20, 2026. Fetched 30 August 2026.
- X, X API documentation entry point. Fetched 30 August 2026.
