DEV Community: FlareCanary

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.

Shopify retires API version 2025-07 on July 16 — pinned apps don't error, they silently fall forward to 2025-10

FlareCanary — Sun, 05 Jul 2026 04:01:32 +0000

On July 16, 2026 at 15:00 UTC, Shopify stops serving API version 2025-07. If your app, integration, or script still pins that version, here is the part that catches people off guard:

Your requests do not start failing.

There is no 400, no 406, no "unsupported version" error. Shopify's documented behavior is to fall forward: a request for an inaccessible version is served using the oldest accessible stable version instead. After July 16, that's 2025-10. So a call that says X-Shopify-Api-Version: 2025-07 quietly gets answered by 2025-10 — a schema you never tested against, on a date you didn't pick.

Same endpoint. Same 200 OK. Different response shape.

Why this is the dangerous kind of breaking change

Most deprecation posts treat a version sunset like a model retirement: there's a date, calls stop working, you migrate before it. Loud, scheduled, hard to miss.

Shopify version sunsets are the opposite. The whole point of fall-forward is that nothing breaks loudly — Shopify keeps answering you so your store doesn't go dark. The cost of that graceful behavior is that the moment your pinned version disappears, your client silently starts consuming a newer contract:

Fields deprecated-then-removed between 2025-07 and 2025-10 come back null or vanish from the payload.
Types that widened now return shapes your parsing code never expected.
Enum values, default behaviors, and pagination semantics shift to the newer version's rules.

None of it raises an exception on Shopify's side. The break happens inside your code, when it reads a field that moved and gets back something it wasn't written for. That's a margin report three weeks later, not a page at 3 a.m.

The only signal is a response header

Shopify does tell you which version actually served the request — in the X-Shopify-API-Version response header. After fall-forward, that header reads 2025-10 even though you asked for 2025-07.

That's the catch: the signal is on every response, but it's on the part of the response almost nobody inspects. Most clients read the JSON body and ignore the headers entirely. There is no Sunset header on the body, no error field, no deprecation block in the payload. If you're not diffing X-Shopify-API-Version against the version you sent, the fall-forward is invisible until behavior drifts.

Three concrete shifts a 2025-07 app inherits on July 16

This isn't hypothetical. Here are real 2025-07 → 2025-10 Admin API changes your pinned client silently adopts the instant it falls forward:

1. StoreCreditAccount.owner widened from one type to a union.
In 2025-07, a store credit account's owner is always a Customer. In 2025-10, the owner can be a Customer or a CompanyLocation (B2B). If your code reads owner assuming it's a customer — an inline fragment that only handles ... on Customer, or a parser that expects owner.firstName — B2B-owned accounts now resolve to a shape you don't handle. No error: just an empty or null branch where a value used to be. Store-credit balances silently stop reconciling for your B2B accounts.

2. ProductVariant.taxCode deprecated (Avalara AvaTax sunset).
As of 2025-10, ProductVariant.taxCode is deprecated as part of Shopify retiring the legacy AvaTax integration path. A 2025-07 client that reads taxCode to drive tax classification doesn't get an exception when it falls forward — it gets a field that's on its way out, with values that may no longer mean what they did. Tax logic keyed on that field drifts without a single failed request.

3. InventoryItem.variant → InventoryItem.variants (singular replaced by a connection).
The singular InventoryItem.variant field was deprecated in favor of an InventoryItem.variants connection. Code written for 2025-07 that walks inventoryItem.variant.id is reading a field on the deprecation path; once it's removed in a later version your fall-forward eventually reaches, that read returns null and your inventory sync quietly maps to nothing.

These three are just what's visible one quarter forward. The deeper problem: fall-forward doesn't move you one version — it moves you to whatever the oldest supported version happens to be on the day yours expires. The longer a pin sits unmaintained, the bigger the silent jump when it finally lapses.

What to actually do before July 16

Find every place you pin 2025-07 — X-Shopify-Api-Version headers, GraphQL/REST URL paths (/admin/api/2025-07/...), SDK config, webhook subscription versions, and any vendored client library's default. Webhooks have their own version setting; don't assume the API pin covers them.
Bump to a supported version and test against its schema, not just "does it still return 200." Move to 2025-10 or newer deliberately, read the release notes for the versions you're skipping, and fix the field-level changes on your schedule instead of inheriting them on Shopify's.
Assert on X-Shopify-API-Version in your client. Log it, and alarm if the served version ever differs from the version you requested. That one check turns a silent fall-forward into a loud, fixable signal — which is exactly the difference between finding this in CI and finding it in a chargeback.

The version sunset itself is well-documented. The trap is that "well-documented" and "fails loudly" are not the same thing. Shopify keeps your store running by quietly handing you a newer contract — and a 200 with the wrong shape is harder to catch than an honest error.

FlareCanary watches your API responses for exactly this: a field that changes type, a value that goes null, a response shape that drifts — including the silent version fall-forwards that pinned clients can't see. If the contract you depend on changes, you hear about it from us before your customers do.

Shopify retires API version 2025-07 on July 16 — pinned apps don't error, they silently fall forward to 2025-10

FlareCanary — Sat, 04 Jul 2026 05:00:37 +0000

On July 16, 2026 at 15:00 UTC, Shopify stops serving API version 2025-07. If your app, integration, or script still pins that version, here is the part that catches people off guard:

Your requests do not start failing.

Same endpoint. Same 200 OK. Different response shape.

Why this is the dangerous kind of breaking change

Most deprecation posts treat a version sunset like a model retirement: there's a date, calls stop working, you migrate before it. Loud, scheduled, hard to miss.

Fields deprecated-then-removed between 2025-07 and 2025-10 come back null or vanish from the payload.
Types that widened now return shapes your parsing code never expected.
Enum values, default behaviors, and pagination semantics shift to the newer version's rules.

The only signal is a response header

Three concrete shifts a 2025-07 app inherits on July 16

This isn't hypothetical. Here are real 2025-07 → 2025-10 Admin API changes your pinned client silently adopts the instant it falls forward:

What to actually do before July 16

Find every place you pin 2025-07 — X-Shopify-Api-Version headers, GraphQL/REST URL paths (/admin/api/2025-07/...), SDK config, webhook subscription versions, and any vendored client library's default. Webhooks have their own version setting; don't assume the API pin covers them.
Bump to a supported version and test against its schema, not just "does it still return 200." Move to 2025-10 or newer deliberately, read the release notes for the versions you're skipping, and fix the field-level changes on your schedule instead of inheriting them on Shopify's.
Assert on X-Shopify-API-Version in your client. Log it, and alarm if the served version ever differs from the version you requested. That one check turns a silent fall-forward into a loud, fixable signal — which is exactly the difference between finding this in CI and finding it in a chargeback.

The Google Merchant API migration has a silent mispricing trap (Content API shuts down Aug 18, 2026)

FlareCanary — Wed, 01 Jul 2026 05:01:04 +0000

If you push product data to Google Shopping through a custom integration — a feed builder, a PIM sync job, an internal Node/Python service that calls shoppingcontent.googleapis.com — you are on a clock. On August 18, 2026, Google permanently shuts down the Content API for Shopping. Every products.insert, every products.list, every inventory and price update against the v2.1 endpoints stops returning data and starts returning errors. There is no soft cutoff and no grace period after that date.

That part is loud. You'll know within minutes because the calls 404, the feed job alerts, and the catalog stops updating.

The part that bites quietly is the migration itself. The Merchant API is not a renamed Content API — it's an architectural rebuild with new resource shapes, a new identifier scheme, and a new money type. A migration done as a search-and-replace of the base URL will compile, authenticate, return 200, and silently write wrong data to your live catalog. Here are the three surfaces where that happens.

What actually changes

Surface	Content API for Shopping	Merchant API v1
Price amount	`price.value` — decimal string (`"15.99"`)	`price.amountMicros` — int64 (`15990000`)
Price currency	`price.currency`	`price.currencyCode`
Resource identity	`merchantId` + `productId` params	`name`: `accounts/{account}/products/{product}`
Product ID format	`channel:contentLanguage:feedLabel:offerId`	`contentLanguage~feedLabel~offerId`
ID delimiter	colon (`:`)	tilde (`~`)
`channel` in ID	present (`online` / `local`)	removed
OAuth scope	`https://www.googleapis.com/auth/content`	per-sub-API scopes

Four of those rows produce no error when you get them wrong. They produce wrong data that the API happily accepts.

1. The `amountMicros` trap silently misprices your entire catalog

This is the one to fix before you touch anything else.

In the Content API, a price is a decimal string with a sibling currency:

{ "price": { "value": "15.99", "currency": "USD" } }

In the Merchant API, the amount is an int64 count of micros, where one million micros equals one unit of currency:

{ "price": { "amountMicros": "15990000", "currencyCode": "USD" } }

So $15.99 is 15990000. The conversion is Math.round(parseFloat(value) * 1_000_000).

Now look at what a field-renaming migration does. The natural instinct, when a guide says "the amount field name changed from value to amountMicros", is to map the old field onto the new name:

// WRONG — renames the field, skips the unit conversion
product.price = {
  amountMicros: oldProduct.price.value,   // "15.99"
  currencyCode: oldProduct.price.currency
};

amountMicros is typed as int64, so the string "15.99" either gets coerced to 15 (truncated) or rejected depending on your client library — and 15 micros is $0.000015. Every product in the feed is now listed at effectively zero. Google accepts the write. The products stay "active." Your Shopping ads start serving at a price that doesn't match your landing page, which trips Google's price-mismatch checks days later — long after the deploy, with no stack trace pointing back at the migration.

The inverse mistake is just as quiet and more expensive: a team that knows about micros but applies the multiply twice (once in a mapping layer, once in a helper) ships 15990000000000 and lists a $16 product at $16 million. It won't sell, but it also won't error — it just silently stops converting.

There is no error path here. The only way to catch it is to diff the prices that landed in Merchant Center against the prices you intended to send.

2. The product ID delimiter flips from `:` to `~` — and drops `channel`

Content API product IDs are colon-delimited and lead with the channel:

online:en:US:SKU12345

Merchant API product IDs are tilde-delimited and have no channel segment:

en~US~SKU12345

Any code that builds or parses product IDs by string manipulation breaks silently:

// builds a malformed ID against the new API
const id = `${channel}:${lang}:${feedLabel}:${offerId}`;  // still using ':' and channel

// parsing an inbound Merchant API id by the old delimiter
const [channel, lang, feed, offer] = id.split(':');  // no ':' present → channel = whole string, rest undefined

The build path creates a product the API treats as a different offer than the one you meant to update — so instead of updating SKU12345 you insert a duplicate, and the original goes stale until it expires. The parse path silently mis-shards your records, and because offer comes back undefined, downstream lookups quietly miss.

The dropped channel segment is its own trap: in the old format online:... and local:... were distinct products. The Merchant API moves the online/local distinction out of the identifier entirely. If your reconciliation logic keyed products by the full colon-string, your online and local variants now collide on the same key.

3. `id` becomes `name`, and scripts reading `.id` get `undefined`

The Content API returned a flat id on every product. The Merchant API follows Google's resource-name convention — the unique identifier is name, formatted accounts/{account}/products/{product}. There is no top-level id field on the new product resource.

Every script that does product.id, every database column populated from response.id, every log line keyed on the product ID reads undefined after the cutover. Nothing throws — JavaScript hands you undefined, Python hands you a KeyError only if you used [] instead of .get(), and most feed code uses .get() defensively precisely so a missing field doesn't crash the run. So the field goes missing and the run keeps going, writing null IDs into your sync table.

What to grep for before you cut over

A focused audit on every service that talks to shoppingcontent.googleapis.com:

grep -rn "shoppingcontent.googleapis.com\|content/v2" . — every match is an endpoint that 404s on August 18, 2026.
Search your price-mapping layer for the move to amountMicros. Confirm there is exactly one * 1_000_000 (or * 1e6) on the path from your stored price to the request body — not zero, not two.
grep -rn "\.split(':')\|:\${" . near product-ID construction — colon-delimited ID logic that needs to become tilde-delimited and channel-free.
grep -rn "\.id\b" . in your product sync code — reads that now need to be .name, and any DB column fed from the old flat id.
Check your OAuth flow: the blanket auth/content scope is replaced by per-sub-API scopes. A token minted with only the old scope authorizes nothing on the new endpoints — and if you request a partial set, the calls that lack scope fail individually while the rest succeed, so a half-migrated scope grant looks like an intermittent outage rather than a config error.

The August 18 shutdown will get attention because it's a date on a calendar with a hard error attached. The migration that everyone does in the weeks before it is where the silent damage lives: a catalog that's fully "active" in Merchant Center, priced at $0.00 or $16 million, with duplicate SKUs and null IDs in your sync table — and not one line in the logs to say so.

FlareCanary monitors API responses for schema drift, silent removals, and behavior changes across upstream providers. If you sync product data to Google Shopping, Shopify, or anywhere else that ships breaking changes through migration guides, flarecanary.com catches the drift before your customers do.

HighLevel webhooks flip X-WH-Signature X-GHL-Signature on July 1, 2026 — three silent failure modes

FlareCanary — Sun, 28 Jun 2026 05:00:43 +0000

If you run a HighLevel integration — an n8n flow, a custom CRM bridge, a Make scenario, an internal Node service that listens for "Opportunity stage changed" — you have five weeks. On July 1, 2026, HighLevel deprecates the legacy X-WH-Signature (RSA) webhook signature header. After that date, every webhook is signed only with X-GHL-Signature using Ed25519.

From the HighLevel Webhook Integration Guide:

"The legacy header **X-WH-Signature* will be deprecated on July 1, 2026. After that date, webhooks will be signed only with X-GHL-Signature."*

The loud failure mode is the one everyone plans around. Your crypto.verify(...) call returns false, HighLevel sees a non-2xx from your endpoint, retries exhaust, the automation chain dies. You notice within an hour because the "new lead created" Slack notifier stops firing.

The failure modes worth grepping for now are the ones that don't surface as a 401. Three of them are common enough that they'll bite a meaningful chunk of the agency-built integrations running on HighLevel today.

What actually changes

Two things change simultaneously, and that's part of the trap:

Surface	Before Jul 1, 2026	After Jul 1, 2026
Signature header	`X-WH-Signature` (and `X-GHL-Signature` when present)	`X-GHL-Signature` only
Algorithm	RSA (SHA-256)	Ed25519
Public key	RSA public key endpoint	Ed25519 public key endpoint
Signature length	256 bytes (2048-bit RSA)	64 bytes
Verifier API (Node)	`crypto.createVerify('SHA256').update(body).verify(pubkey, sig)`	`crypto.verify(null, body, pubkey, sig)`

Two headers. Two algorithms. Two public keys. Two completely different verifier call shapes. A migration that's only a string replace from x-wh-signature to x-ghl-signature is silently broken on at least three of those rows.

1. The "skip if signature missing" branch becomes an open endpoint

This is the one to grep for first. Pattern:

app.post('/webhook/highlevel', (req, res) => {
  const sig = req.headers['x-wh-signature'];
  if (!sig) {
    // dev/test environments don't sign — skip verification
    return handlePayload(req.body, res);
  }
  if (!verifyRSA(req.body, sig, RSA_PUBLIC_KEY)) {
    return res.status(401).send('bad sig');
  }
  handlePayload(req.body, res);
});

That if (!sig) early-return exists in roughly every webhook handler I've seen in agency-shipped HighLevel code. It's there because somebody wanted to test locally without setting up signature verification, or because an older version of HighLevel really did skip signing on certain event types.

After July 1, 2026, every production webhook from HighLevel arrives with X-WH-Signature absent. The handler reads req.headers['x-wh-signature'], gets undefined, takes the skip-verify branch, and processes the payload. Your endpoint is now unauthenticated. Anyone who knows the URL can POST arbitrary JSON to it — fake "stage changed to Won" events that trigger your billing automation, fake "new contact" events that pollute your CRM.

The fix is one line — switch the header name and remove the skip-verify branch — but the open-endpoint window between now and the fix is exactly the kind of thing that doesn't show up in logs because the requests succeed.

2. RSA verifier passed an Ed25519 signature returns false (silently)

The migration guide says to use X-GHL-Signature and provides Ed25519 verification snippets. What it doesn't emphasize is that you cannot mix and match the verifier call with the new header. Code that updates the header but keeps the RSA verifier looks like this:

const sig = req.headers['x-ghl-signature'];           // updated
const verifier = crypto.createVerify('SHA256');       // not updated
verifier.update(JSON.stringify(req.body));
const ok = verifier.verify(RSA_PUBLIC_KEY, sig, 'base64');
// ok === false, because sig is a 64-byte Ed25519 sig
// and verifier is checking RSA-PSS / RSA-PKCS1

Two outcomes, both bad:

If your handler returns 401 on !ok, HighLevel retries with exponential backoff, gives up after the retry window, and the event is lost. No alert fires — HighLevel doesn't push failed-delivery dashboards into the agency dashboard, and most agency setups don't subscribe to delivery-failure events.
If your handler logs but still processes (an "alert on verify failure but proceed" pattern that some teams use during cutover), you're back to unauthenticated processing.

Either way, the symptom is the same the entire production stack from July 1 onward: deliveries look 200-green from HighLevel's side until you check the actual content delivered to your downstream system, and they look fine from your side until you realize the automations that should have fired never did.

A body-parser + RSA-verifier stack ported to Ed25519 also needs to handle the body differently — crypto.createVerify takes streamed updates; crypto.verify with null algorithm wants the full buffer. If your middleware already consumed the stream into a JSON object, you need the raw body preserved (bodyParser.raw or express.raw with a verify callback to stash req.rawBody).

3. Cached public keys work right up until the cutoff

A lot of agency setups load the HighLevel RSA public key into an environment variable at deploy time:

HIGHLEVEL_PUBKEY=-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0...

That key keeps working through June 30. On July 1, every signature is generated against a different keypair — the Ed25519 keypair. Your env var is now matched against signatures it has never seen and cannot validate by definition.

If you also took the time to switch verifiers (so issue #2 doesn't apply), you'll still fail because the public key is wrong. The verifier returns false. The signatures look "well-formed but invalid," which is indistinguishable in your logs from a real attack — and that's the worst place to be on July 1, because the on-call response to "all webhook signatures are suddenly invalid" is exactly the same as "we're being attacked": tighten the rate limit, page the security team, panic.

The fix is to fetch the Ed25519 public key from HighLevel's published JWKS-equivalent endpoint at runtime (with caching), not bake it into config. Even setting aside the July 1 cutoff, baking long-lived public keys into env vars is the pattern that makes every future key rotation a deploy event.

What to grep for this week

A 30-minute audit on every HighLevel webhook handler in your fleet:

grep -rn "x-wh-signature\|X-WH-Signature" . — every match is a code path that breaks on July 1.
grep -rn "createVerify" . near webhook handlers — RSA verifier calls that need to become crypto.verify(null, ...) Ed25519 calls.
grep -rn "if (!sig\|if (!signature\|sig === undefined" . — skip-verify branches that turn into open endpoints.
Search your env vars and secret stores for HIGHLEVEL_PUBKEY or similar — anything pinned to the RSA key needs to be re-pointed at the Ed25519 key, ideally fetched at runtime.
Confirm your webhook handler preserves the raw body for Ed25519 verification — body-parser's default JSON middleware consumes the stream and loses the byte-exact payload that the signature covers.

The cutoff is hard. HighLevel is not running a parallel-signed period where both headers ship — once X-WH-Signature is deprecated, it's gone. The thirty minutes spent grepping now is the difference between a quiet July 2 and explaining to a client why the "new lead → SMS notification" pipeline stopped firing five days into the month.

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

DEV Community: FlareCanary

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

The bonus that hits your bill, not your logs

What to actually do before August 26

Shopify retires API version 2025-07 on July 16 — pinned apps don't error, they silently fall forward to 2025-10

Why this is the dangerous kind of breaking change

The only signal is a response header

Three concrete shifts a 2025-07 app inherits on July 16

What to actually do before July 16

Shopify retires API version 2025-07 on July 16 — pinned apps don't error, they silently fall forward to 2025-10

Why this is the dangerous kind of breaking change

The only signal is a response header

Three concrete shifts a 2025-07 app inherits on July 16

What to actually do before July 16

The Google Merchant API migration has a silent mispricing trap (Content API shuts down Aug 18, 2026)

What actually changes

1. The amountMicros trap silently misprices your entire catalog

2. The product ID delimiter flips from : to ~ — and drops channel

3. id becomes name, and scripts reading .id get undefined

What to grep for before you cut over

HighLevel webhooks flip X-WH-Signature X-GHL-Signature on July 1, 2026 — three silent failure modes

What actually changes

1. The "skip if signature missing" branch becomes an open endpoint

2. RSA verifier passed an Ed25519 signature returns false (silently)

3. Cached public keys work right up until the cutoff

What to grep for this week

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

1. The `amountMicros` trap silently misprices your entire catalog

2. The product ID delimiter flips from `:` to `~` — and drops `channel`

3. `id` becomes `name`, and scripts reading `.id` get `undefined`