DEV Community: FlareCanary

Meta's Graph API v20 expires September 24 — your calls won't fail, they'll quietly start running v21

FlareCanary — Thu, 06 Aug 2026 05:00:43 +0000

There are two ways a vendor can retire an API version. It can reject calls to the dead version, which is loud and annoying and gets fixed the same afternoon. Or it can keep serving those calls out of a newer version, which is polite, invisible, and much worse.

Meta does the second one. From Meta's Graph API versioning docs:

A version will no longer be usable two years after the date that the subsequent version is released.

and, immediately after:

For APIs, once a version is no longer usable, any calls made to it will be defaulted to the next oldest, usable version.

Graph API v20.0 is listed in the changelog as "Available Until September 24, 2026." It is the oldest version still available, and the only one that expires in 2026 — v21.0 runs until January 21, 2027, v22.0 until May 20, 2027.

So on September 24, requests to https://graph.facebook.com/v20.0/... do not start returning 400. They start getting answered by v21 code. The path in your request still reads v20.0. Your dashboards still show 200s. Nothing in the response announces that the switch happened.

The failure modes split into two groups, and only one of them pages you

This is the part worth internalizing before September, because it determines what your incident review will miss.

Everything that changed between v20 and v21 lands on your integration at the same instant, from the same cause. But it doesn't land the same way.

The loud group — you'll find these in your error logs within a day:

POST /{app_id}/page_activities is gone. The Messaging Events API is, per the v21 changelog, "no longer supported in any future releases of Graph API, starting with version 21.0." Calls 404.
Removed Insights metrics return real errors. Request video_views on IG media insights and you get (#100) Starting from version 21+, the following metric is no longer supported: video_views. That's an explicit, greppable error.
Legacy campaign objectives stop being creatable. On v21 you can't create new ad sets or ads with non-ODAX objectives via POST /{ad_account_id}/campaigns, /adsets, or /ads. Creation fails.
Image Expansion moved. It's now part of Standard Enhancements and has to be set via standard_enhancements in creative_features_spec.

Fix these and it feels like you've handled the migration. You have not.

The quiet group is everything that changed shape or value without changing status code. And the six Instagram User Insights time-series metrics removed in v21 — profile_views, website_clicks, email_contacts, get_direction_clicks, text_message_clicks, phone_call_clicks — are the ones to watch, because of how they're usually consumed rather than how the API responds.

The API is loud. Your pipeline is quiet.

Here's the trap, and it's a pipeline problem more than an API problem.

Insights endpoints take a comma-separated metric list. A nightly ETL that pulls twelve metrics per account across four hundred accounts does not, as a rule, fail the whole run when Meta rejects one of them. It does something like this:

for metric in METRICS:
    try:
        rows = fetch_insights(account_id, metric, since, until)
        write(rows)
    except GraphAPIError as e:
        log.warning("skipping %s for %s: %s", metric, account_id, e)
        continue

That code is not wrong. It's the code you write after the third time one bad account killed an eight-hour backfill. But on September 24 it converts an explicit (#100) error into a WARNING line in a log nobody reads, and the dashboard downstream renders a metric that simply stops having data — not a gap with an error banner, just a line that goes flat and a "profile views" tile that reads 0.

Zero is a plausible number. That's the whole problem. Nobody files a ticket about a chart that shows a small number; they file tickets about charts that show an error. Reporting built on this quietly becomes wrong on a Thursday and gets discovered in a quarterly review, if at all.

The same shape applies to any per-field try/except, any IGNORE_MALFORMED-style ingest setting, any connector that treats a partial response as a successful sync. If you run Airbyte, Fivetran, Supermetrics, or a homegrown equivalent against Meta, the question isn't "does the API error" — it's "what does my connector do with a metric-level error inside an otherwise-successful call."

Grep won't find all of it

The obvious audit is to search for v20.0 across your codebase. Do that first, but know that it's the easy half. The version pin also lives in places that don't contain that string:

App-level default version. Calls made without an explicit version in the path resolve to a version configured for your app, not one written in your code. Open the App Dashboard and check what your app is actually set to before you conclude you're not affected.
SDK pins. Meta is explicit that this is a landmine: "For SDKs, a version will always remain available as it is a downloadable package. However, the SDK may rely upon APIs or methods which no longer work, so you should assume an end-of-life SDK is no longer functional." A pinned facebook-business SDK from 2024 is a v20 client wearing a version number that never expires.
Connector configuration, not code. Airbyte/Fivetran/Supermetrics/Zapier/n8n Meta connectors store an API version in saved config. It's in a database row, not your repo.
Mobile SDKs shipped to devices. You don't control the upgrade cadence of an app someone installed in 2024.
Saved webhook subscriptions, which were created against a version at subscription time.

The useful part: you can diff this today

The thing that makes this different from most deprecation posts is that the "after" state already exists. v21 through v25 are live right now. You do not have to wait for September 24 to find out what changes — you can find out this week, with seven weeks left to act.

The check that actually pays:

Capture your real query set. Not a representative sample you wrote by hand — the actual distinct (endpoint, fields, metrics) tuples your integration issues in a week. Pull them from access logs or add a one-line logger.
Replay each one against /v20.0/ and /v21.0/ back to back, same token, same params, same time window.
Diff on shape and value, not status. Both will mostly return 200. What you're looking for is: keys present in one and absent in the other, data arrays that come back shorter, numbers that moved more than rounding explains, and enum values in the v21 response that your code doesn't have a branch for.
Run the same replay through your pipeline, not just curl. The (#100) errors are only interesting in terms of what your ingest code does with them. Point a staging connector at v21 and see what lands in the warehouse.

Step 4 is the one people skip and it's the one that matters, because as established, the API's honesty is not the issue. Your error handling is.

Why this pattern keeps showing up

Fall-forward versioning — serving expired versions out of newer code instead of rejecting them — is now the default posture at Meta, Klaviyo, monday.com, Contentful, and Xero. The vendor logic is sound: nobody's integration goes dark on a Tuesday, and the long tail of unmaintained clients keeps limping along.

The cost is borne somewhere else. It converts an availability failure, which your monitoring is built to catch, into a correctness failure, which it usually isn't. A version string in a URL stops being a contract and becomes a preference the server honors right up until the day it doesn't — while still echoing your preference back to you.

The defense isn't to stop pinning versions. It's to treat every pinned version in your stack as a dated liability with a known expiry, and to assert on the shape of what comes back instead of trusting that a 200 means the contract held.

For Meta specifically, the date is September 24, 2026, and the diff is available today.

I write about API drift — the changes that keep returning 200 while quietly changing what your integration receives. FlareCanary monitors API responses and schemas for exactly this class of change.

Klaviyo retired an API revision on July 15 — if you pinned it, your profile writes silently changed behavior

FlareCanary — Mon, 03 Aug 2026 05:01:52 +0000

Most API deprecations announce themselves. You pin a version, the vendor retires it, and your next call comes back 410 Gone with a link to the migration guide. Annoying, but it's a signal — something in your monitoring goes red, someone gets paged, and the work gets scheduled.

Klaviyo does something different, and it's written plainly in their versioning policy:

If a retired revision date is passed to the request header, Klaviyo falls forward and responds to your request with the same behavior as the next oldest revision.

Read that again with an on-call hat on. Your revision: 2024-07-15 header keeps getting sent. Klaviyo keeps returning 200. Your logs, your traces, your API client's user-agent string — all still say 2024-07-15. But the code path serving you changed.

Revision 2024-07-15 reached its support end date on July 15, 2026. If you're pinned to it — or anything older — you've been served 2024-10-15 behavior since then. And 2024-10-15 itself retires on October 15, 2026, which is a sharper cliff than the one that already passed.

Why fall-forward is worse than a hard failure

The trade Klaviyo made is deliberate and defensible: don't break integrations that stopped being maintained. The cost is that "still works" and "still works correctly" stop being the same thing, and nothing in the response distinguishes them.

Klaviyo is direct about this in the same doc — relying on fall-forward is "likely to introduce unwanted, breaking changes in your app." There's a partial exception worth knowing: calls to endpoints that were removed after your pinned revision do return a 410. So endpoint removals are loud. Behavior changes to endpoints that still exist are silent. That asymmetry is the whole problem, because the July 15 cliff was entirely the second kind.

Cliff one (already fired): profile identity resolution

The breaking change in 2024-10-15 — the behavior you're getting now if you pinned 2024-07-15 — is on the Profiles API. Klaviyo's changelog describes it as updating the profile endpoints to an enhanced identity resolution processor that better follows Klaviyo's identifier priority order. It affects Create Profile and Update Profile.

Identity resolution decides which existing profile your write lands on. Klaviyo's precedence runs roughly: Klaviyo ID, then external_id, then email, then phone_number, then anonymous/device ID. When you POST a profile carrying more than one identifier, that order determines whether you update an existing record, merge two records, or create a new one.

Change the matching processor and you change the destination of a write that returns an identical 200 either way. Concretely:

1. Multi-identifier writes can land on a different profile. The classic payload from a store sync carries both a customer ID and an email:

{
  "data": {
    "type": "profile",
    "attributes": {
      "external_id": "cust_88213",
      "email": "sam@example.com",
      "properties": { "lifetime_value": 412.00 }
    }
  }
}

If external_id and email point at different existing profiles — and in real catalogs they often do — the resolution order decides the winner. Stale or reused external IDs are extremely common: guest checkouts that later register, customer records rebuilt during a platform migration, staging IDs that leaked into production, ID namespaces merged after an acquisition. When the tiebreak changes, lifetime_value: 412.00 gets written to a different human being than it did in June. Status: 200.

2. Writes that used to create now merge (and overwrite). If the new processor matches an identifier the old one didn't, a call that previously created a fresh profile now updates an existing one — and custom properties on that existing profile get overwritten by your payload. Your "new profiles created today" metric drops, which reads like a top-of-funnel problem, not an API problem.

3. Consent state can land on the wrong profile. This is the one to care about. Subscribe and unsubscribe writes resolve to a profile like any other write. A resolution change that redirects a consent write is a compliance problem wearing a 200 OK: someone who unsubscribed keeps receiving email because the suppression landed next door.

4. Your billable profile count moves. Klaviyo bills on active profiles. Duplicates and merges both shift that number, and the shift shows up on an invoice weeks after the code that caused it shipped — long past the point where anyone connects the two.

None of these throw. There is no error rate to alert on. The only observable is data that is quietly wrong.

Cliff two (October 15, 2026): the one to schedule work for

On October 15, 2026, 2024-10-15 retires and anyone pinned to it falls forward to 2025-01-15. That revision carries three changes, and they fail in different ways:

Offset pagination becomes cursor pagination on Get Messages for Flow Action and Get Action ID for Flow Message. This is the silent-truncation shape that has bitten teams on Jira, monday.com, and Contentful this year. The canonical loop:

let offset = 0;
const all = [];
while (true) {
  const res = await getMessagesForFlowAction({ page_offset: offset });
  all.push(...res.data);
  if (res.data.length < PAGE_SIZE) break;   // "short page = done"
  offset += PAGE_SIZE;
}

Two independent ways this loses data under cursor pagination: the offset parameter stops steering the result set, and a non-final cursor page is not guaranteed to be full, so the short-page heuristic exits early. You get a plausible-looking partial list of flow messages. If that list feeds a content audit or a template-sync job, the missing tail is invisible — you can't miss messages you never learned existed.

The Campaigns API restructures for push notification support. 2025-01-15 changed the request and response structure across Get Campaigns, Get Campaign, Create Campaign, Update Campaign, Create Campaign Clone, and the campaign-message endpoints. Reporting code that reaches into a nested field by path gets undefined rather than an exception — and undefined propagates into a dashboard as a zero or a blank far more often than it propagates as a stack trace.

Bulk Subscribe/Unsubscribe Profiles now require the subscriptions field. This one is loud — a missing required field is a 4xx. Good. It's also the only one of the three you'll find out about on day one.

So the October cliff is a mix, and the loud member of the set is the least dangerous.

What to actually do

The audit is small and it beats reading the changelog diff by hand:

1. Find every pinned revision. Grep for the header across your services, your serverless functions, your ETL jobs, and — the one people forget — your official Klaviyo SDK version, which pins a revision internally:

grep -rn --include='*.{js,ts,py,rb,php,go,java}' -e 'revision' -e '2024-0' -e '2024-10-15' .

Check the third-party middleware too. iPaaS connectors, reverse-ETL tools, and agency-built integrations all pin revisions, and none of them will tell you when one retires.

2. Sort what you find into three buckets. Anything at 2024-07-15 or older is already being served newer behavior — that's not future work, that's a live audit of the last two weeks of profile writes. Anything at 2024-10-15 has until October 15. Anything 2025-01-15 or newer has runway.

3. For the already-fired group, look at the data, not the logs. The logs are clean by construction. Query for profiles created since July 15 that duplicate an existing external_id or email, and diff your daily new-profile count across the July 15 boundary. A step change on that date is your answer.

4. Pin deliberately, then monitor the pin. Pinning a revision is correct — it's what the header is for. What breaks teams is pinning and then never revisiting, so the pin silently becomes a lie about which behavior you're getting. A retirement date is a known future date. Put it in the calendar the day you pin.

The general shape

Fall-forward versioning is spreading — Klaviyo, monday.com, Contentful, and Xero have all shipped some flavor of it in the last year. The appeal to a vendor is obvious: nobody's integration goes dark on a Tuesday.

But it converts a hard failure into a data-quality failure, and it moves detection from your error budget to whoever eventually notices the numbers look wrong. The version header stops being a contract and becomes a preference — one the server is free to ignore once the date passes, while still echoing it back to you.

The defensive move isn't to stop pinning. It's to treat every version header in your stack as something with an expiry date attached, and to assert on the shape of what comes back rather than trusting that a 200 means the contract held.

Twilio removes conference_participant from Voice Insights on Aug 1, 2026 — the field goes null, not gone, so nothing errors

FlareCanary — Fri, 31 Jul 2026 05:00:46 +0000

If you pull Twilio Voice Insights Call Summaries to analyze conference calls — contact-center reporting, a QA dashboard that scores participant talk-time, a reconciliation job that joins conference legs — there's a removal landing on August 1, 2026 that fails in the quietest way an API change can: the field you read doesn't disappear, it just stops carrying data. Same 200. Same JSON shape. attributes: null.

Twilio is removing the conference_participant field from the Voice Insights Call Summary on August 1, 2026 — from both the REST API and Event Streams. Their reasoning is fair: the field predates the purpose-built Conference Insights product, and its accuracy was always shaky because conference call flows are complicated. But the mechanism of the removal is the trap.

The field that was already mostly null

Here's the part that makes this silent instead of loud. From Twilio's own note:

It is currently only populated for calls eligible to participate in a Twilio conference; all others return attributes: null. After removal, all calls will uniformly return attributes: null.

Read that twice. The field already returns null for the majority of calls today — any call that wasn't conference-eligible. Which means every consumer that reads conference_participant has already been written to tolerate null. You had to be null-safe from day one, or your Call Summary parser would have crashed on every non-conference call years ago.

So the code is robust. It handles null gracefully. And that robustness is exactly why August 1 slides past unnoticed: the day your real conference-participation data flips to null looks identical to every non-conference call you've been safely ignoring the whole time. There's no new error path to trip, because the null path was load-bearing from the start.

// Call Summary today, for a conference-eligible call
{
  "call_sid": "CA…",
  "conference_participant": {
    "attributes": { /* participant data */ }
  }
}

// Same call, same request, on Aug 1 2026 — still 200 OK
{
  "call_sid": "CA…",
  "conference_participant": {
    "attributes": null      // <- your dashboard reads this as "no conference"
  }
}

The if (summary.conference_participant?.attributes) guard you wrote to survive non-conference calls now silently classifies every call as non-conference. Your conference metrics don't error. They trend to zero.

What actually breaks

Consumer	Before Aug 1	On/after Aug 1
REST: `GET /v1/Voice/{CallSid}/Summary`	`conference_participant.attributes` populated for conference legs	uniformly `null`, 200 OK
REST: `GET /v1/Voice/Summaries` (list/scan jobs)	conference legs carry attributes	every row `null`
Event Streams: Call Summary event	event payload includes the field	field present, value `null`
A dashboard that counts "conference participants seen"	real number	quietly decays to 0

Three failure shapes, all 200-clean:

Analytics that zero out. A daily rollup of conference participation — average participants per conference, talk-time distribution, hold events — keeps running, keeps writing rows, and the numbers just slide toward zero starting August 1. Because the trend is gradual-looking (it's a step, but a step in a noisy metric reads as "quiet week"), nobody gets paged. Zeros don't alert; nulls don't alert. Only errors alert, and there aren't any.
Event Streams pipelines that dead-end silently. If you sink Voice Insights Call Summary events into Kinesis / a webhook consumer / a warehouse and route on conference_participant, the events keep arriving on schedule. The field keeps arriving too — as null. There's no dead-letter, no schema-validation failure (the field still exists, it's just empty), no gap in the stream. The pipeline is perfectly healthy and perfectly empty.
Joins that go from sparse to empty. A reconciliation job that enriches conference legs by joining Call Summary conference_participant against your own conference records now matches nothing. If the join is a LEFT JOIN, you get rows with null enrichment and no complaint. If downstream logic treats "no participant attributes" as "leg wasn't in a conference," you've just reclassified your entire conference history.

The migration is not a rename

This is the cost that makes it worth doing before the cliff, not after. conference_participant is not being replaced by a differently-named field on the same resource. The replacement is a different API with a different addressing model: Conference Insights — the Conference Summary and Conference Participant Summary resources, plus Conference Insights Event Streams.

The Call Summary is keyed by CallSid — you look up a single call and read its (former) conference attributes inline. Conference Insights is keyed by ConferenceSid / ParticipantSid:

# Old (removed Aug 1) — conference data hung off the call
GET https://insights.twilio.com/v1/Voice/{CallSid}/Summary
    -> conference_participant.attributes

# New — conference data lives on the conference
GET https://insights.twilio.com/v1/Conferences/{ConferenceSid}
GET https://insights.twilio.com/v1/Conferences/{ConferenceSid}/Participants/{ParticipantSid}

So the migration isn't "read a new key." It's: capture ConferenceSid/ParticipantSid at call time (or map CallSid → ConferenceSid), fan out to a second resource, and reshape your storage from call-centric to conference-centric. That's real work, and it's why the three-plus months of runway matters — the failure mode if you don't is not an exception you'll catch in staging, it's a metric that quietly goes to zero in prod.

What to grep for

# Any read of the field being removed (REST or SDK)
grep -rEi 'conference_participant' src/

# Event Streams / warehouse consumers routing on it
grep -rEi 'conference_participant|conferenceParticipant' \
  --include=*.{js,ts,py,go,java,sql,json} .

# Call Summary endpoints whose payloads carry it
grep -rE 'Voice/[^/]+/Summary|/Voice/Summaries|insights\.twilio\.com' src/

# Null-guards that will now match every call (the silent reclassifier)
grep -rE 'conference_participant.{0,20}(attributes|null|\?\.|&&)' src/

The non-grep audit: anything wired through a no-code connector (a Zapier/Make/n8n step, a warehouse sync, a BI tool pulling Voice Insights) that references conference_participant won't show up in your repo at all — check those pipelines by hand.

Who this actually hits — and who it doesn't

Be honest about the blast radius, because it's narrower than most silent-drift stories. If you don't run Twilio conferences, this is a non-event — the field was null for you already and stays null. If you already migrated to Conference Insights, you're done. The population in the crosshairs is specific: teams doing conference-call analytics on Voice Insights who still read conference_participant — contact centers, CPaaS-built collaboration tools, compliance/QA recording pipelines that score multi-party calls.

But that's exactly the population least likely to notice, for the same reason every entry in this table is 200 OK: the people who built conference analytics on this field built it years ago, wrapped it in a null guard because they had to, and haven't looked at that code since it started working. The August 1 removal is invisible to precisely the code most affected by it.

FlareCanary watches the response shapes of the APIs you depend on and tells you when a field that used to carry data starts returning null, when a 200 stops meaning what it meant last week, or when a value your dashboards read every night quietly empties out. Twilio's conference_participant removal is the textbook case: no error, no status-code change, no schema break — just data that stops arriving under a healthcheck that stays green. flarecanary.com

Greenhouse Harvest v1/v2 retires August 31 — three silent failure modes during your v3 cursor pagination migration

FlareCanary — Tue, 28 Jul 2026 05:00:48 +0000

If you have an ATS integration that reads Greenhouse data — a custom recruiter dashboard, a Snowflake warehouse pulling candidate history, a Slack bot that posts interview scorecards, anything piped through the Harvest API — you have nine weeks. On August 31, 2026, Greenhouse removes Harvest API v1 and v2 entirely. Every integration must be on v3 by that date.

The Greenhouse Harvest landing page puts it plainly: "The Harvest v1/v2 API is deprecated and will be removed on August 31, 2026. Please migrate to Harvest v3."

The loud failure mode after the cutoff is the one teams plan around. v1/v2 endpoints stop accepting requests, you get a 4xx, you redeploy with v3.

The failure modes worth thinking about live in the migration window — the next nine weeks, while v1/v2 and v3 both work and integrations are partly converted. Three of them swallow data without raising an error.

The v3 changes that matter for silent drift

Before the failure modes, the v3 shape. Three things changed that touch every paginated endpoint:

Surface	v1 / v2	v3
Auth	Basic Auth (API token as username, blank password, Base64-encoded)	OAuth 2.0 bearer token
Pagination	`Link` header (RFC 5988) with `rel="next"`, `rel="prev"`, `rel="last"`	`Link` header with only `rel="next"`, cursor must be the only query parameter on subsequent requests
Rate limiting	`X-RateLimit-Limit` over a 10-second window	The same headers over a longer fixed window

The pagination row is the one the v3 docs are most emphatic about. From the Harvest v3 pagination guide: "When you pass a cursor, it must be the only query parameter." And: "Treat the cursor as an opaque value: don't parse it, and don't try to construct it yourself."

Both of those are sharp. Both of them break in ways the migration team is going to miss.

1. The "cursor + filter → 422 → end of pages" silent truncation

The most common shape of a v1/v2 paginated extract:

url = f"/v1/applications?job_id={job_id}&per_page=500"
while url:
    resp = session.get(url)
    resp.raise_for_status()
    rows.extend(resp.json())
    url = parse_link_header(resp.headers.get("Link", "")).get("next")

Note the structure of the loop: the first request carries the filters (job_id, per_page, created_after, whatever). The subsequent requests follow the Link: <...>; rel="next" URL the server hands back. In v1/v2, that URL has all the filter parameters baked in. The loop stops when there is no next link.

A migration that converts the first request to v3 but forgets that v3's cursor rule is "cursor must be the only query parameter" produces this:

url = "/v3/applications?job_id=123&per_page=500"  # first request
while url:
    resp = session.get(url)
    resp.raise_for_status()                      # <-- the problem
    rows.extend(resp.json())
    url = parse_link_header(resp.headers.get("Link", "")).get("next")

The first request succeeds and returns a page of applications for job_id=123 plus a Link header with a cursor URL. Greenhouse's cursor URL does not include job_id=123 — the cursor encodes the position internally. The migration team, looking at this from a code-review distance, doesn't notice that job_id has dropped.

The next iteration follows the cursor URL. v3 accepts it. The pages keep coming. The pipeline ingests applications from job_id=123, then applications from job_id=124, then 125, and so on — every application in the tenant, not just the one job the original query asked for.

That's the version where the loop doesn't even raise. The version that does raise looks like this — the migration team appends the cursor to a URL builder that still adds tenant-default query parameters:

url = build_url("/v3/applications", cursor=cursor_from_link, per_page=500)

Greenhouse v3 returns 422 Unprocessable Content because there are two query parameters and cursor must be alone. A pipeline whose retry logic treats 4xx as "permanent — stop paginating" silently completes with whatever rows it got from page 1.

There's no error in your warehouse. Your row counts are lower than yesterday's, but day-over-day variance on ATS data is normal and nobody alerts on a 30% drop on a Tuesday. The integration's healthcheck shows green because the last call returned a response. The deferred symptom is "our recruiting funnel dashboard has been wrong for two weeks."

2. The `prev` and `last` Link rels are gone

v3 returns only rel="next". The official guide: "Harvest v3 currently returns only a next link (no prev or last)."

For most batch ETL, this doesn't matter — you walked forward, you stopped at the end. For interactive consumers, it matters a lot.

The patterns that break silently:

"Jump to last page" controls in admin UIs reading the rel="last" link and using its cursor. The Link header lacks that rel; a permissive HTTP client returns None rather than raising; the UI button stops working. Most ATS admin tools route through a generic API gateway that swallows missing rels.
"Page back" controls that walked rel="prev". Same story — silently dead, no error.
Total-count estimates built by following rel="last" and reading the page number from the URL. The page number isn't in the URL anyway (v3 uses opaque cursors), so this was already going to break, but now it breaks before the URL parser gets a chance to fail — the rel just isn't there.

If your codebase has any of links["prev"], links["last"], or a parse_link_header call that doesn't assert which rels it got, those callsites need an audit before September 1.

3. Cursor parsing for "where am I" silently desyncs

The v3 cursor is opaque. The docs are direct: "don't parse it, and don't try to construct it yourself." In practice it's a Base64-encoded value that encodes a primary-key position — Harvest paginates by id descending.

Two patterns that break:

The "resume from yesterday" cron. Long-running ETL pipelines often persist the last cursor they consumed and resume from that cursor the next day. v1/v2 had stable, predictable next-URLs that were safe to store. v3's cursor is opaque, and Greenhouse hasn't published a stability guarantee — a cursor stored today may produce 422 Unprocessable Content tomorrow if the cursor format changes, or it may silently produce data from a different position if the encoding's interpretation drifts. The safer pattern is to store a high-water mark by id or updated_at and re-paginate from there each run, not to persist cursors.

The "skip to row 10,000" debug helper. Engineers who built tools that take a cursor as a CLI flag and parse it to print "you're at position X" silently degrade to "you're at position [unparseable]." Worse, helpers that construct a synthetic cursor (e.g., to start partway through a sync) hit a 422 and either crash or get silently treated as "no more data."

Anyone writing v3-compatible code should treat the cursor exactly like the docs say — a token to be passed back, never inspected. Code that diverges from this rule is the first thing to grep for during the migration audit.

What to grep for before September 1

Four targeted searches that catch the bulk of v1/v2-shaped code in a typical Harvest integration:

# Direct version pins
grep -rE 'harvest\.greenhouse\.io/v[12]|api/v[12]/(candidates|applications|jobs|offers)' src/

# Basic Auth that won't carry to v3
grep -rE 'Authorization: Basic|base64.*api[_-]?key.*:' src/ scripts/

# Link header parsers that read rels v3 doesn't return
grep -rE 'rel=["\x27]?(prev|last)|links\[["\x27](prev|last)' src/

# Cursor parsing or construction
grep -rE 'base64.*decode.*cursor|cursor\s*=\s*[fF]"|f["\x27]\?cursor=' src/

The non-grep audit is the persisted-config check: any Airbyte connector, Fivetran connector, Workato recipe, or n8n workflow with harvest.greenhouse.io/v1 or /v2 in its config string needs to be re-pointed before August 31, and any stored cursors flushed before the version flip.

Why this lands silently when v3 is more strict, not less

The strict-pagination rule (cursor must be alone) is exactly the kind of contract change that produces silent failure when error handling is generic. A 200-OK with the wrong rows fails open. A 422 from a pipeline that treats 4xx as "stop, no more data" also fails open. The only loud failure is "the v1 endpoint is gone" — and that's the one that doesn't fire until September 1.

The window from now to August 31 is when the wrong code is most likely to ship: v3 endpoints work, v1/v2 endpoints work, and the migration looks "done" because all the tests pass and the dashboards have data. The data is just from the wrong rows.

FlareCanary watches the response shapes of API endpoints you depend on and tells you when filter parameters silently drop, pagination links vanish from headers, or row counts shift in ways that look normal but aren't. Greenhouse's v3 migration is exactly the kind of transition where a passing healthcheck and a clean Sentry feed don't mean what you think they mean. flarecanary.com

Contentful's August 14 CMA update silently truncates your role lists and strips fields from user responses

FlareCanary — Sat, 25 Jul 2026 05:00:43 +0000

If you manage Contentful spaces programmatically — a script that syncs roles into your IdP, a member-roster export, an onboarding job that provisions access, anything that hits the Content Management API to enumerate roles or users — two changes land on August 14, 2026 that fail in the worst way: they return a 200, valid JSON, and less data than they did the day before.

Both are listed on Contentful's own API changes page. Neither throws an error. Both depend on a precondition you might not be checking — the shape of the pagination block, or the role of the token doing the reading.

Change 1: the roles endpoint swaps offset pagination for cursors

The endpoint is GET /spaces/{spaceId}/roles. Today it paginates the way most Contentful collection endpoints do:

{
  "total": 42,
  "skip": 0,
  "limit": 25,
  "items": [ ... ]
}

As of August 14 it switches to cursor-based pagination. total and skip go away; you get a pages object with next/previous cursor links instead, and limit stays:

{
  "limit": 25,
  "pages": { "next": "<cursor>", "previous": null },
  "items": [ ... ]
}

The migration is documented and the fix is "use pageNext/pagePrev cursor parameters instead of skip." The problem is what happens to code that doesn't migrate, because none of it errors out.

The three ways this silently truncates

1. The total-driven loop exits after page one. This is the canonical offset-pagination idiom:

let skip = 0;
const all = [];
do {
  const res = await getRoles({ skip, limit: 25 });
  all.push(...res.items);
  skip += res.limit;
} while (skip < res.total);   // res.total is now undefined

After August 14, res.total is undefined. skip < undefined evaluates to false on the first iteration, so the loop runs exactly once and stops. A space with 60 roles syncs the first 25 and silently drops 35 — no exception, no empty result you'd notice, just a short list that looks plausible.

2. The "short page means last page" heuristic drops the tail. Code that decides it's done when items.length < limit is making an assumption cursor pagination doesn't honor — a non-final cursor page is not guaranteed to be full. Stop on the first short page and you lose every role after it. (This is the same class of bug teams hit with cursor migrations on Jira, monday.com, and Greenhouse — a server can return a half-full page with a live next cursor.)

3. Persisted numeric offsets have nothing to persist. A cron job that stores "I got through skip=50, resume there next run" breaks completely: cursors are opaque tokens scoped to a live pagination session, not a stable integer offset you can stash in a database and reuse tomorrow. The stored offset is meaningless and the resume logic either errors or restarts from the top.

What runs GET /roles? Access-provisioning automation that maps Contentful roles to an IdP, compliance exports that enumerate who-can-do-what, and admin dashboards. A truncated role list means access reviews that miss roles, and provisioning logic that can't find a role it's supposed to assign.

Change 2: user-data responses become role-based

The second change hits "Get all users in a space" and "Get all Space Members in a space." Contentful's exact wording:

API responses for user data will become role-based: Admin users will continue to receive full responses, with no changes. Non-admin users will receive limited user information.

So the same request, same endpoint, same 200 returns a fuller or thinner user object depending on the role of the token making the call. Admin token: unchanged. Non-admin token: trimmed payload.

This is a nastier silent surface than the pagination one, because it's environment-dependent in a way that defeats casual testing:

1. It works in dev and under-fetches in prod. You build and test the integration with your own admin Personal Access Token — full responses, everything's there. It ships to prod running under a scoped, non-admin service token, and after August 14 the fields you depend on quietly stop coming back. Classic "works on my machine," except the machine is the token's role and nothing in your code changed.

2. User-sync and audit exports write nulls. A job that reads email (or any of the fields that get trimmed) off the users list with a non-admin token now gets undefined for them. Downstream you get user records synced with blank emails, SCIM-ish reconciliation that can't match people, audit CSVs with empty columns — all populated from a 200 response that looks successful.

3. Member dashboards render partial detail with nothing to alert on. A 200 with a smaller object doesn't trip error monitoring. The dashboard just shows less, and unless someone eyeballs it against yesterday, the regression is invisible.

The fix is to check, before August 14, which token role your integration uses against these endpoints. If it's non-admin, confirm exactly which user fields you read, and either elevate the token to admin (if the use case justifies it) or stop depending on the fields that get trimmed.

What to grep for

Any pagination loop against /spaces/{spaceId}/roles that reads .total or increments .skip — those break on August 14. Migrate to reading pages.next and stopping when it's absent.
Any "done when items.length < limit" heuristic on a Contentful collection — replace with "done when there's no next cursor."
Any persisted numeric offset for roles pagination — it can't survive the cursor migration.
Any call to the space-users or space-members endpoints, plus the role of the token that makes it. Non-admin tokens reading user fields are the ones that silently lose data.

The tell for both changes is identical and easy to miss: a 200 OK that returns less than it did yesterday. There's no status code, no error body, and no changelog entry that fires inside your monitoring — the response is structurally valid and semantically wrong.

Schema drift like this — a field that stops populating, a pagination block that changes shape, a payload that thins out under a scoped token — is exactly the failure mode FlareCanary was built to catch: it watches your real API responses and tells you when their shape changes, before the silently-wrong data reaches your database.

monday.com's API now returns 200 users instead of your whole account — the 2026-07 version flip that fails silently

FlareCanary — Wed, 22 Jul 2026 05:00:38 +0000

If you sync users out of monday.com — an SSO deprovisioning job, an HR-to-monday roster sync, a SCIM-ish reconciliation script, a dashboard that counts seats, anything that runs query { users { id email } } — there's a change that went live on July 1, 2026 and fails in the worst way: it returns a 200, valid JSON, and the wrong number of users.

monday.com versions its API by date. Version 2026-07 entered release-candidate on April 1, 2026 and became the Current (default stable) version on July 1, 2026. The detail that makes this silent is monday's own documented default:

If you don't pass an API-Version header, your app will always get the Current version.

So every integration that doesn't pin an explicit version — and a lot of them don't, because the SDKs make it optional — rolled onto 2026-07 on July 1 with no deploy, no changelog read, no error. Integrations pinned to an older version aren't safe either: when monday deprecates a version, requests to it fall forward to the Maintenance version (that's exactly what the February 15, 2026 deprecation did — it routed 2025-01 and 2024-10 to 2025-04). Either path lands you on the new Query.users behavior eventually.

And the 2026-07 release is a full overhaul of the User entity. Most of it is documented as a breaking change. The parts that bite are the ones that don't break loudly.

What changed in `Query.users`

Surface	Before `2026-07`	`2026-07` (Current since Jul 1)
No `limit` argument	all matching users returned	200 users returned
Maximum `limit`	unbounded	1000 (over that → error)
`created_at`	`Date` (`2024-01-15`)	`ISO8601DateTime!` (`2024-01-15T09:30:00Z`, non-null)
`birthday`	`Date`	`String`
`utc_hours_diff`	`Int`	`Float`
`emails` argument	`[String]`	`[String!]` (nulls in the array now rejected)
`is_admin`, `is_guest`, `is_view_only`, `is_pending`, `enabled`, `is_verified`	present	deprecated (removed in `2026-10`)
`kind`, `newest_first`, `non_active` arguments	present	deprecated → `user_kind`, `sort`, `status` (removed in `2026-10`)

The headline is the first row. The rest stack on top of it.

1. `Query.users` without a `limit` silently caps at 200

This is the query that's in everyone's codebase:

query {
  users {
    id
    email
    name
  }
}

Before 2026-07, that returned every user in the account. As of July 1 it returns the first 200 and stops — no nextPageToken-style signal in the response telling you there's more, no error, no warning header. A 700-seat account syncs 200 users and silently drops 500.

Think about what runs that query:

SSO / SCIM deprovisioning. A nightly job pulls the monday user list, diffs it against the IdP, and disables anyone who left. After July 1 it only ever sees the first 200 users — so offboarded people in the tail of the list never get deprovisioned. That's not a cosmetic bug; it's dangling access to a system of record.
Seat / license reconciliation. Finance counts users to true-up billing. The count quietly drops to 200 and the numbers look better, so nobody investigates.
HR roster sync. New hires past the 200th user never appear downstream.

The fix is explicit pagination — you now have to page with limit and page:

query ($page: Int!) {
  users (limit: 1000, page: $page) {
    id
    email
  }
}

…and loop until a page comes back with fewer than limit rows. Note limit itself is now capped at 1000; asking for more is one of the few things here that does error, which is at least honest.

2. Three scalar type changes that parse fine and store wrong

created_at went from a bare Date to a non-null ISO8601DateTime!. The field name didn't change, it's still a JSON string, the query still returns 200 — but the value went from 2024-01-15 to 2024-01-15T09:30:00Z. Anything that:

writes it into a DATE column (now you're truncating or erroring on the time component, depending on the driver),
does string equality against a stored YYYY-MM-DD,
or parses with a format string that doesn't expect a T/Z,

now silently mismatches. Date-range filters that compare created_at >= '2024-01-15' as strings can flip results because '2024-01-15T09:30:00Z' > '2024-01-15' lexically.

utc_hours_diff went from Int to Float. The whole point is half-hour and 45-minute offsets — India is 5.5, Nepal 5.75. Code that did parseInt, integer math, or unmarshalled into a Go int / Java int either drops the fraction silently or, in strict-typed clients, throws on the decimal. A "schedule this user's reminder in their timezone" feature is now off by 30 minutes for a chunk of the planet.

birthday went Date → String. Looser, but the same shape of trap: code expecting a parseable date object gets a free-form string.

3. The second shoe: `2026-10` removes the fields you're still reading

In 2026-07 the old User fields are deprecated but still work. That's the trap — your code keeps reading them, your tests stay green, and the migration looks done. On the 2026-10 version they're removed outright:

Permission booleans is_admin, is_guest, is_view_only, is_pending, enabled, is_verified → replaced by a single status (a UserStatus enum) plus user_kind. A access-control check like if (user.is_admin) either starts erroring on an unknown field (loud, if your client validates the schema) or — with permissive clients and fragment spreads — reads null/undefined and treats an admin as a non-admin, or vice-versa. Either direction is a security-relevant silent failure.
Photo fields photo_original, photo_thumb, photo_thumb_small, photo_tiny, photo_small → replaced by a nested photo_url { original thumb tiny ... } object. Avatars silently 404 / go blank.
Argument renames kind → user_kind, newest_first → sort, non_active → status. A query filtering users(non_active: true) to find deactivated accounts keeps working through the 2026-07 window, then loses the argument in 2026-10 — and depending on how your client handles an unknown argument, you either error or silently get the unfiltered set (active users where you expected inactive).

If you only fix the 200-cap and stop, you've bought three months. The field removals are the same migration; do them now.

What to grep for

# monday user queries with no limit (the 200-cap)
grep -rEi 'users\s*(\([^)]*\))?\s*\{' src/ | grep -vi 'limit'

# Deprecated permission booleans removed in 2026-10
grep -rE 'is_admin|is_guest|is_view_only|is_pending|is_verified|\.enabled' src/

# Deprecated photo fields -> photo_url { ... }
grep -rE 'photo_(original|thumb|thumb_small|tiny|small)' src/

# Deprecated query arguments
grep -rEw 'kind|newest_first|non_active' src/

# created_at parsed/stored as a bare date
grep -rE 'created_at' src/ | grep -iE 'date|split|substr|strftime|DATE'

# And the root cause: requests that never pin a version
grep -rEi 'api-version|monday.*version' src/

The non-grep audit is the connector check: any Make, Zapier, n8n, Workato, or homegrown job hitting api.monday.com/v2 that doesn't set an explicit API-Version header is, by monday's own rule, running on 2026-07 right now.

Why this one lands silently

Pin an explicit API-Version header and none of this touches you until you decide to move — that's the entire point of date-based versioning, and monday tells you to do it. But the default for an unversioned request isn't "stay where you are," it's "always get Current." So the integrations most exposed are the ones nobody's looked at in a year: the quiet nightly sync that's worked since 2024 and has no version header because it predates versioning.

Every failure here returns 200 OK with syntactically perfect, semantically incomplete data. The user list parses. The count is a plausible number. The deprovisioning job exits zero. The healthcheck that asserts "last call was 2xx" stays green. The only loud signal — asking for limit over 1000, or hitting a removed field on a strict client — is the least likely path. The likely path is a roster that quietly got shorter on July 1 and a deprovisioning gap nobody will notice until an audit.

FlareCanary watches the response shapes of the APIs you depend on and tells you when a default limit changes, when a scalar like created_at starts carrying a time component, or when a field you read every night quietly disappears. monday's 2026-07 version flip is exactly the kind of 200-OK-but-wrong transition that slips past healthchecks and Sentry alike. flarecanary.com

Jira's agile API drops offset pagination on November 1, 2026 — three ways your board and sprint syncs silently truncate

FlareCanary — Sun, 19 Jul 2026 05:00:48 +0000

If you sync data out of Jira — a sprint-report dashboard, a Snowflake warehouse pulling issue history, a Slack bot that posts backlog counts, a custom burndown chart, anything reading the agile REST API — you have a pagination change coming that fails in the worst possible way: quietly.

On November 1, 2026, Jira Software Cloud removes random page access from a set of nine agile endpoints. The Jira Software Cloud changelog gives a six-month deprecation window and is explicit: the endpoints that page with startAt will be removed, and integrations must move to token-based pagination using nextPageToken.

The endpoints in scope are the ones every agile integration leans on:

GET /rest/agile/1.0/board/{boardId}/issue — issues for a board
GET /rest/agile/1.0/board/{boardId}/backlog — issues in the backlog
GET /rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issue — issues in a sprint
GET /rest/agile/1.0/board/{boardId}/epic/{epicId}/issue — issues under an epic
GET /rest/agile/1.0/sprint/{sprintId}/issue
plus the board/epic/sprint listing endpoints

The loud failure is the one teams plan around: after November 1 the deprecated startAt path is gone, you get an error, you redeploy. The failures worth thinking about happen before that — during the migration window, while both shapes work and the integration looks "done." Three of them swallow issues without raising anything.

What actually changed in the response

Two things, and the second is the one that bites:

Surface	Old (offset)	New (token)
Page position	`startAt` query param	`nextPageToken` query param
End-of-results signal	`startAt + maxResults >= total`	`isLast: true` / `nextPageToken` absent
`total`	returned on every response	no longer returned
Random access	jump to any page; prefetch in parallel	sequential only — you must walk the tokens

A response now looks like this:

{
  "maxResults": 50,
  "issues": [ ... ],
  "nextPageToken": "CAEaAggB",
  "isLast": false
}

No startAt. No total. You paginate by passing nextPageToken back on the next request, and you stop when isLast is true (or nextPageToken is absent). If you need a count, Atlassian points you at a separate approximate-count endpoint — the number is no longer free on the page you already fetched.

Every one of the failure modes below comes from old code that assumed total exists and that a short page means the end.

1. `total` is gone, so `while (startAt < total)` exits after page one

The single most common offset loop in the wild:

start_at, total = 0, None
issues = []
while total is None or start_at < total:
    resp = session.get(
        f"/rest/agile/1.0/board/{board_id}/issue",
        params={"startAt": start_at, "maxResults": 50},
    ).json()
    issues.extend(resp["issues"])
    total = resp["total"]          # <-- KeyError, or .get() -> None
    start_at += 50

When total stops coming back, one of two things happens, and both fail open:

If the code reads resp["total"] directly, you get a KeyError — at least that's loud. But most production clients learned long ago to use resp.get("total") defensively.
With total = resp.get("total") → None, the loop condition start_at < None raises in Python 3, but the very common guarded form while total is None or start_at < total: evaluates total is None as True forever — so this one actually loops. The nastier variant is while start_at < (total or 0):, which is 0 < 0 → False after the first page. One page of issues, loop exits clean, no error.

That last shape — (total or 0), total ?? 0, total || maxResults — is everywhere, because it's the idiom people reach for to "handle the case where total is missing." After November 1 (and on the new endpoints before then), it silently caps every sync at the first maxResults issues. A board with 800 issues reports 50. The burndown chart still renders. The sprint report still has rows. Nobody alerts on "the dashboard has data, just less of it."

2. The "short page means done" heuristic drops the tail

The other way teams avoid depending on total is to stop when a page comes back shorter than maxResults:

let issues = [], token = undefined;
do {
  const page = await getIssues({ maxResults: 50, nextPageToken: token });
  issues.push(...page.issues);
  token = page.nextPageToken;
} while (page.issues.length === 50);   // <-- the bug

With offset pagination, a full page reliably meant "there's probably more," and a short page meant "you're at the end." Token pagination breaks that assumption. Token-based pages are not guaranteed to be full — the server can hand you 30 issues on a page with isLast: false and a valid nextPageToken, and the next page has the rest.

This is the exact failure Atlassian integrators have been hitting on the platform's matching JQL migration: any query returning more results than maxResults silently drops results, with no indication that more exist. The loop above sees a 30-issue page, decides 30 !== 50 means "done," throws away a perfectly good nextPageToken, and returns a truncated set. The only correct end-of-results signal is isLast === true or an absent nextPageToken — never the length of the page.

If you have any pagination loop whose exit condition references .length, len(...), count, or === maxResults, that's the first callsite to fix.

3. Parallel prefetch and persisted offsets quietly stop working

Two performance patterns that were safe with startAt and aren't with tokens:

Parallel page prefetch. Dashboards that need a whole board fast often fan out requests — startAt=0, startAt=50, startAt=100 — concurrently, because with offsets you can compute every page boundary up front from total. Token pagination is strictly sequential: you can't know page N's token until you've fetched page N-1. A migration that keeps the parallel fan-out has nothing to fan out — it either collapses to fetching page one several times, or guesses offsets the new endpoint ignores. You get the first page, in triplicate, and call it the board.

Persisted offset high-water marks. Long-running cron syncs frequently store "I got up to startAt=400, resume there tomorrow." There is no numeric offset to persist anymore, and the cursor token is opaque and not documented as stable across runs. A pipeline that resumes from a stored offset against the new endpoint resumes from nowhere — silently re-ingesting from the top or skipping the delta, depending on how the resume code degrades. The durable pattern is to re-paginate from the start each run and filter by updated date, not to persist position.

What to grep for before November 1

# Agile endpoints that page by offset
grep -rE 'rest/agile/1\.0/(board|sprint).*(issue|backlog)' src/

# Loops that depend on total
grep -rE "\.get\(['\"]total|\[['\"]total['\"]\]|total\s*\|\|\s*0|total\s*\?\?\s*0" src/

# End-of-results heuristics based on page length, not isLast
grep -rE "length\s*===?\s*\w*max|len\(.*\)\s*<\s*max|< maxResults" src/

# Parallel offset fan-out
grep -rE "startAt\s*[:=]\s*(i\s*\*|page\s*\*|\d+\s*\*)" src/

The non-grep audit is the connector check: any Fivetran, Airbyte, Workato, n8n, or homegrown ETL job that reads /rest/agile/1.0/board/.../issue with startAt needs to move to nextPageToken and stop trusting total. And anything that persists a numeric pagination offset between runs needs to switch to a date high-water mark.

Why this one lands silently

Every failure here returns 200 OK with a syntactically perfect, semantically incomplete response. The first page is real issues. The JSON parses. The dashboard renders. The healthcheck — which almost always asserts "did the last call return 2xx" — stays green. The only loud signal, the removed startAt endpoint, doesn't fire until November 1, by which point the silently-truncated version may have been shipping wrong sprint metrics for weeks.

Token pagination is the right call on Atlassian's part — offset paging over a moving issue set was never consistent. But "more correct" and "drop-in compatible" are different things, and the gap between them is exactly where a passing test suite and a clean error feed stop meaning what you think they mean.

FlareCanary watches the response shapes of the APIs you depend on and tells you when a field like total stops appearing, when a pagination contract changes, or when row counts shift in ways that look normal but aren't. Jira's agile pagination migration is precisely the kind of 200-OK-but-wrong transition that slips past healthchecks and Sentry alike. flarecanary.com

Google Ads API v21 sunsets in August — three silent ways the forced version bump corrupts your reports (still 200 OK)

FlareCanary — Thu, 16 Jul 2026 05:01:01 +0000

If anything you run touches the Google Ads API — a bid-management tool, an agency reporting pipeline, a Looker Studio connector, a budget-pacing script, a custom dashboard pulling spend into a warehouse — you are on a clock you may not have noticed. Google moved the Google Ads API to a monthly release cycle in 2026, and each major version now lives for roughly one year after launch. Versions are sunsetting faster than they used to, and quietly.

The dates that matter right now:

v20 sunset on June 10, 2026. Requests on v20 now fail.
v21 sunsets around August 6, 2026 — one year after its August 6, 2025 release. (sunset schedule)
v22 (Oct 15, 2025) and v23 (Jan 28, 2026) are the versions you're migrating to.

v21 is still one of the most widely pinned versions in production. If yours is one of them, you have until early August to move — and the version you land on (v23+) carries breaking changes from both v22 and v23 stacked on top of each other.

The loud failure is the one you'll plan for

When a version sunsets, requests against it fail. You get an error, your monitoring lights up, you bump the version string in your client config and redeploy. Annoying, visible, fixable.

That's not the failure mode that costs you a month of wrong numbers.

The Google Ads API is queried through GAQL and read back through generated client-library protos (google-ads-python, google-ads-php, the .NET and Java libraries). Both layers are forgiving in exactly the wrong way during a version bump: a query that used to return a value can keep returning 200 OK with that value silently changed, blanked, or reclassified. Three of those are worth grepping for before August.

1. A removed enum value makes your ad-type switch fall through

v23 removed VIDEO_OUTSTREAM from three enums at once: AdType, AdvertisingChannelSubType, and AdGroupType (v23 release notes).

The field still exists. Your query still succeeds. But the value you were branching on never arrives anymore. Consider the canonical reporting shape — bucket spend by ad type:

TYPE_LABELS = {
    "VIDEO_BUMPER":   "Bumper",
    "VIDEO_OUTSTREAM": "Outstream",   # v23: this enum value no longer exists
    "VIDEO_TRUEVIEW_IN_STREAM": "In-stream",
}

for row in ga_service.search(customer_id=cid, query=GAQL):
    label = TYPE_LABELS.get(row.ad_group_ad.ad.type_.name, "Other")
    spend[label] += row.metrics.cost_micros

After the bump, rows that used to come back as VIDEO_OUTSTREAM come back as UNKNOWN / UNSPECIFIED (or are reshaped onto a different type). TYPE_LABELS.get(...) doesn't raise — it returns "Other". Your outstream spend silently collapses into a catch-all bucket, or vanishes if you filter that bucket out. The query is valid, the response is 200, the totals at the campaign level still reconcile, and the only symptom is that one row in a breakdown table is wrong. Nobody alerts on that.

The same trap applies anywhere you WHERE or GROUP BY one of these enums, and to the if channel_sub_type == ... branches that route campaigns to different handlers. A branch that no longer matches doesn't error — it falls through to the default.

2. Asset performance metrics come back empty, not missing

v22 removed AssetPerformanceLabel for Performance Max campaigns. v23 went further: it removed aggregate asset performance-label metrics, and the performance-label enum is no longer returned for Search and Display (release notes).

Here's the asymmetry that makes this silent. If you SELECT a field that the version has deleted, GAQL throws a loud error and you find it in testing immediately. But these aren't deletes of the field path — they're cases where the field stops being populated. The asset still has a performance_label; for Search and Display it now returns the unspecified/empty value instead of LOW / GOOD / BEST.

# Query still valid, still 200. Field now empty for Search/Display assets.
query = """
  SELECT asset.id, ad_group_ad_asset_view.performance_label, metrics.impressions
  FROM ad_group_ad_asset_view
  WHERE segments.date DURING LAST_30_DAYS
"""
for row in ga_service.search(customer_id=cid, query=query):
    if row.ad_group_ad_asset_view.performance_label.name == "LOW":
        flag_for_replacement(row.asset.id)   # never fires again

Your "replace low-performing assets" automation stops finding anything to replace. Your asset-health dashboard shows every asset as unlabeled and reads it as "fine." There is no error, no empty result set, no 4xx — just a column that used to carry signal and now carries blanks. The same goes for the Campaign.url_expansion_opt_out field removed in v22 (now governed by AssetAutomationType.FINAL_URL_EXPANSION_TEXT_ASSET_AUTOMATION): code that read the old boolean to decide whether to trust final-URL targeting silently reads a default and takes the wrong branch.

3. The renamed error field that breaks your error handler

This one is small and perfect. v22 renamed BudgetPerDayMinimumErrorDetails.minimum_bugdet_amount_micros to minimum_budget_amount_micros — Google fixed a typo in the field name (release notes).

If you wrote graceful budget-error handling — the kind that catches the API's "your daily budget is below the minimum" error and surfaces the actual minimum to the user — you almost certainly hard-coded the misspelled field name, because that's what the API gave you:

except GoogleAdsException as ex:
    for error in ex.failure.errors:
        details = error.details.budget_per_day_minimum_error_details
        # pre-v22 field name; returns proto default (0) after the bump
        user_message = f"Minimum daily budget is {details.minimum_bugdet_amount_micros / 1e6}"

After the bump, minimum_bugdet_amount_micros no longer exists on the proto; accessing it returns the default 0 (proto3 doesn't raise on unknown-as-default access in several client libraries). Your error handler now tells users the minimum budget is $0.00 — at exactly the moment they're hitting a budget error and need a real number. It fires only in the error path, which is the path with the thinnest test coverage.

Bonus: the Feeds removal is the loud one — but it relocated your extension data

v23 removed all feed-related entities — Feed, FeedMapping, FeedService, AdGroupFeed, feed_placeholder_view, and the rest. Queries against those resources fail loudly, so you'll catch the direct breakage. The quieter follow-on: sitelinks, callouts, and structured snippets that used to live in Feeds now live in Assets, with a different shape and different IDs. Reporting that aggregated extension performance by feed item has to be rebuilt against the asset model, and the rebuild is where double-counting and dropped extensions creep in. That's a migration project, not a one-line version bump.

What to grep for before August 6

# Direct version pins in client config / URLs
grep -rnE 'v2[0-3]|google-ads.*version|GOOGLE_ADS_API_VERSION' src/ config/

# Enum values removed or reshaped in v22/v23
grep -rnE 'VIDEO_OUTSTREAM|AssetPerformanceLabel|url_expansion_opt_out' src/

# The renamed error field
grep -rn 'minimum_bugdet_amount_micros' src/

# Feed entities removed in v23
grep -rnE 'FeedMapping|AdGroupFeed|feed_placeholder_view|FeedService' src/

# Any switch/dict keyed on ad type or channel sub-type — audit for fall-through defaults
grep -rnE 'ad_group_type|advertising_channel_sub_type|ad\.type_' src/

The non-grep check is the persisted-config sweep: any Supermetrics, Funnel, Adverity, or homemade connector with a pinned v20/v21 in its settings needs re-pointing, and every dashboard that buckets by ad type or reads an asset performance label needs a spot-check against a v23 response before the cutover — not after.

Why a forced upgrade fails silently

The mental model for a version sunset is "it either works or it 503s." For the transport layer, that's true. For the data, it isn't. GAQL keeps answering, the protos keep deserializing, and the values inside them quietly change contract: an enum loses a member, a metric stops populating, a field gets renamed out from under your accessor. Every one of those returns 200.

The window between now and August 6 is when the wrong code ships, because both behaviors are observable at once: v21 still answers, v23 already answers, the tests pass, and the dashboards have numbers in them. The numbers are just bucketed wrong, blanked, or zeroed — and "the report has data" is not the same as "the report is right."

FlareCanary watches the response shapes of the API endpoints you depend on and tells you when an enum value disappears, a metric goes empty, or a field gets renamed between versions — the drift that returns 200 and slips past a green healthcheck. A forced version sunset like Google Ads v21 → v23 is exactly the transition where passing tests don't mean what you think they mean. flarecanary.com

Xero's Reference field stops returning invoice numbers on July 13 — and reconciliation won't notice

FlareCanary — Mon, 13 Jul 2026 05:01:07 +0000

If you sync Xero — a bookkeeping integration, a payments reconciliation tool, an e-commerce-to-ledger bridge, or an in-house script that's been matching customer prepayments to invoices since forever — there's a one-line changelog entry with your name on it, and it doesn't throw an error.

For as long as most integrators can remember, the Reference field on Xero's Bank Transaction, Prepayment, and Payment endpoints has returned the invoice number for prepayment transactions. Not the reference you typed on the transaction — the invoice number Xero generated. That was never quite what the field name promised, but it was stable, and a lot of code came to depend on it: "to find the invoice this prepayment belongs to, read Reference." On July 13, 2026, that stops being true.

What actually changes

Xero is making the prepayment endpoints internally consistent with the rest of the API and with the web app. The rollout has two dates:

Date	Change
April 13, 2026	A new explicit `InvoiceNumber` field becomes available on these responses. It is the new source of truth for the RECEIVE-PREPAYMENT invoice number. `Reference` is unchanged — still returns the invoice number.
July 13, 2026	`Reference` stops returning the invoice number for RECEIVE-PREPAYMENTs and switches to returning the transaction's actual reference data — the free-text reference, which is usually different and often empty.

So there's a three-month window where both behaviours coexist: the new field is present, the old field hasn't flipped yet, and everything keeps working. That window is exactly what makes this dangerous. Nothing breaks in April. Nothing breaks in May or June. Code reviews pass. Then on July 13 the meaning of a field changes underneath running integrations that were "tested and working" a quarter earlier.

Why this is a silent failure, not a loud one

Every property of the response that a client checks stays the same:

HTTP status: still 200 OK.
JSON shape: Reference is still there, still a string. No field added or removed from the perspective of old code.
Type: still a string. No deserialization error, no null where an object was expected.
The value: silently changes from "INV-0042" to whatever someone typed in the reference box — "Deposit", "Stripe payout", or "".

A schema validator that checks "is Reference a present string?" passes on both sides of July 13. The only thing that changed is the semantics of the field — and semantics don't show up in a status code.

The three ways this bites

1. Invoice matching silently misses

The canonical prepayment-reconciliation loop reads Reference to find the invoice:

// Match a RECEIVE-PREPAYMENT bank transaction back to its invoice
const invoiceNo = txn.Reference;                 // "INV-0042" … until July 13
const invoice   = await findInvoiceByNumber(invoiceNo);
if (invoice) applyPrepayment(invoice, txn.Total);

Before July 13, txn.Reference is "INV-0042" and the lookup hits. After July 13, txn.Reference is the free-text reference — often empty, sometimes a memo like "June deposit". findInvoiceByNumber("") returns nothing, applyPrepayment never runs, and the prepayment sits unreconciled. No exception, no log line, no failed request. Your books just quietly stop matching prepayments to invoices, and someone notices weeks later when the aged-receivables report doesn't foot.

2. The worse case: it matches the wrong invoice

Missing matches are the lucky outcome. The unlucky one is a collision. If a user happened to type something into the reference box that looks like another invoice number — or your findInvoiceByNumber does fuzzy/partial matching — the post-July-13 Reference value can resolve to a different, real invoice. Now a prepayment is applied against the wrong customer's invoice, two ledgers are wrong, and the only evidence is a number that matched something it shouldn't have. Silent-wrong is always more expensive than silent-missing, because you trust the result.

3. Filtering by reference changes what comes back

The same change makes filtering "optimised" to operate on real reference data. Code that filters or searches bank transactions and prepayments by Reference expecting to query on invoice numbers will, after July 13, be filtering on a different field's worth of data. Queries that returned the prepayment for INV-0042 yesterday return nothing today — or return a different set — and a paginated sync that keys off those results silently drops rows it used to pick up.

The fix is small — if you make it before July 13

Xero gave you the escape hatch in April: the explicit InvoiceNumber field. The migration is a one-line read change, and the safe window to do it is now, while Reference still agrees with InvoiceNumber so you can verify the swap against live data before the flip:

// Source of truth for the invoice number is InvoiceNumber, not Reference
const invoiceNo = txn.InvoiceNumber ?? txn.Reference;   // belt-and-suspenders during the window
const invoice   = await findInvoiceByNumber(invoiceNo);

What to audit in every Xero integration you own:

Grep for Reference on prepayment/payment paths. Anything that reads .Reference off a Bank Transaction, Prepayment, or Payment response and treats it as an invoice number is on the clock. Search grep -rn "\.Reference" . and triage every hit on these endpoints.
Switch invoice-number reads to InvoiceNumber. It's available now (since April 13). Make the swap, deploy, and confirm it matches the current Reference value before July 13 — that's your free regression test.
Re-check anything that filters by reference. If you query BankTransactions or Prepayments using Reference to pull by invoice number, move that filter to the new field and re-validate the result set.
Don't assume Reference is now useless — assume it's now correct. After July 13 it carries the real user reference. If you have a separate need for that (display, search by user memo), this is an upgrade. The danger is only where the old meaning was load-bearing.

The cutoff date here is loud in the changelog and silent in production. April's new field is the gift; July 13 is the cliff. The whole point of the three-month overlap is to let you migrate while you can still see both values side by side — which only helps if you know the flip is coming.

FlareCanary monitors API responses for schema drift, silent field-semantics changes, and quiet removals across upstream providers. If you run integrations against Xero, Stripe, Shopify, PayPal, or anywhere else that ships breaking changes through a changelog post and a 200 OK, flarecanary.com catches the drift before your reconciliation does.

PayPal IPN is deprecated — the IPN Webhooks migration drops payments in four silent ways

FlareCanary — Sat, 11 Jul 2026 04:02:14 +0000

If you take money through PayPal's legacy Instant Payment Notification (IPN) — a Website Payments Standard button, a WooCommerce/Gravity Forms PayPal Standard gateway, or a hand-rolled listener.php that's been quietly confirming orders since 2014 — the ground is already moving under you. PayPal stopped letting merchants generate new IPN/WPS credentials at the end of 2025, Website Payments Standard is deprecated as of January 2026, and full end-of-life lands in January 2027. The replacement is REST Webhooks.

The deadline isn't the dangerous part. Jan 2027 is far enough that everyone plans for it. The dangerous part is the migration window we're in right now, because IPN→Webhooks is not a rename. It changes four things at once, and each one has a failure mode that returns HTTP 200 to PayPal — which makes PayPal stop retrying — while your system silently never records the payment.

IPN and Webhooks disagree on almost everything

Surface	IPN (legacy)	Webhooks (REST)
Content type	`application/x-www-form-urlencoded`	`application/json`
Payload shape	flat key/value pairs	nested `resource` object
Amount field	`mc_gross` = `"19.95"`	`resource.amount.value` + `resource.amount.currency_code`
Status field	`payment_status` = `"Completed"`	`event_type` and `resource.status` = `"COMPLETED"`
Buyer email	`payer_email` (top level)	no equivalent in the capture resource
Custom ref	`custom`	`custom_id`
Transaction id	`txn_id`	`resource.id` (capture id) / `id` (event id `WH-…`)
Verification	POST back `cmd=_notify-validate`, expect `VERIFIED`	RSA-SHA256 over raw body + `PAYPAL-TRANSMISSION-*` headers + cert chain

A migration that treats this as "point the same handler at the new payload" is broken on every row. Here are the four that fail quietly.

1. The body parser still expects form-encoding — so every field is `undefined`

IPN listeners are wired to read a form POST:

app.post('/paypal/ipn', express.urlencoded({ extended: false }), (req, res) => {
  const status = req.body.payment_status;   // "Completed"
  const amount = req.body.mc_gross;         // "19.95"
  if (status === 'Completed') fulfillOrder(req.body.custom, amount);
  res.sendStatus(200);
});

Point PayPal Webhooks at that endpoint without touching the parser and the JSON body lands on express.urlencoded, which parses it into a single garbage key or an empty object. req.body.payment_status is undefined, the === 'Completed' check is false, fulfillOrder never runs — and the handler still falls through to res.sendStatus(200).

That 200 is the trap. PayPal treats 2xx as "delivered" and stops retrying. The payment is captured, the buyer is charged, your webhook said OK, and the order is never fulfilled. Nothing in your logs is red. The only signal is a customer emailing "I paid and got nothing" days later — and by then the webhook is long past its retry window, so you can't even replay it without going to the PayPal dashboard.

2. Field paths moved, and the ones that didn't move changed meaning

Even after you switch to a JSON parser, a 1:1 field map fails because the data is nested and renamed:

// IPN brain, JSON body
const amount = req.body.mc_gross;              // undefined → NaN downstream
const ref    = req.body.custom;                // undefined (it's custom_id now)
const email  = req.body.payer_email;           // undefined — and unrecoverable here

The correct paths are req.body.resource.amount.value (a string, not a number — "19.95"), req.body.resource.amount.currency_code (now a separate field; IPN folded currency into mc_currency alongside mc_gross), and req.body.resource.custom_id.

payer_email is the sharp one. IPN handed you the buyer's email on every notification. The PAYMENT.CAPTURE.COMPLETED resource does not contain the payer email at all — payer identity lives on the order, one API call up, not on the capture. Any code that keys a customer record, sends a receipt, or matches an account off payer_email gets undefined and either crashes (loud, lucky) or writes a blank/null email into your users table (silent, unlucky). The fix is a follow-up GET /v2/checkout/orders/{id} — an architectural change, not a field rename.

And amount being a string means mc_gross * quantity or any arithmetic that used to coerce cleanly now produces NaN or string concatenation. "19.95" < 20.00 is true by coercion but "100.00" < 20.00 is false — comparisons mostly work until the one order where they don't.

3. Status vocabulary: `"Completed"` → `"COMPLETED"`, in two places

IPN had one status field with title-case values: payment_status = "Completed" | "Pending" | "Refunded" | "Denied". Webhooks split that into two layers, both upper-case:

event_type — "PAYMENT.CAPTURE.COMPLETED", "PAYMENT.CAPTURE.REFUNDED", "PAYMENT.CAPTURE.DENIED"
resource.status — "COMPLETED", "PENDING", "DECLINED"

Code carried over verbatim — if (status === 'Completed') — silently never matches "COMPLETED". No error; the branch just never fires, so paid orders sit forever in "awaiting payment." The case flip is the kind of thing that passes a quick eyeball review (Completed and COMPLETED read the same when you're skimming) and fails 100% of the time in production.

The deeper trap is the vocabulary split. A refund used to arrive as payment_status = "Refunded" on the same field you were already reading. Now a refund is a different event_type (PAYMENT.CAPTURE.REFUNDED) that your handler may not even be subscribed to. If you only registered PAYMENT.CAPTURE.COMPLETED, refunds and chargebacks simply never reach you — your books say paid, PayPal says refunded, and the drift is invisible until reconciliation.

4. Verification flips from a postback handshake to RSA-SHA256 — and skip-verify becomes an open wallet

IPN verification was a callback: take the exact payload, POST it back to PayPal with cmd=_notify-validate, and trust it only if PayPal replies VERIFIED. Webhooks replace that entirely with offline RSA-SHA256: you reconstruct a signing string from the raw request body, the PAYPAL-TRANSMISSION-ID, PAYPAL-TRANSMISSION-TIME, your webhook id, and a CRC32 of the body, then verify the PAYPAL-TRANSMISSION-SIG against the public cert at PAYPAL-CERT-URL. (Or you call PayPal's /v1/notifications/verify-webhook-signature and check verification_status === "SUCCESS".)

Two silent failure modes hide here:

The old postback still "works" enough to fool you. During deprecation the _notify-validate endpoint hasn't vanished, but posting a JSON webhook body back to it doesn't return VERIFIED. Teams that kept the postback path see every webhook fail verification → return 4xx → PayPal retries then gives up → payments lost, exactly as in #1, but now it looks like a security check doing its job.
The skip-verify fallback becomes an open endpoint. The most dangerous pattern is the dev-convenience branch:

const sig = req.headers['paypal-transmission-sig'];
if (!sig) return process(req.body);      // "must be a local test"
if (!verify(req)) return res.sendStatus(401);
process(req.body);

Anyone who learns your webhook URL can now POST a hand-written PAYMENT.CAPTURE.COMPLETED with any custom_id and amount they like, omit the signature header, and walk straight through to fulfillOrder. IPN's postback design made this attack awkward (PayPal had to confirm). Webhook verification done wrong makes it a curl one-liner. This won't appear in any log as an error — the forged request returns 200 just like a real one.

What to grep for in every PayPal integration you own

grep -rn "payment_status\|mc_gross\|payer_email\|_notify-validate" .

Each hit is IPN-era code that breaks on the JSON payload. Then specifically:

Parser: anything reading req.body.* on a PayPal route behind urlencoded middleware — JSON webhooks need a JSON parser and the raw body preserved for signature verification (express.json({ verify: (req,_,buf) => req.rawBody = buf })).
Status checks: every === 'Completed' / 'Refunded' / 'Pending' — flip to upper-case resource.status and branch on event_type. Confirm you're subscribed to refund/dispute events, not just COMPLETED.
Amounts: every mc_gross → resource.amount.value, and treat it as a string — parse explicitly before arithmetic or comparison.
Buyer identity: every payer_email → there is no drop-in; add the GET /v2/checkout/orders/{id} lookup or capture payer data at checkout instead of expecting it on the webhook.
Verification: kill any if (!sig) skip branch, and make sure you're doing RSA-SHA256 over the raw body — not posting JSON back to _notify-validate.
Idempotency: dedup keyed on txn_id silently treats every webhook as new (the field is gone). Re-key on the event id (WH-…) or resource.id.

The reason this one is worth auditing now rather than in late 2026 is that the failure isn't gated on the January 2027 cliff. The moment you flip a button or gateway from IPN to Webhooks — which merchants are doing all through 2026 — these modes are live, and the worst of them (silent 200, lost payment, open endpoint) produce no error anywhere in your stack. The cutoff is loud. The migration is not.

FlareCanary monitors API responses for schema drift, silent removals, and behavior changes across upstream providers. If you run integrations against PayPal, Stripe, Shopify, GitHub, or anywhere else that ships breaking changes through changelog posts and deprecation notices, flarecanary.com catches the drift before your customers do.

PayPal IPN is deprecated — the IPN Webhooks migration drops payments in four silent ways

FlareCanary — Fri, 10 Jul 2026 05:00:43 +0000

IPN and Webhooks disagree on almost everything

Surface	IPN (legacy)	Webhooks (REST)
Content type	`application/x-www-form-urlencoded`	`application/json`
Payload shape	flat key/value pairs	nested `resource` object
Amount field	`mc_gross` = `"19.95"`	`resource.amount.value` + `resource.amount.currency_code`
Status field	`payment_status` = `"Completed"`	`event_type` and `resource.status` = `"COMPLETED"`
Buyer email	`payer_email` (top level)	no equivalent in the capture resource
Custom ref	`custom`	`custom_id`
Transaction id	`txn_id`	`resource.id` (capture id) / `id` (event id `WH-…`)
Verification	POST back `cmd=_notify-validate`, expect `VERIFIED`	RSA-SHA256 over raw body + `PAYPAL-TRANSMISSION-*` headers + cert chain

A migration that treats this as "point the same handler at the new payload" is broken on every row. Here are the four that fail quietly.

1. The body parser still expects form-encoding — so every field is `undefined`

IPN listeners are wired to read a form POST:

app.post('/paypal/ipn', express.urlencoded({ extended: false }), (req, res) => {
  const status = req.body.payment_status;   // "Completed"
  const amount = req.body.mc_gross;         // "19.95"
  if (status === 'Completed') fulfillOrder(req.body.custom, amount);
  res.sendStatus(200);
});

2. Field paths moved, and the ones that didn't move changed meaning

Even after you switch to a JSON parser, a 1:1 field map fails because the data is nested and renamed:

// IPN brain, JSON body
const amount = req.body.mc_gross;              // undefined → NaN downstream
const ref    = req.body.custom;                // undefined (it's custom_id now)
const email  = req.body.payer_email;           // undefined — and unrecoverable here

3. Status vocabulary: `"Completed"` → `"COMPLETED"`, in two places

IPN had one status field with title-case values: payment_status = "Completed" | "Pending" | "Refunded" | "Denied". Webhooks split that into two layers, both upper-case:

event_type — "PAYMENT.CAPTURE.COMPLETED", "PAYMENT.CAPTURE.REFUNDED", "PAYMENT.CAPTURE.DENIED"
resource.status — "COMPLETED", "PENDING", "DECLINED"

4. Verification flips from a postback handshake to RSA-SHA256 — and skip-verify becomes an open wallet

Two silent failure modes hide here:

The old postback still "works" enough to fool you. During deprecation the _notify-validate endpoint hasn't vanished, but posting a JSON webhook body back to it doesn't return VERIFIED. Teams that kept the postback path see every webhook fail verification → return 4xx → PayPal retries then gives up → payments lost, exactly as in #1, but now it looks like a security check doing its job.
The skip-verify fallback becomes an open endpoint. The most dangerous pattern is the dev-convenience branch:

const sig = req.headers['paypal-transmission-sig'];
if (!sig) return process(req.body);      // "must be a local test"
if (!verify(req)) return res.sendStatus(401);
process(req.body);

What to grep for in every PayPal integration you own

grep -rn "payment_status\|mc_gross\|payer_email\|_notify-validate" .

Each hit is IPN-era code that breaks on the JSON payload. Then specifically:

Parser: anything reading req.body.* on a PayPal route behind urlencoded middleware — JSON webhooks need a JSON parser and the raw body preserved for signature verification (express.json({ verify: (req,_,buf) => req.rawBody = buf })).
Status checks: every === 'Completed' / 'Refunded' / 'Pending' — flip to upper-case resource.status and branch on event_type. Confirm you're subscribed to refund/dispute events, not just COMPLETED.
Amounts: every mc_gross → resource.amount.value, and treat it as a string — parse explicitly before arithmetic or comparison.
Buyer identity: every payer_email → there is no drop-in; add the GET /v2/checkout/orders/{id} lookup or capture payer data at checkout instead of expecting it on the webhook.
Verification: kill any if (!sig) skip branch, and make sure you're doing RSA-SHA256 over the raw body — not posting JSON back to _notify-validate.
Idempotency: dedup keyed on txn_id silently treats every webhook as new (the field is gone). Re-key on the event id (WH-…) or resource.id.

OpenAI's Assistants API shuts down August 26 — but the silent failures hit weeks earlier, when you migrate

FlareCanary — Tue, 07 Jul 2026 05:01:15 +0000

On August 26, 2026, OpenAI removes the Assistants API. Calls to /v1/assistants, /v1/threads, and /v1/threads/runs start returning errors. That date has been on developer calendars for a year, and it's the easy part: a hard cutoff fails loudly, in your face, on a day you can plan around.

The part that actually costs people is the migration to the Responses API — and that one doesn't wait for August 26, and it doesn't fail loudly.

When you port an Assistants-based app to Responses, the endpoints answer with 200 OK. Nothing throws. But three things the Assistants API used to manage for you are now your job, and if you wire any of them wrong, the failure shows up as degraded behavior, not an error: a model that forgets context, grounding that quietly drops, a stream that renders blank. You ship it, it looks fine in a smoke test, and it's wrong in production.

Why this is the dangerous kind of breaking change

The Assistants API was stateful and opinionated. A Thread persisted conversation history, truncated it to fit the context window, and orchestrated tool runs — implicitly, with no code on your side. The Responses API is deliberately simpler: you send input items, you get output items back. Almost everything the Thread did for you is now an explicit decision.

That inversion is the trap. A "shallow" migration — swap the endpoint, keep the shape of your code — compiles, runs, and returns 200. The regressions are in the gap between what the Thread used to do automatically and what you now have to do on purpose. None of that gap raises an exception. It just makes the output worse, on a delay, in ways your tests probably don't assert on.

Here are the three places it bites.

1. State regression — follow-up turns silently lose context

In the Assistants API, you appended a message to a Thread and the Thread was the state. History and truncation were handled for you.

In Responses, persistent conversation state is explicit. You either chain turns by passing previous_response_id from the last response into the next request, or you use the Conversations API to hold history. Two things go wrong here, both silently:

You forget to chain at all. Each request becomes effectively stateless. The first turn looks perfect. The second turn — "and make it shorter" — has no idea what "it" is, because the prior turn's context and your earlier system constraints never traveled with it. The API returns a fluent, confident, context-free answer with a 200. There's no error to catch; the model just behaves like it has amnesia.
You mix both mechanisms. OpenAI's guidance is explicit: pick one state model per workload — previous_response_id or Conversations — and don't interleave them ad hoc. Apps that half-adopt Conversations while still passing response IDs get inconsistent history depending on the path a request takes. Constraints set early in a session reappear and disappear between turns, and it reads like a flaky model rather than a state bug.

The Assistants version of this code couldn't have this bug, because the Thread never let state fall on the floor. The Responses version can, and it won't tell you.

2. Retrieval regression — RAG grounding drops with no error

Assistants file_search was forgiving: a run could search across both assistant-level and thread-level vector stores, and the run flow wired retrieval in for you. You attached files, asked a question, and got grounded answers.

In Responses, file search is configured explicitly on the tool — you pass the vector_store_ids you want searched, and retrieval behavior is yours to tune. The failure mode is obvious in hindsight and invisible at runtime: miss a vector store in the list, and that knowledge silently disappears from grounding. The request succeeds. The model still answers — it just answers from less context, or from none, and falls back on its parametric memory.

A retrieval miss doesn't look like a 404. It looks like a slightly worse answer, or a confidently wrong one, for the subset of questions that depended on the store you dropped. Nobody gets paged. Your eval suite — if you have one — catches it. Your 200-checking integration test does not.

3. Streaming breakage — the SSE event taxonomy changed

If you stream responses, this is the one most likely to ship broken to real users.

The Assistants API emitted run-centric server-sent events — deltas tied to runs, run steps, and messages (thread.run.step.delta, thread.message.delta, and friends). Downstream consumers were written to pattern-match those event types and assemble the output from them.

The Responses API emits a different event taxonomy — response-centric events like response.output_text.delta and response.completed. A consumer still listening for the old thread.* events does something worse than crash: it connects, the stream opens, events flow, the stream completes — and none of them match the handlers it's looking for. The result is an empty or truncated render on a connection that, by every status check, succeeded. 200, clean SSE, blank UI.

This is exactly the kind of break that passes review (the request works!) and gets discovered by a user, because the failure lives in event-name strings, not in HTTP status.

The bonus that hits your bill, not your logs

Built-in tools moved too. In Responses, hosted tools like web search and file search carry per-call fees that didn't exist under the Assistants API. Migrate a high-traffic assistant that leaned on those tools and your functionality is identical, your error rate is zero, and your invoice drifts up with no code change to point at. Silent cost regression is still a regression.

And there's no shortcut waiting to save you: OpenAI has stated it will not ship an automated tool to migrate existing Threads into Conversations. The recommended path is to start new sessions on the new model and backfill old history yourself. Anyone counting on a one-click migration in August is going to find out, in August, that it isn't coming.

What to actually do before August 26

Treat the migration as an architecture change, not an endpoint swap. The three regressions above all come from assuming Responses will do what the Thread did implicitly. It won't. Map your state, retrieval, and streaming explicitly.
Pick one state model and assert on it. previous_response_id or Conversations — not both. Add a test that runs a multi-turn conversation and checks that turn N actually respects a constraint set in turn 1. That single test catches the silent amnesia bug.
Pin your vector store IDs and eval grounding. Diff the stores your old assistant could reach against the vector_store_ids you pass in Responses. Then run a retrieval eval, not just a 200 check — a request that returns successfully with empty grounding is the failure you're looking for.
Rewrite your stream consumer for the new events and test it end to end. Don't assume your SSE parser "still works" because the connection opens. Confirm it assembles real output from response.* events, not thread.* ones.
Watch the response shape, not just the status code. Every one of these failures returns 200. The only way to catch a state drop, a grounding miss, or an unhandled event is to inspect what's actually in the response — not whether the call succeeded.

The shutdown date is the loud, well-advertised part, and it's the part you're least likely to get wrong. The migration is the quiet part — and a 200 that's missing your context, your grounding, or your output is far harder to notice than an honest error on August 26.

FlareCanary watches your API responses for exactly this: a field that changes type, a value that goes null, an event shape that drifts, a contract that quietly stops meaning what it used to. Migrations like Assistants → Responses are where response shapes change silently — and a 200 with the wrong shape is the failure that reaches your users before it reaches your logs. If the contract you depend on changes, you hear it from us first.

DEV Community: FlareCanary

Meta's Graph API v20 expires September 24 — your calls won't fail, they'll quietly start running v21

The failure modes split into two groups, and only one of them pages you

The API is loud. Your pipeline is quiet.

Grep won't find all of it

The useful part: you can diff this today

Why this pattern keeps showing up

Klaviyo retired an API revision on July 15 — if you pinned it, your profile writes silently changed behavior

Why fall-forward is worse than a hard failure

Cliff one (already fired): profile identity resolution

Cliff two (October 15, 2026): the one to schedule work for

What to actually do

The general shape

Twilio removes conference_participant from Voice Insights on Aug 1, 2026 — the field goes null, not gone, so nothing errors

The field that was already mostly null

What actually breaks

The migration is not a rename

What to grep for

Who this actually hits — and who it doesn't

Greenhouse Harvest v1/v2 retires August 31 — three silent failure modes during your v3 cursor pagination migration

The v3 changes that matter for silent drift

1. The "cursor + filter → 422 → end of pages" silent truncation

2. The prev and last Link rels are gone

3. Cursor parsing for "where am I" silently desyncs

What to grep for before September 1

Why this lands silently when v3 is more strict, not less

Contentful's August 14 CMA update silently truncates your role lists and strips fields from user responses

Change 1: the roles endpoint swaps offset pagination for cursors

The three ways this silently truncates

Change 2: user-data responses become role-based

What to grep for

monday.com's API now returns 200 users instead of your whole account — the 2026-07 version flip that fails silently

What changed in Query.users

1. Query.users without a limit silently caps at 200

2. Three scalar type changes that parse fine and store wrong

3. The second shoe: 2026-10 removes the fields you're still reading

What to grep for

Why this one lands silently

Jira's agile API drops offset pagination on November 1, 2026 — three ways your board and sprint syncs silently truncate

What actually changed in the response

1. total is gone, so while (startAt < total) exits after page one

2. The "short page means done" heuristic drops the tail

3. Parallel prefetch and persisted offsets quietly stop working

What to grep for before November 1

Why this one lands silently

Google Ads API v21 sunsets in August — three silent ways the forced version bump corrupts your reports (still 200 OK)

The loud failure is the one you'll plan for

1. A removed enum value makes your ad-type switch fall through

2. Asset performance metrics come back empty, not missing

3. The renamed error field that breaks your error handler

Bonus: the Feeds removal is the loud one — but it relocated your extension data

What to grep for before August 6

Why a forced upgrade fails silently

Xero's Reference field stops returning invoice numbers on July 13 — and reconciliation won't notice

What actually changes

Why this is a silent failure, not a loud one

The three ways this bites

1. Invoice matching silently misses

2. The worse case: it matches the wrong invoice

3. Filtering by reference changes what comes back

The fix is small — if you make it before July 13

PayPal IPN is deprecated — the IPN Webhooks migration drops payments in four silent ways

IPN and Webhooks disagree on almost everything

1. The body parser still expects form-encoding — so every field is undefined

2. Field paths moved, and the ones that didn't move changed meaning

3. Status vocabulary: "Completed" → "COMPLETED", in two places

4. Verification flips from a postback handshake to RSA-SHA256 — and skip-verify becomes an open wallet

What to grep for in every PayPal integration you own

PayPal IPN is deprecated — the IPN Webhooks migration drops payments in four silent ways

IPN and Webhooks disagree on almost everything

1. The body parser still expects form-encoding — so every field is undefined

2. Field paths moved, and the ones that didn't move changed meaning

3. Status vocabulary: "Completed" → "COMPLETED", in two places

4. Verification flips from a postback handshake to RSA-SHA256 — and skip-verify becomes an open wallet

What to grep for in every PayPal integration you own

OpenAI's Assistants API shuts down August 26 — but the silent failures hit weeks earlier, when you migrate

Why this is the dangerous kind of breaking change

1. State regression — follow-up turns silently lose context

2. Retrieval regression — RAG grounding drops with no error

3. Streaming breakage — the SSE event taxonomy changed

2. The `prev` and `last` Link rels are gone

What changed in `Query.users`

1. `Query.users` without a `limit` silently caps at 200

3. The second shoe: `2026-10` removes the fields you're still reading

1. `total` is gone, so `while (startAt < total)` exits after page one

1. The body parser still expects form-encoding — so every field is `undefined`

3. Status vocabulary: `"Completed"` → `"COMPLETED"`, in two places

1. The body parser still expects form-encoding — so every field is `undefined`

3. Status vocabulary: `"Completed"` → `"COMPLETED"`, in two places