DEV Community: FlareCanary

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.

GitHub GraphQL drops Team.viewerSubscription + 17 audit-log entries on July 1 — and partial errors are the silent surface

FlareCanary — Mon, 22 Jun 2026 05:00:50 +0000

If you use the GitHub GraphQL API for team notification dashboards, audit-log exports, or any kind of organization compliance reporting, you have nine days when this lands. On July 1, 2026, GitHub deletes two fields from the Team type and the fields from seventeen audit-log entry types.

The fields are listed in GitHub's own breaking changes log:

Team.viewerSubscription — removed. Reason: "Team notifications subscriptions are being deprecated."
Team.viewerCanSubscribe — removed. Same reason.
All scalar fields on TeamAddMemberAuditEntry, TeamAddRepositoryAuditEntry, TeamChangeParentTeamAuditEntry, TeamRemoveMemberAuditEntry, TeamRemoveRepositoryAuditEntry, and twelve sibling repository/audit entry types — removed. Reason: "The GraphQL audit-log is deprecated. Please use the REST API instead."

The loud failure mode is the one most teams plan around. A query that selects a field GraphQL no longer recognizes fails server-side validation. You get a clear error, you regenerate types, you redeploy.

That's not the failure mode this article is about.

The failure mode worth thinking about is GraphQL's partial-error semantics — specifically, what happens to clients that don't treat the errors array as fatal.

What "removed" actually returns

When GitHub removes Team.viewerSubscription, queries that select it don't fail with a 4xx HTTP status. The HTTP layer returns 200 OK with a body like:

{
  "data": {
    "organization": {
      "team": {
        "name": "platform",
        "viewerSubscription": null
      }
    }
  },
  "errors": [
    {
      "message": "Field 'viewerSubscription' doesn't exist on type 'Team'",
      "locations": [{ "line": 5, "column": 9 }],
      "path": ["organization", "team", "viewerSubscription"]
    }
  ]
}

The exact shape depends on whether GitHub leaves the field validation-rejected (no data for the team at all) or treats it as a removed-but-tolerated field returning null. In practice, large-vendor GraphQL APIs deliberately bias toward the second shape during deprecation periods so that clients with partially-stale schemas don't go fully dark.

Either way, the client side of this is where it gets quietly bad.

1. The Apollo / urql / Relay "log and continue" pattern

Most production GraphQL client setups have an error link or middleware that logs errors[] to a telemetry sink and continues. The reasoning is sound — partial responses are useful, and a network-level failure should not be confused with a single-field schema mismatch.

The result is that a compliance dashboard that does:

const { data } = await client.query({ query: GET_TEAM_SUBS });
const subscribed = data.organization.team.viewerSubscription === 'SUBSCRIBED';

…silently flips subscribed to false on July 1. The Apollo error link logged the schema error to Sentry, where it joins the existing six hundred GraphQL errors nobody triages.

If the dashboard's job is to show "who on the platform team is muted on PR notifications," the dashboard reports "everybody is muted." If the job is to enforce "all leads must be subscribed to security-channel notifications," every lead's subscription check returns false and either the enforcement skips them (if the rule is "alert when subscribed == false") or alerts on everybody (if the rule is "alert when subscribed != true"). Most enforcement rules are written the second way, which means July 1 produces a wall of false-positive alerts and a tendency to mute the rule.

2. Persisted queries and codegen don't help

The standard answer to GraphQL drift — codegen with graphql-codegen or Relay's compiler, against an up-to-date schema — only helps if you're regenerating before July 1. The codegen does not know that a field that exists in your local schema today will be gone on a future date.

The deeper problem is persisted queries. A persisted-query setup hashes the query at build time and submits the hash at runtime. Server-side, GitHub validates against its live schema. The build that shipped last quarter persisted a query selecting Team.viewerSubscription. The build doesn't change between now and July 1. On July 1, the hashed query starts returning the partial-error shape above, and the client app never sees a code change to prompt regeneration.

If you have a persisted-query setup pointed at GitHub's GraphQL endpoint, every persisted hash that references the removed fields needs to be rebuilt and republished before July 1 — not after a deploy, after July 1.

3. The audit-log surface is a different problem

GitHub is not just removing two Team fields. It is deprecating the entire GraphQL audit-log subsystem and pointing users at the REST endpoint instead.

The seventeen entry types that get gutted on July 1 cover the common team and repository administrative actions:

TeamAddMemberAuditEntry, TeamRemoveMemberAuditEntry
TeamAddRepositoryAuditEntry, TeamRemoveRepositoryAuditEntry
TeamChangeParentTeamAuditEntry
The repository-side equivalents for visibility, archive, transfer, and access changes

A typical security pipeline does something like:

query Audit($org: String!, $cursor: String) {
  organization(login: $org) {
    auditLog(first: 100, after: $cursor) {
      edges {
        node {
          __typename
          ... on TeamAddMemberAuditEntry {
            createdAt
            actorLogin
            team { name }
            user { login }
          }
        }
      }
      pageInfo { endCursor, hasNextPage }
    }
  }
}

After July 1, the node still has __typename, but every field inside the ... on TeamAddMemberAuditEntry fragment returns null or schema-errors out. The pipeline still iterates pages, still increments its "events processed" counter, still writes rows to the warehouse. The warehouse rows are tombstones — typename and timestamps if you're lucky, nothing if you're not.

The REST migration is non-trivial. The REST audit-log API uses cursor pagination via a phrase= query parameter rather than GraphQL connection cursors, returns flattened event objects rather than nested team { } / user { } shapes, and has different field names (actor vs actorLogin, team as a string vs an object). It's a rewrite, not a remap.

4. The Insights/Analytics integrations don't surface this

The third-party analytics tools layered on top of GitHub's GraphQL API — lowdefy, Sourcegraph batch changes that read audit data, GitHub-Actions-based compliance bots — typically use the GitHub Apps OAuth flow and inherit GraphQL access. None of them publish a "we use these fields" manifest. The only way to know whether one of them will break is to query its error logs after July 1, or to read its source.

The default posture is to assume any integration that touches Teams or audit data is affected unless its changelog explicitly says otherwise. The vendors with a published changelog (Octokit, gh CLI) will have already shipped a fix. The bespoke "we wrote a small dashboard for our compliance team" surface is where the drift lands.

How to find what's affected before July 1

Three commands worth running this week.

Grep your queries: grep -rE 'viewerSubscription|viewerCanSubscribe|TeamAddMemberAuditEntry|TeamRemoveMemberAuditEntry|TeamAddRepositoryAuditEntry|TeamRemoveRepositoryAuditEntry|TeamChangeParentTeamAuditEntry' src/ queries/ catches direct references. Add the twelve other audit-entry types if your reporting covers repository visibility/transfer changes. GitHub's breaking-changes page has the full list.

Inventory persisted queries: any GraphQL setup using Apollo's Automatic Persisted Queries or Relay's --persist-output flag has a JSON map of query hashes to query bodies. grep that map for the field names. The hashes themselves are content-addressed, so a hash referencing viewerSubscription won't change until the query body changes.

Replay last week's audit-log queries with the deprecation banner: GitHub returns an X-GitHub-Media-Type header and includes deprecation warnings in the errors[] array for fields scheduled for removal. If your client logs GraphQL errors anywhere — Sentry, Datadog, CloudWatch — filter for the message "Team notifications subscriptions are being deprecated" or "The GraphQL audit-log is deprecated" over the past 30 days. Anything that fires today will silently fail on July 1.

The published deprecation table is here: GitHub GraphQL API Breaking changes. The REST replacement for the audit log is documented under REST API endpoints for audit log.

The pattern this lands in is the one GraphQL APIs hit most often during big deprecation cycles. The schema validator doesn't care about wall-clock dates — until July 1, the field exists and queries succeed. On July 1, the field returns null with a partial error that most production clients are configured to swallow. The dashboards stop showing data, the compliance enforcers stop enforcing, and the alarms don't fire because the request never failed.

FlareCanary watches the response shapes of API endpoints you depend on and tells you when a field that used to be present starts coming back null. GraphQL partial-error responses are exactly the kind of drift that survives an Apollo error link and lands in a dashboard tile that's quietly wrong. flarecanary.com

Azure SQL Database 2014-04-01 APIs retire June 30 — your tools auto-upgrade, the response shapes change

FlareCanary — Fri, 19 Jun 2026 05:00:59 +0000

If you manage Azure SQL Database resources through ARM templates, the Azure SQL REST API, the Az.Sql PowerShell module on an old version, the Azure CLI shipped with an older deployment image, or any third-party tooling that wraps the Azure Resource Manager surface, you have eight days of runway when this lands. Microsoft is retiring the entire 2014-04-01 API version of the Azure SQL Database control plane on June 30, 2026.

The original retirement date was October 31, 2025. Microsoft extended it by eight months "based on customer feedback," which means a lot of estate still has 2014-04-01 baked into it.

The loud failure mode is straightforward: ARM templates that pin "apiVersion": "2014-04-01" start failing at deploy time. You get a clear error, you bump the version, you redeploy. That's not the failure mode this article is about.

The interesting failure mode is what happens when your tooling auto-upgrades to the newer stable version (2021-11-01) without you noticing. Microsoft itself describes this as the benign path:

The retirement of the 2014 API will not affect Azure PaaS or SaaS products that are kept up to date, as the API will be updated automatically.

What the announcement does not spell out is that the upgrade from 2014-04-01 to 2021-11-01 is not a transparent version bump. It's seven years of API redesigns crammed into a single rename. Endpoints disappear without a replacement. Resource types are renamed. Audit policies move from one storage backend to another. The most common automation patterns built against 2014-04-01 will continue to "succeed" against 2021-11-01 — they just stop reading the thing they think they're reading.

The mappings are spelled out in Microsoft's own retirement notice. Here are the five silent surfaces that fall out of the differences between the two versions, with what each one does to the kind of script you probably have running.

1. Eight endpoint groups have no replacement at all

The retirement table lists thirty-odd 2014-04-01 endpoint groups mapped to their 2021-11-01 successors. Eight of them have a footnote that reads: "APIs marked as deprecated with no newer/stable versions, are permanently discontinued from the service."

Database Connection Policies
Elastic Pool Activities
Elastic Pool Database Activities
Queries
Query Statistics
Query Texts
Recommended Elastic Pools
Service Tier Advisors

If you have a script that polls /queries, /queryStatistics, or /queryTexts against the 2014-04-01 API to surface query performance data outside of the portal — the SDK or tooling layer above you cannot transparently retry against 2021-11-01, because the endpoint isn't there. Whatever your tooling does when an endpoint disappears, that's what it does on July 1. Most SDKs raise. Most schedulers log the raise and continue. The dashboard the script was feeding goes flat. Nobody notices because the job ran "successfully" — it raised, logged, and exited zero, exactly as it was written to.

Recommended Elastic Pools is the sneakiest of the eight, because the recommendation it surfaced was advisory. If your pool-sizing job was using it to decide whether to scale or merge pools, the job continues to make sizing decisions — based on an empty recommendation set. Everything looks "stable" because there's nothing to act on.

2. Table-based auditing silently maps to blob-based auditing

Database Table Auditing Policies (2014-04-01) maps to Database Blob Auditing Policies (2021-11-01). Same for the server-level variant.

These are not the same audit subsystem. Table auditing wrote audit rows to Azure Table Storage in the same storage account. Blob auditing writes audit logs to Blob Storage with a different filename convention, different retention semantics, and a different schema. The legacy table-auditing destination has been deprecated for years, but the API surface persisted in 2014-04-01 as a way to enable, disable, and read the policy.

Tooling that reads "is auditing enabled" against the new endpoint gets a different answer for the same logical question. Concretely:

A compliance script that did GET .../auditingPolicies/Default?api-version=2014-04-01 and asserted on properties.auditingState == "Enabled" is now hitting .../auditingSettings/default?api-version=2021-11-01. The property layout is different. If the tool was tolerant — e.g. checked if (auditing.properties.state == 'Enabled') against a value that doesn't appear in the new shape — it returns undefined, the check evaluates falsy, and you report "auditing not enabled" for databases that very much have blob auditing enabled.
A provisioner that wrote table-auditing config via 2014-04-01 (PUT .../auditingPolicies/Default) is now writing blob-auditing config (PUT .../auditingSettings/default). The request shape is similar enough that a JSON template with the wrong keys can still 200, but the resulting policy is partially configured, pointed at the wrong storage container, or missing the retention period. Your IaC layer reports a successful apply.

Either way, the audit you thought you had is not the audit you have, and the surface that would tell you is the surface that just changed.

3. Threat Detection Policies were renamed to Advanced Threat Protection Settings

Database Threat Detection Policies (2014-04-01) maps to Database Advanced Threat Protection Settings (2021-11-01).

The 2014 endpoint exposed properties like state, emailAddresses, emailAccountAdmins, and disabledAlerts. The 2021 endpoint replaces the alert/email config with a simpler state toggle and pushes the alert configuration into Defender for Cloud at the subscription tier.

A security posture script that reads the old endpoint's disabledAlerts array — say, to ensure SQL injection alerts haven't been muted — has nothing analogous to read on the new endpoint. The migration broke the very signal the script existed to check. The script still runs. It still produces a report. The report just doesn't include the field it was built around, and depending on how it was written, either renders the column empty or silently treats "no muted alerts" as the answer.

4. Disaster Recovery Configurations became Failover Groups

Disaster Recovery Configurations (2014-04-01) → Failover Groups (2021-11-01).

This isn't a rename for cosmetic reasons. Failover Groups are the modern, multi-database DR primitive. Disaster Recovery Configurations were a per-database active geo-replication wrapper with a different lifecycle, different role semantics ("Primary"/"Secondary"/"Source"/"Target" depending on which way you looked at it), and a different relationship to the underlying replicas.

If you have a DR posture monitor that does something like:

for each server, list disasterRecoveryConfiguration children, count where role == "Primary," compare against expected_count, alert if delta

…you are reading an empty list on the new endpoint, because nothing creates DR configurations on a 2021-vintage server. Everything created in the last few years is a failover group, and failover groups live at a different URL with a different resource type. The script returns zero. The script's invariant is "zero is bad." But the script doesn't fire, because the script's invariant was actually "zero compared to last week's count is bad" — and last week's count was also zero, since the script has been wrong since the auto-upgrade happened. It looks healthy by virtue of being uniformly broken.

The unambiguous version of this problem is the IaC tool that, on next plan, decides to delete the disasterRecoveryConfiguration child because "it's not in the template anymore." It isn't in the template anymore because the template now references failoverGroups. The DR resource itself doesn't get deleted (the underlying replica's data lives elsewhere), but the management plane object pointing at it does, and reattaching from scratch is the kind of thing you find out about during a real outage.

5. Restorable Dropped Databases now points at managed instances

The most quietly dangerous entry in the migration table:

Restorable Dropped Databases (2014-04-01) → Restorable Dropped Managed Databases (2021-11-01).

Read that carefully. The replacement is the managed instance variant, not the logical-database variant. If you had a self-service "undelete a dropped database" tool that called the 2014 endpoint against your standard Azure SQL Database (not managed instance), and that tool got auto-upgraded by an SDK bump or a wrapper-library bump, it is now asking the API for restorable dropped managed databases. For a standard Azure SQL server, the list is empty.

The runtime behavior:

User drops a database, panics, opens the self-service restore tool.
The tool calls the upgraded endpoint, asks for restorable dropped databases on the managed-instance resource path.
The managed-instance resource doesn't exist on a standard logical server, or the list returns empty for the correct managed instance.
The tool reports "no restorable databases found."
The user assumes the drop was permanent and moves on.

The actual restore endpoint for a standard logical server is restorableDroppedDatabases under Microsoft.Sql/servers/restorableDroppedDatabases — which still exists in 2021-11-01, just not in this row of the migration table. Microsoft's own retirement-mapping doc only lists the managed-instance variant under the 2014 row, because the standard variant has been promoted to the server-scoped resource model. If your tool didn't notice the model shift, the migration documentation actively misleads.

How to find what's affected before June 30

Three commands to run in your environment this week.

Inventory ARM templates and Bicep: grep -rE '"apiVersion"\s*:\s*"2014-04-01"' templates/ infra/ (or the moral equivalent in Bicep) catches the loud cases. Use the Azure Resource Graph to see deployed resources by API version if you have it enabled.

Inventory SDK and CLI versions: the Azure SQL SDKs (Azure.ResourceManager.Sql in .NET, azure-mgmt-sql in Python) shipped major versions between the 2014 and 2021 API generations. A pip list | grep azure-mgmt-sql or its NuGet/npm equivalent will show whether you're on a version that pins old APIs. The Az.Sql PowerShell module has the same property — Get-Module Az.Sql | Format-List Version tells you whether your runners are still on a pre-5.x build.

Inventory custom REST callers: if anything in your environment talks directly to management.azure.com/subscriptions/.../providers/Microsoft.Sql/...?api-version=2014-04-01, that's the highest-confidence place to look first. Network egress logs, an az monitor activity-log list over the past 30 days, or just a grep across your repos for Microsoft.Sql/ paths will surface them.

For each find, the migration is mechanical when the endpoint maps cleanly (most databases, servers, firewallRules calls), and a real design decision when it lands on one of the five surfaces above. Make the design decision now while you have a fallback period, not after July 1.

The published retirement notice is here: Azure SQL Database REST API 2014-04-01 Retirement Notice. The full 2021-11-01 surface is documented in the same place — read it side-by-side with whatever your tooling is currently using.

FlareCanary watches the response shapes of API endpoints you depend on and tells you when they drift. The Azure SQL control plane is exactly the kind of surface where renamed properties and silently-substituted endpoints land in production before a deployment-time error ever fires. flarecanary.com

SharePoint silently retired the EnableAzureADB2BIntegration setting in May — and your old guest links break in July

FlareCanary — Wed, 17 Jun 2026 04:03:10 +0000

If you administer a SharePoint Online tenant, the EnableAzureADB2BIntegration setting is the thing you used to flip to choose between the legacy SharePoint One-Time Passcode (SPO OTP) experience for external guests and the modern Entra B2B Invitation Manager flow. The cmdlet has been around for years. Compliance scripts read it. Tenant baselines assert on it. Some org policies still document it as the toggle.

Starting May 2026, that setting no longer does anything.

Microsoft is rolling Entra B2B integration out to every SharePoint tenant automatically. The rollout windows are not announced per-tenant — "tenants are selected automatically by our rollout systems. You cannot choose a specific date." Once your tenant flips, Set-SPOTenant -EnableAzureADB2BIntegration $false becomes a no-op. The cmdlet returns without error. The next Get-SPOTenant may still show a value. External sharing has already moved to B2B regardless.

And in July 2026, the other shoe drops. Every external guest who was authenticated through SPO OTP — and never got upgraded to a real Entra B2B guest account in your directory — silently loses access to every link you ever shared with them. The link doesn't 404. The user gets a flat "This organization updated its guest access settings" page. Your audit log says the sharing event was successful months ago. Your sharing reports still list the file as shared. The recipient just can't open it anymore.

That's two stacked silent surfaces with a hard July cliff in between. Here's what each one actually does, and how to find what's affected before the cliff.

1. The setting is gone but the cmdlet still answers

Read the Microsoft docs carefully:

Starting May 2026, Microsoft enables SharePoint and OneDrive integration with Microsoft Entra B2B for all tenants, regardless of the tenant's setting for EnableAzureADB2BIntegration. Once rolled out, this setting has no effect on sharing behavior, and the ability to disable the integration is removed.

The phrase that gets glossed over is "regardless of the tenant's setting." The setting field is not being deleted. The PowerShell cmdlet is not being removed. The property still exists, still returns a value, and Set-SPOTenant -EnableAzureADB2BIntegration $false still parses and executes. It just no longer controls the behavior it used to control.

This is the textbook silent surface: an API endpoint that continues to accept the same request and return the same response, but the underlying behavior changed. Anything in your environment that reads the setting to infer sharing behavior is now wrong.

Concrete examples of what breaks in the dark:

Compliance baselines. If your CIS / NIST / internal policy baseline asserts that EnableAzureADB2BIntegration is $true, that check still passes after rollout, but it's measuring nothing — the answer is True for everyone whether they configured it or not. If your baseline asserts it's $false (some orgs deliberately kept legacy OTP), the check passes and the assertion is a lie. External sharing is using B2B regardless.
Tenant-state monitors. Scripts that snapshot tenant settings nightly and diff against a known-good baseline see no diff. The setting didn't change. The world around the setting did.
Pre-rollout audits. If you ran a "we'll handle this when we're ready" plan and used the setting as your gate, you can't gate on it anymore. The rollout flips your tenant when the rollout flips your tenant.
Idempotent provisioning. Terraform, Azure Bicep, DSC, or whatever provisions tenant settings continues to "successfully" set the value. The plan and apply both succeed. The value the next plan sees is unchanged. Nothing in the tooling reports that you provisioned a setting that does nothing.

If you've ever depended on this setting to reason about whether sharing goes through OTP or B2B, you can't anymore. The only reliable source of truth after May is "the rollout has happened to this tenant" — which Microsoft does not surface as a single boolean. You have to look at the actual share events.

2. Auto-rollout means you can't time your migration

When a Microsoft 365 change has an admin-controlled flag, you can plan: turn it on in a test tenant, run validation, schedule the production flip. When the change is forced on by central rollout, you lose that.

The FAQ is explicit:

Can I choose when this integration is enabled for my tenant? No. Tenants are selected automatically by our rollout systems. You cannot choose a specific date.

And:

Can I opt out of this change? No. This change applies to all tenants and aligns with Microsoft's strategy of using one centralized identity provider across all Microsoft 365 applications.

So between May and the end of the rollout, your tenant flips one day with no notice on your end. The day it flips, every new external share creates an Entra B2B guest in your directory instead of an SPO OTP entry. Existing OTP guests are not auto-upgraded. The two populations now coexist in your tenant.

That coexistence is the trap. Until July, both populations can still open files. B2B guests authenticate via Entra; OTP guests authenticate via the SPO OTP code flow. Everything looks fine. Sharing reports still light up green. Your helpdesk doesn't see tickets, because nobody's actually broken yet.

So you assume the rollout was a non-event. You move on. Then in July, the OTP cohort starts hitting access-denied, and you have no list of who they are because nobody told you the cohort even existed.

The only way to get ahead of this is to enumerate, before July, every external user who is authenticated through OTP and does not yet have a corresponding B2B guest account in your directory. Microsoft surfaces this at site level via the external sharing report — pull the report, look at the User E-mail column, cross-reference against Entra B2B guests. The mismatch is your at-risk cohort. The tenant-level admin center does not give you this list.

3. July's access-denied is silent from the admin side

Here's the precise behavior Microsoft documents:

Do my guest users retain access to files shared before the integration? Yes, but only if they have a Microsoft Entra B2B guest account in your directory. If they do not have a Microsoft Entra B2B guest account, external collaborators see access denied starting July 2026.

What the external user sees, after rollout: a page that says "This organization updated its guest access settings." Not "link expired." Not "file not found." Not 404. A specific, generic-sounding error that most users will read as "the link broke" and either re-ping the sender or quietly give up.

What the admin sees: nothing, until someone files a ticket. The audit log entry for the original share is still there, intact, months old. The file is still shared — Get-SPOUser still lists the guest. The sharing report still shows the link. The only thing different is that the guest's authentication path no longer works because the OTP authentication backend isn't where SharePoint looks anymore.

This is the asymmetric failure that makes it hard to test: the share-side state stays valid, the auth-side state stops being honored. Anything you build to monitor "is this share still active" by inspecting share state returns "yes" all the way through the cliff.

The Microsoft-recommended fix is to either pre-create B2B guest accounts for at-risk users (so July is uneventful), or rely on a workflow where an internal user reshares one file — that creates the B2B guest, which then retroactively grants access to every link previously shared with that email. The second option works but requires a user to notice access is broken and request a reshare, which means the broken-access state is part of the user experience.

If your SharePoint estate has guests from any tenant provisioned before June 2023, assume you have OTP-only guests. Tenants provisioned after June 2023 have B2B integration on by default and aren't impacted by this specific population, but they still get the setting-no-op behavior from section 1.

4. Anyone-links and Anonymous-links are unaffected — which matters because people will assume otherwise

One thing that's explicitly not changing is anonymous/Anyone links:

Is there any impact on Anyone/Anonymous links? No. SPO OTP retirement and use of Entra B2B for external sharing does not impact Anyone/Anonymous links.

Surface this in your internal comms. The natural reaction to "external sharing is changing in July" is to assume every external link is at risk and to either re-share everything or panic-disable external sharing. Anonymous links never used OTP — they use the link's own access controls — so they sail through this entirely.

The cohort that's at risk is the narrow one: links shared with a specific person's email address, where that recipient authenticated via SPO OTP, and where that recipient has not yet been promoted to a B2B guest in your directory.

5. Audit-log event types: the sharing event itself looks different post-rollout

The other piece nobody is talking about is that the audit-log shape of an external share event changes once your tenant is on Entra B2B integration. SPO OTP shares emitted SharePoint-namespaced events with the OTP authentication flow. Entra B2B Invitation Manager emits Microsoft Entra audit events (Add user, Invite external user) followed by the SharePoint share event.

If you have SIEM filters keyed on the SPO OTP event signature — for example, alerting on "external share to a high-risk domain via OTP" — those filters quietly stop matching the new shares. The new shares still happen; they just no longer trip your old query. Same kind of silent surface as the setting in section 1: the data is there, your filter just doesn't see it.

For Microsoft Sentinel, Defender, Purview Audit, or any third-party SIEM ingesting Microsoft 365 audit data, audit the queries that depend on share-event shape and make sure they also match the Entra B2B Invitation Manager flow. Microsoft Graph Data Connect (MGDC) is the higher-fidelity source if you need both populations.

Timeline summary

End of April 2026 — Last window to manually run Set-SPOTenant -EnableAzureADB2BIntegration $true on your own schedule and validate in a controlled way.
May 2026 — Auto-rollout begins. Tenants flip on Microsoft's schedule, not yours. The setting becomes a no-op. New external shares use Entra B2B.
July 2026 — OTP-only guests start seeing access-denied on previously shared links. The hard cliff.
August 31, 2026 — Full SPO OTP retirement complete.

What this looks like on a monitoring dashboard

The whole point of writing this up is that none of these surfaces are visible in a normal "is my API working" check. The PowerShell endpoint answers. The audit log writes events. The sharing report renders. The compliance baseline reports green. The user sees a generic error page. The admin sees nothing.

This is the same shape as the schema-drift incidents we've been tracking elsewhere — Twilio dropping transit_callerid, Stripe flipping unit_amount_decimal from string to Decimal, GitHub silently removing payload.commits from PushEvent: the endpoint stays alive, the response stays parseable, and the meaning of what it returns has changed under the integration. The tooling that doesn't notice is the tooling that asserts on shape, not on semantics.

For SharePoint specifically, the assertions that actually catch this are:

Setting + behavior coherence: read EnableAzureADB2BIntegration and also sample a recent external share event; assert the auth path in the event matches the setting. After rollout, the setting can claim $false and the share will be via B2B — that mismatch is your signal that the rollout flipped you.
Guest population audit: weekly diff of "external email addresses with active shares" vs. "Entra B2B guest accounts." Any email in the first set not in the second is at risk in July.
Share-event shape monitoring: alert on a change in the dominant audit event type for external shares — when SPO-OTP-shaped events drop to zero and B2B-Invitation-Manager-shaped events become the norm, your tenant has been flipped, and your SIEM filters need re-tuning.

If you maintain any of those today, this rollout is manageable. If you don't, July is going to be a helpdesk surprise rather than a planned change.

References

Microsoft Entra B2B integration for SharePoint & OneDrive — the canonical doc, updated May 2026.
FAQ: Improvements to external sharing in OneDrive and SharePoint — the source of the "no opt-out, no scheduling, July access-denied" specifics.
Sharing reports in SharePoint — site-level external sharing report, the only place to enumerate OTP-only guests.

Shopify Scripts stop executing June 30 — and the failure is silent: checkout completes at full price, no error

FlareCanary — Sat, 13 Jun 2026 05:00:46 +0000

On June 30, 2026, every Shopify Script stops executing. This is the final deadline — it has already been pushed twice (August 2024 → August 2025 → June 2026), and Shopify has stated this one is firm. Editing and publishing new Scripts was already turned off on April 15, 2026.

Most "deadline" posts about this frame it as a migration-project problem: audit your Scripts, rebuild them as Functions, ship before the date. That's true. But it buries the part that actually bites.

Here is the part that makes this dangerous.

When a model gets retired — Imagen, an OpenAI snapshot, a Grok slug — the failure is loud. The call returns an error, your pipeline throws, someone gets paged. Loud failures get fixed.

A Shopify Script ceasing to execute is not loud. There is no Script to call and fail. The checkout simply runs without it. The customer reaches the thank-you page. Shopify returns a completed order. Your logs show a successful checkout. Everything is 200 OK.

The only thing missing is the logic the Script was doing — and nothing in the system says so.

1. The cutoff itself fails silent — checkout just stops applying your rules

Think about what Shopify Scripts actually do. They are Ruby scripts that run inside checkout to modify three things:

Line item discounts — "20% off for wholesale-tagged customers," "buy 3 get 1 free," tiered volume pricing.
Shipping rates — hide express shipping for PO boxes, rename rates, discount freight for VIPs.
Payment methods — hide credit card for high-risk carts, hide cash-on-delivery above a cart threshold.

On July 1, none of that runs. And checkout does not error — it has nothing to error about. It just renders the cart without the Script's modifications:

The wholesale customer who should see 20% off pays full price. No error. Order completes.
The express shipping you hid for PO boxes shows up again, gets selected, and now you owe a carrier for a route you can't service.
The payment method you hid on high-risk carts comes back, and the fraud you were screening out walks straight through.

Every one of these is a 200, a completed order, a happy-looking checkout funnel. You will not find this in an error dashboard, because there is no error. You find it in a margin report three weeks later, or in a customer support ticket, or in a chargeback.

That is the worst kind of failure: revenue logic that silently switches off while the system around it reports success. If you have a Script live today, June 30 is not a migration deadline — it is the day a piece of your checkout silently changes behavior.

2. A deployed Function does nothing until a discount node exists in the Admin

So you migrate. You rebuild the Script as a Shopify Function — WebAssembly, the official replacement. You write the logic, npm run deploy, the Function shows up in your Partner Dashboard. Done?

No. And this is the trap that catches teams who think a Function is a drop-in for a Script.

A Script ran the moment it was saved in the Script Editor. A Function does not run just because it is deployed. A discount Function only executes when a discount is attached to it — a DiscountAutomaticApp or DiscountCodeApp node, created in the Shopify Admin (or via the discountAutomaticAppCreate GraphQL mutation) and set to Active.

Deploy the Function, forget to create the discount node — or create it and leave it in Draft, or with a future start date — and the result is exactly the same as section 1: checkout runs, completes, charges full price. The Function exists. It is just never invoked. There is no error, because nothing called anything.

This is the half-migration failure mode. The Script is gone, the Function is "deployed," the dashboard looks green, and discounts are silently off. Confirm the discount node exists, is Active, and has a start date in the past. The Function is only half the wiring.

3. The input query: a field you forget to request comes back `null`

Scripts and Functions receive cart data completely differently, and this is where logic silently no-ops.

A Ruby Script got the whole cart handed to it — Input.cart.line_items, customer, tags, everything in scope. A Function gets only what its input query explicitly asks for. The input query is a GraphQL document you write; Shopify runs it and passes the result to your Function as JSON.

The rule that bites: a field you do not request in the input query is null in your Function. Not an error. Not a warning. null.

So you migrate a Script that gives a discount to customers tagged wholesale. In the Function you write the discount logic correctly — but your input query doesn't request cart.buyerIdentity.customer.hasTags (or the metafield, or the product tags, or the line-item sellingPlanAllocation, whatever your rule keys on). The Function runs. It reads the customer tags. They are null. The null doesn't match wholesale. It returns "no discount."

200 OK. Order completes. Full price. The Function ran successfully — it just made its decision on data that was silently absent. Every conditional discount you migrate has this exposure: the condition you branch on must be in the input query, or your branch quietly takes the wrong path.

When you migrate a Script, write down every field its logic reads, and check each one is in the input query. The dangerous field is the one your logic depends on and your query forgot.

4. `combinesWith` and discount strategy: a Script that always applied may now lose

A Script applied its discount unconditionally — the Ruby ran, the discount landed, end of story. A Function discount does not get that guarantee. It lives under two layers of Shopify-side arbitration that Scripts never had:

combinesWith is configured on the discount node, not in your Function code. It declares whether this discount can stack with order / product / shipping discounts. If you had a Script that gave both a line-item discount and an order-level discount, and you rebuild it as two Functions whose discount nodes are not configured to combine with each other — only one applies. The other is silently dropped. Your Function code is correct; the node configuration is the bug.
discountApplicationStrategy decides which discount wins per line item — FIRST, MAXIMUM, or ALL. A Script that always stacked its discount on top may become a Function that only applies when it is the best discount on that line. On a cart that already has a better discount, yours silently does not apply.

None of this errors. The checkout completes, an order is created, a discount may even show — just not the combination your Script produced. If your Script's behavior depended on stacking, your Function's behavior now depends on the node config and the strategy matching it. Verify both against a real multi-discount cart.

One more: if you are following an older tutorial, make sure you build against the unified Discount Function API, not the legacy split Order Discount / Product Discount Function APIs — those are themselves deprecated. Migrating onto an already-deprecated target is a migration you get to do twice.

What to actually do

Inventory your Scripts now. In the Shopify admin, open the Script Editor (Apps → Script Editor) and the Shopify Scripts customizations report. List every live Script and exactly what it modifies — discount, shipping, or payment.
For each Script, decide the replacement explicitly. A Shopify Function, a public app from the App Store, or consciously dropping it. The danger is the Script nobody owns — it just stops on June 30 and no one is watching the metric it moved.
Treat "deployed" and "live" as two different states. For every discount Function: confirm the discount node exists, is Active, has a past start date, and has combinesWith set to match the stacking your Script did.
Diff the input query against the Script's logic. Every field the Ruby read must be in the Function's input query. Anything missing is null, and null silently changes which branch your discount logic takes.
Test on real carts before June 30, not after. Build the carts your Scripts actually targeted — the wholesale customer, the PO box address, the high-risk payment cart, the multi-discount cart — and run a full checkout. Confirm the final price, the shipping options, and the payment methods match what the Script produced. This is the only check that catches a silent no-op.
Watch the margin metric across the cutover. Average discount per order, blended shipping cost, payment-method mix. If a Script silently stops, these move before any human notices. A dashboard line is cheaper than a chargeback.

The model retirements get headlines because they fail loud. Shopify Scripts will fail quiet — checkout will keep completing, orders will keep flowing, and the only signal that something broke is a number in a report moving the wrong way. Plan for the quiet failure.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — deprecations, response-shape changes, and silently-dropped behavior — and surfaces them before they reach production. Free tier monitors 5 endpoints.

Google retires every Imagen model on June 24 — and the Gemini image migration fails silently in 4 places

FlareCanary — Wed, 10 Jun 2026 05:00:36 +0000

On June 24, 2026, Google shuts down every remaining Imagen model on the Gemini API:

imagen-4.0-generate-001
imagen-4.0-ultra-generate-001
imagen-4.0-fast-generate-001

(imagen-3.0-generate-002 already went dark on November 10, 2025 — if you somehow survived that one, you were already on borrowed time.)

The recommended replacement is gemini-2.5-flash-image — the model Google markets as "Nano Banana" — or gemini-3-pro-image-preview.

Here is the part that makes this dangerous. The retirement itself is loud: after June 24, a request to imagen-4.0-generate-001 returns an error, your pipeline throws, someone gets paged. That's fine. Loud failures get fixed.

The migration is not loud. Imagen and Gemini's image generation are not the same API with a different model string — they are two different request shapes, two different endpoints, and two different parameter vocabularies. And Gemini's image endpoint will happily accept a request full of Imagen-era parameters, ignore the ones it doesn't recognize, and return 200 OK with an image. Not the image you asked for. An image.

That's the trap. Teams will migrate under deadline pressure, see images come back, see green status codes, and ship. The defects land downstream, weeks later, with no error attached.

Here's the silent-fail surface.

1. The endpoint and response shape changed — and a half-migrated parser fails quiet

Imagen runs on the :predict endpoint. You send instances and parameters, and you get back:

{ "predictions": [ { "bytesBase64Encoded": "...", "mimeType": "image/png" } ] }

Gemini image generation runs on :generateContent. You send contents with parts, and the image comes back at:

{ "candidates": [ { "content": { "parts": [ { "inlineData": { "data": "...", "mimeType": "image/png" } } ] } } ] }

If you point your code at the new model but keep calling :predict, you get a loud error — good. But the failure that actually ships is the half migration: you move to :generateContent, and a downstream helper still reaches for response.predictions[0].bytesBase64Encoded.

That path doesn't exist on a Gemini response. In JavaScript it evaluates to undefined. In Python it's a KeyError only if you index hard — and most image-handling code doesn't, because it was written defensively:

img = resp.get("predictions", [{}])[0].get("bytesBase64Encoded")
if img:
    save(img)

predictions is missing, so img is None, so the if is skipped. No exception. No image written. 200 OK logged. The function returns cleanly. You find out when someone notices the asset bucket stopped filling — and by then you can't tell which day it started.

2. `sampleCount` is gone — your batch silently collapses to one image per call

This is the sharpest one.

Imagen's :predict request takes a sampleCount parameter: ask for up to 4 images in a single call (imagen-4.0-generate-001), or 1 at a time on the Ultra tier. Plenty of pipelines lean on this — generate 4 candidates per prompt, score them, keep the best. The sampleCount: 4 is load-bearing.

Gemini's image API has no sampleCount. It generates one image per call, and Google's own documentation is blunt about it: "The model won't always follow the exact number of image outputs that the user explicitly asks for."

So when your migrated request carries sampleCount: 4 — or you ask conversationally for "four variations" — Gemini doesn't error. It returns one image, 200 OK. Your candidate pool just dropped from 4 to 1. The "pick the best of 4" step still runs; it's now picking the best of 1. Output quality quietly degrades, throughput math is off by 4×, and nothing in the response says "you asked for four and got one."

If any part of your system reasons about how many images it gets back, that assumption is now wrong, and it's wrong silently.

3. Aspect ratio moved namespaces — and became a suggestion

Imagen takes aspectRatio as a top-level entry in parameters, and it's a hard constraint: ask for 16:9, get 16:9.

On Gemini image generation, aspect ratio is not a top-level parameter. It lives nested inside an image-config block on the generation config. Carry the Imagen-style top-level aspectRatio field straight over and it lands nowhere — it's an unrecognized key, silently dropped, and Gemini falls back to its default (square, or whatever it infers from the prompt).

Result: 200 OK, a perfectly valid image, in the wrong dimensions. Every downstream consumer that assumed a fixed aspect ratio — a CSS grid, a video frame, a thumbnail cropper, a print layout — now gets a shape it wasn't built for. Best case it looks wrong. Worst case the cropper "fixes" it by cutting the subject's head off, automatically, with no error.

And even when you do nest the field correctly, treat it as a strong hint rather than a guarantee. There are documented reports of Gemini image models returning a 1:1 square for an explicit 16:9 request. Validate the dimensions of what comes back; don't trust that you got what you asked for.

4. `personGeneration` has no clean equivalent — your safety posture shifts without a diff

Imagen exposes a personGeneration parameter: dont_allow, allow_adult, allow_all. Teams set this deliberately — a kids' education product pins dont_allow; an internal tool runs allow_all. It's a compliance decision, often written down in a review somewhere.

Gemini's image API doesn't have a personGeneration knob in that shape. It folds people-generation behavior into the general model safety stack. So personGeneration on a migrated request is — you'll notice the pattern by now — an unrecognized key, silently dropped.

What you're left with is Gemini's default people-generation behavior, which is not guaranteed to match the Imagen setting you carefully chose. A pipeline pinned to dont_allow may start returning images with people in them. A pipeline that relied on allow_all may start refusing prompts it used to honor. Either way, 200 OK, no warning, and a safety/compliance posture that changed without anyone editing the line that used to control it. This is the surface a security review would actually care about, and it has no error and no schema diff to catch.

5. The two things to also budget for

Prompt rewriting. Imagen runs an LLM-based prompt rewriter by default — it silently expands your terse prompt before generating. Gemini handles prompts natively and differently. Migrate, send the byte-identical prompt, and the image style, composition, and detail level shift — because the prewriting layer your results were implicitly tuned against is gone. Nothing breaks; your outputs just drift. If you have a brand or style baseline, re-approve it after migrating.

Mask-based editing has no replacement. This is the migration some teams can't actually make. Imagen's capability/editing model does precise, programmatic mask-based inpainting and outpainting — you supply a reference image plus a mask, and edits land exactly inside the mask. Gemini 2.5 Flash Image does conversational editing: you describe the change in words. There is no pixel-precise mask parameter. If you have a pipeline that does deterministic mask-driven edits — product photography, automated retouching, compositing — there is no drop-in path. Find this out now, in June, not in a sprint planning meeting in July.

What to actually do

Grep for the dead model IDs across everything — app code, IaC, notebooks, prompt configs, batch-job definitions:

   git grep -nE "imagen-(4\.0-(generate|ultra-generate|fast-generate)-001|3\.0)"

Treat this as a rewrite, not a string swap. The endpoint, request shape, and response shape all change. Budget for it like the API migration it is.
Audit every Imagen-era parameter against the new API. Make a literal checklist: sampleCount, aspectRatio, personGeneration, prompt-rewrite behavior. For each, confirm it either has a real equivalent you've wired up, or accept — explicitly, in writing — that you're losing it. The danger is the parameter you neither migrate nor consciously drop.
Assert on the response, don't assume it. After migrating, check the count of images returned and the dimensions of each one against what you requested. Both can silently differ. A three-line assertion catches sections 2 and 3 of this post.
Re-approve your output baseline. Prompt rewriting is gone and the underlying model is different. Whatever "looks right" meant for your product, re-establish it against real Gemini output before June 24 — not after.

The model retirement is the loud part, and the loud part will get handled. The migration is the quiet part. Plan for the quiet part.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — model retirements, response-shape changes, and silently-dropped parameters — and surfaces them before they reach production. Free tier monitors 5 endpoints.

Atlassian Admin v1 APIs Go Dark on June 30 — Your User-Provisioning Script Probably Hits Eleven of Them

FlareCanary — Sun, 07 Jun 2026 05:00:42 +0000

If your team has any custom Atlassian Cloud admin automation — IdP sync, SCIM glue, lifecycle scripts, group provisioning — it almost certainly hits at least one of the eleven endpoints under /admin/v1/orgs/{orgId}/.... After June 30, 2026, those endpoints are gone.

Atlassian announced the v1 sunset alongside the new v2 Directory/Users/Groups APIs. The migration is documented; the part that isn't documented loudly is that v2 isn't a drop-in path swap. The shape of the URL changed, the auth model picked up an extra resolution step, and several common automation patterns become two-call sequences instead of one.

The eleven endpoints to grep for

User-management endpoints going away:

POST /admin/v1/orgs/{orgId}/users/search
POST /admin/v1/orgs/{orgId}/directory/users/{accountId}/suspend-access
POST /admin/v1/orgs/{orgId}/directory/users/{accountId}/restore-access
DELETE /admin/v1/orgs/{orgId}/directory/users/{accountId}

Group-management endpoints going away:

POST /admin/v1/orgs/{orgId}/groups/search
POST /admin/v1/orgs/{orgId}/directory/groups
DELETE /admin/v1/orgs/{orgId}/directory/groups/{groupId}
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/roles/assign
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/roles/revoke
POST /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships
DELETE /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships/{accountId}

Plus POST /admin/v1/orgs/{orgId}/users/invite, which Atlassian deprecated on January 13, 2026 — same June 30 sunset date.

A literal grep on your repo:

grep -rn "admin/v1/orgs" --include="*.{py,js,ts,go,rb,sh}" .

If anything comes back, it dies on June 30.

This affects any tenant on centralized user management — which, since 2025, has been the default for new orgs and the migration target for existing ones. If you don't know which user management mode your org is on, the v1 sunset still applies once the migration completes, so treat it as in-scope.

What v2 actually looks like

The v1 path was organization-rooted:

/admin/v1/orgs/{orgId}/directory/users/{accountId}

The v2 path is directory-rooted under an organization:

/admin/v2/orgs/{orgId}/directories/{directoryId}/users/{accountId}

That directoryId is not optional, and Atlassian's v1 callers never had to know it. Every script migrating off v1 needs an extra step to discover the directory before it can act on a user or group inside that directory.

So a one-call workflow becomes a two-call workflow:

1. List directories for the org → pick a directoryId
2. Call the v2 endpoint with {orgId}/directories/{directoryId}/...

For orgs with one directory, this is mostly mechanical. For orgs with multiple directories (Identity Manager, Google, Microsoft, plus a local directory), every script now has to disambiguate, and "the right one" depends on which IdP the user came from.

OAuth scopes — one easy miss

The Admin scope set didn't get a new "v2 scope." But scripts that previously only operated on users-by-account-id never had to declare read:directories:admin. Now they do, because every v2 call passes through a directory resolution.

Apps that don't add read:directories:admin to their token request will get scope errors on the new endpoints — without the v1 endpoint being there to fall back to. The scope error happens at request time, not at auth time, so a token issued before the migration looks fine until the first call.

What the failures will look like

Atlassian's announcement says v1 endpoints "will remain available until 30 June 2026. After this date, they will be fully deprecated." The exact response shape post-sunset isn't documented for /admin/v1/orgs/..., but Atlassian's pattern on other removed REST APIs (Jira /rest/api/3/search and friends) has been HTTP 410 Gone with a JSON error along the lines of:

{
  "code": 410,
  "message": "The requested API has been removed. Please use the newer endpoints."
}

That's the expected fingerprint, not a guarantee. If your client treats 410 as terminal (most retry libraries do), the failed call will not be retried, and the operation — suspend, remove, group-add — silently won't happen. The script returns "successful" on the calls that didn't go through the dead endpoint and "failed" on the ones that did, and a half-completed offboarding looks identical to a successful one in the audit log.

The use cases that quietly break

The Atlassian announcement explicitly calls out a handful of automation patterns that depend on the v1 endpoints:

Offboarding scripts. Calling suspend-access and then directory/users/{accountId} DELETE in sequence is the canonical Atlassian-side termination flow. Both endpoints are on the list.
SCIM-adjacent IdP sync. Many teams wrote custom sync because Atlassian's SCIM connector didn't cover their IdP, or didn't handle group memberships the way they wanted. Custom sync scripts overwhelmingly use the v1 group memberships endpoints.
Bulk invite onboarding. POST /admin/v1/orgs/{orgId}/users/invite was the canonical way to invite a list of users with a default group set. Already deprecated since January.
Group provisioning from CI. Terraform-style "groups defined in code" pipelines that create/delete groups based on YAML — the create and delete endpoints are both on the list.

The offboarding case is the one that goes wrong silently. A user gets removed from your IdP, the sync script runs, the v2 path fails because the script wasn't migrated, and the user keeps their Atlassian access until someone notices on the next access review. That's the nightmare scenario for security teams who track "removed in IdP within X hours" as a compliance metric.

What to do this quarter

Three steps:

Inventory. Grep admin/v1/orgs across all internal repos, CI configs, and scripts on admin/ops machines. Capture which endpoints are in use.
Resolve directory IDs. Build (or buy) a small helper that lists directories on the org and returns the directory ID for a given user — every v2 call needs this.
Add the read:directories:admin scope to your token requests before you migrate the calls. The scope addition is forward-compatible with v1 calls, so you can add it without breaking anything before you cut over.

If your custom sync also uses Jira's /rest/api/3/search or any other v3 Jira API marked for removal, batch them — same orgs, same teams, same maintenance window.

The pattern here is the one we keep seeing across providers: a deprecation notice goes out, the SDK or admin script gets an "available until" date that everyone marks on a sticky note, and on the day the API returns 410 the team finds out which scripts they actually shipped to production years ago. We built FlareCanary to flag the response-shape and field-semantic changes that don't even show up as a deprecation notice — but on this one, the calendar entry for June 30, 2026 is the one to set.

If your offboarding flow uses any v1 endpoint, treat it as the highest-priority migration. Half-completed user removals are an audit problem long before they're a security problem.

Auth0 removes enabled_clients from connection reads July 13 — Terraform/Pulumi will silently see every client as disabled

FlareCanary — Thu, 04 Jun 2026 05:00:42 +0000

If you manage Auth0 connections through Terraform, Pulumi, or any in-house multi-tenant provisioning script, there's a quiet failure mode landing on July 13, 2026. On that date, Auth0 removes the enabled_clients field from GET /api/v2/connections and GET /api/v2/connections/{id} responses, and stops accepting enabled_clients in PATCH /api/v2/connections/{id}. The field was deprecated January 13, 2026; July 13 is end-of-life.

Nothing returns an error. Calls still get a 200. The connection object comes back, with all the same fields you've always read — minus one. The code that reads connection.enabled_clients to figure out which apps are wired to a connection gets either an empty array or undefined, depending on how Auth0 serializes the absence. Either way, your IaC plan, your drift-detection job, or your client-provisioning script reads "no clients enabled" and reacts accordingly. That reaction is usually one of two failure modes, both bad.

The Two Silent Failure Modes

Mode 1: Drift-detection wipe

Terraform's auth0_connection resource (and the Pulumi equivalent) include enabled_clients as a managed attribute. On every plan, the provider calls GET /api/v2/connections/{id}, reads the current enabled_clients, and compares it to what's in your state file. After July 13, the read returns empty, the state file still lists the configured set, and the provider sees a delta. Then apply calls PATCH to "fix" it — sending the configured enabled_clients list back. The PATCH ignores the field (it's deprecated for input too), the connection's client associations stay whatever they actually are, and the next plan shows the same drift again.

The dangerous variant: if you've ever managed Auth0 partly through Terraform and partly through the dashboard or a separate provisioning tool, your state file lists only the clients Terraform knows about. A drift-detection run that decides "the source of truth is my state file" — common in CI pipelines that auto-apply — will silently issue a corrective change. Until July 13, that worked: PATCH with the desired enabled_clients reconciled the difference. After July 13, the PATCH silently no-ops, so Terraform-managed connections look right in the state but actually still have the out-of-band associations intact. If you then also run the new endpoint-based code to "clean up disabled clients," you can wipe the out-of-band ones.

Mode 2: Multi-tenant provisioning over-restriction

A common multi-tenant pattern in SaaS apps that white-label Auth0: when a new tenant signs up, your control plane creates an Auth0 client for them and enables existing connections for that client. The reverse — enumerating which connections each client is enabled on — is usually done by walking all connections, reading enabled_clients, and filtering by the tenant's client_id.

After July 13, that walk returns empty enabled_clients for every connection. Code that interprets the empty list as "this connection has no enabled clients" and then "remediates" by re-enabling everything from a desired-state list hits either:

A no-op (the PATCH ignores the field, the actual associations don't change, the tenant works fine in production but every audit report says they're disabled).
A retry storm (if the script keeps trying to re-enable until GET confirms the change, which never happens because the field is gone).

Either way, observability dashboards keyed on enabled_clients go dark or flatline. SCIM-style sync jobs that reconcile Auth0 against an external IdP source-of-truth start over-eagerly trying to fix a discrepancy that isn't real.

What Actually Changed

The new endpoints, available now:

GET /api/v2/connections/{id}/clients — returns the enabled clients for a connection, paginated.

{
  "clients": [
    { "client_id": "abc123..." },
    { "client_id": "def456..." }
  ],
  "next": "opaque_cursor"
}

Query params: take (1–1000, default 50), from (cursor; omit on first call). When next is absent in the response, you've walked the full set. Required scope: read:connections.

PATCH /api/v2/connections/{id}/clients — toggle enabled status for specific clients.

[
  { "client_id": "abc123...", "status": true  },
  { "client_id": "def456...", "status": false }
]

Returns 204 No Content on success. Required scope: update:connections. The hard constraint that bites bulk operations: maximum 50 clients per request. If your provisioning code enables a connection for all 200 clients in a tenant batch via one enabled_clients PATCH today, the equivalent through the new endpoint is four sequential calls. Naive ports that don't chunk silently truncate at 50 (or, depending on the API, return 400 — the docs don't pin this down).

The new PATCH is also selective, not replacing. The old enabled_clients was a full-set replacement: PATCH with ["client_a", "client_b"] made those exactly the enabled set. The new endpoint only toggles the clients you list. Anything not in your PATCH array keeps its current status. Tools that assumed PATCH = full replacement will now leave stale enables in place.

Why It Slips Through Normal Detection

Walk the standard checks:

HTTP status check — passes. GET /api/v2/connections/{id} still returns 200. The connection object is still there, just without the enabled_clients key.
Schema validation — passes. enabled_clients was always an optional field for connections that hadn't been wired to any client yet. A response without it is structurally valid.
Terraform plan — thinks it caught it. The provider sees the configured enabled_clients is no longer present in the remote state and shows a diff. The diff says "will add three clients." apply runs, the PATCH succeeds (200, the deprecated field is silently dropped), and the next plan shows the same diff. To an operator, this looks like Terraform fighting with another process — not like a deprecated field.
CI / unit tests — pass if they mock Auth0. Anyone who tests against a recorded fixture from before July 13 sees the same field they always saw. Tests don't notice until they hit real Auth0.
Migration audits — only catch it if you specifically look for enabled_clients in your codebase. Most audits look for endpoint URL changes, not field-level removals.

The Terraform Auth0 provider will probably ship a release that switches enabled_clients to use the new endpoints under the hood — but the release calendar isn't Auth0's, it's HashiCorp's (or the community maintainers'). Pinning to an older provider version with explicit enabled_clients config delays the migration into the deprecation window without addressing it.

How To Detect It Now

1. Grep for enabled_clients across your infra repos. Every match is a migration site:

Terraform auth0_connection resources with enabled_clients = [...]
Pulumi auth0.Connection resources with enabledClients: [...]
Direct API calls — anything reading .enabled_clients off a connection response, or sending enabled_clients in a PATCH body
SDK calls: managementClient.connections.update(..., { enabled_clients: ... }) in node-auth0 / auth0-python / auth0.net

2. Verify the new endpoints work for your scopes. The new GET /api/v2/connections/{id}/clients requires read:connections, which most existing M2M tokens already have. The PATCH requires update:connections. If you've used a scoped-down token in CI that only had read:client_grants or similar, you may need to expand it.

3. Chunk PATCHes by 50. Wherever you currently send a full enabled_clients array, the replacement code has to enumerate the desired client_ids, diff against the current set (paginated via the new GET), and issue PATCH /clients calls in chunks of 50 with status: true / status: false per client. Bulk operations that don't chunk break.

4. Treat missing enabled_clients as a sentinel during migration. If your code path can run before or after July 13 (a slow CI matrix, a paused tenant, a long-lived M2M token still hitting an older runtime), add an explicit check: if enabled_clients is undefined on the connection response, fall back to the new endpoint instead of treating it as "no clients enabled." That single guard makes the cutover safe regardless of which side of July 13 the call lands on.

The Pattern

A vendor moves a piece of state from "inlined on a parent resource" to "dedicated sub-resource endpoints." The parent endpoint keeps working. The field just stops being there. Code that assumed presence of the field as "this connection has clients" and absence as "this connection has no clients" reads the new absence as the old "no clients" — and acts on it.

The same shape shows up across cloud providers and SaaS APIs every few months. The mitigation isn't to track every deprecation memo; it's to treat field absence as ambiguous (was it removed? was it always empty? was it filtered out by a scope?) and require an explicit signal before reacting. After July 13, "absent" on Auth0 connection responses means "go ask the new endpoint" — not "no clients enabled."

If you run Auth0 through IaC, the cheapest move this month is to grep for enabled_clients, write the new-endpoint reads alongside the old-field reads, and gate the cutover on a feature flag you can flip per-environment. Eight weeks of runway is enough to do it carefully; the alternative is debugging silent drift on a Monday in July.

Shopify Changed heldBy From a String to an Object in 2025-01 — Your Query Still Returns 200 OK

FlareCanary — Mon, 01 Jun 2026 05:00:36 +0000

Shopify ships a new GraphQL Admin API version every quarter. Most releases are additive. A few are not. The 2025-01 release is one of the "are not": it removed a handful of fields that thousands of apps were reading, and it quietly changed the type of one of the most common fulfillment fields from a string to an object.

The endpoint still returns 200 OK. The query still parses. The field your code reads just isn't there anymore — or it's there under a new name with a completely different shape.

If you upgraded a Shopify app from 2024-x to 2025-01 without reading the full release notes and you're seeing "this field is empty now" in production, this is probably why.

The heldBy → heldByApp Change

On a FulfillmentHold object, the 2024-x GraphQL schema returned:

{
  fulfillmentHold {
    heldBy  # String! — "PrepSupport" or "ShopifyFulfillmentNetwork" or an app name
  }
}

As of 2025-01, heldBy is gone. In its place:

{
  fulfillmentHold {
    heldByApp {
      title    # String! — "PrepSupport"
      id       # ID!
    }
  }
}

The 2025-01 release notes put it like this:

If you currently query fulfillmentHold.heldBy, then transition to querying fulfillmentHold.heldByApp.title.

The important thing is what happens if you don't. GraphQL in this version will happily return null for a field it no longer recognizes (depending on your client's error handling), or it will throw a field-level error that your resolver swallows. Your downstream code — the logic that routes held orders to a human, the Slack notification that names the blocking app, the dashboard tile that shows "held by X" — starts quietly producing empty strings or "Unknown."

Type systems don't save you here, either. Most Shopify SDKs are either hand-rolled TypeScript types generated from the schema at some pinned version, or they're any-shaped because the developer didn't codegen against the current version. If your schema snapshot is from 2024-10, heldBy is still in your types, your IDE still autocompletes it, and your unit tests (mocking your own types) pass. The mismatch only shows up at runtime, against Shopify's live API.

PrivateMetafield Is Just Gone

The second big removal in 2025-01:

PrivateMetafield is removed from the public GraphQL Admin API. Use app-data metafields instead.

There is no field rename, no transitional alias, no "deprecated for N versions" wind-down. Every query, mutation, and resolver that referenced PrivateMetafield, privateMetafields, privateMetafieldUpsert, or the MetafieldStorefrontVisibility object stops working.

If your app was using private metafields to store per-shop configuration — credentials, feature flags, per-merchant routing rules — that configuration didn't move anywhere. You have to migrate it to app-data metafields yourself, re-grant access via the new app-reserved namespace scheme, and replace every read and write. And until you do, the queries come back empty.

The reason this is a silent-failure story and not a loud one is that GraphQL errors on unknown types usually manifest as empty result sets plus a "errors": [...] array in the response body. Plenty of client libraries treat empty results as a valid zero-length response and log the error array at debug level. Your code reads data.app.privateMetafields.edges, gets [], and moves on. The merchant's configuration just looks like it was never set.

accountNumber and routingNumber, Also Gone

A smaller but spicier one, buried in the same release:

Removed accountNumber and routingNumber fields from ShopifyPaymentsBankAccount.

If your app was reading bank account details from Shopify Payments — for displaying masked account info, for reconciling payouts against external bookkeeping, for compliance paperwork — those two fields no longer exist. The field resolver returns null. Whatever UI or report depended on them now shows blanks.

The reason Shopify gave is reasonable (PCI / financial-data exposure narrowing). The reason apps break anyway is that nothing in the upgrade path forces you to notice. You bump your API version header from 2024-10 to 2025-01, you ship, and the fields that used to come back populated just come back null. Everything else is identical.

Why CI Tests and Type Systems Don't Catch This

Every time I write up one of these stories — the GitHub PushEvent commits field, Stripe's Basil current_period_end move, now Shopify 2025-01 — the pattern is the same:

The upstream API version is under the upstream's control, not yours.
The breaking change is a field removal or a type reshape, not a new 4xx status.
Responses still parse. HTTP still returns success.
Your unit tests pass because you mocked the response shape yourself.
Your integration tests pass because your sandbox data was seeded before the change.
Your type checker passes because your types were generated against the old schema.
The break shows up in production, against real data, after a deploy that looked clean.

There is no test you can write inside your codebase that catches a response-shape change introduced by code you don't own. The contract is between two systems and you only control one of them.

What Actually Catches It

Three things can catch a silent upstream schema change, in order of cost:

1. Version pinning with forced upgrade cadence. Shopify lets you pin your API version via the Shopify-Api-Version header. Pin an explicit version and don't let it float. Then schedule the upgrade (2024-10 → 2025-01, etc.) as a deliberate project with a review of the full release notes, a grep of your codebase for removed/renamed fields, and a regression test against a non-production shop. This is what every Shopify app developer should already be doing. Most aren't, which is why forum posts like "Submit for review button is disabled after upgrading to 2025-04" keep showing up.

2. Deprecation-warning monitoring. Shopify exposes deprecated API call counts in the Partner Dashboard and will block app submissions if you have any in the 3-day window before review. Read the warnings, fix the calls. This requires that you bothered to upgrade in the first place, though — it doesn't catch drift on a version you've been sitting on.

3. Runtime shape monitoring. Poll the endpoints your app actually hits on a schedule, record the response shape, and alert when a field disappears, a type shifts, or nullability changes. This is the one catch for APIs that change shape out from under you without you bumping any versions — and it's the one that works for every third-party API, not just the ones that publish a deprecation dashboard. (FlareCanary does this; so do a few others. The point is to have something doing it, not specifically us.)

The economics matter. The cost of an undetected Shopify field rename isn't "an exception in the logs." It's usually something worse — wrong data on a merchant-facing dashboard, a fulfillment routing rule that silently misfires, a compliance report with a missing column. The business cost of one of those is larger than the annual cost of any monitor. And it only takes one.

The Next Shopify Release Is Already Doing This Again

Shopify's 2026-07 release (still months away as of this writing) is dropping grams from DraftOrderLineItem in favor of weight. customerPaymentMethodRemoteCreditCardCreate is fully removed after January 2026. These are the ones listed in the changelog; history says there will be 5–10 more smaller ones by the time the version actually ships.

If you integrate with Shopify, now is a good time to:

Grep your codebase for heldBy (without the App), privateMetafield, accountNumber, routingNumber, grams, multiLocation, customerPaymentMethodRemoteCreditCardCreate, metafieldDelete, visibleToStorefrontApi. Anything that comes back is a candidate break.
Pin your Shopify-Api-Version header explicitly if you aren't already.
Subscribe to the Shopify changelog and actually read it.
Set up shape monitoring on your most critical queries — fulfillment, orders, metafields, payments. Whether you do it yourself, use an observability tool, or use a schema-drift monitor, the cost of not doing it compounds every quarter.

Upstream API breaking changes are not a problem you can solve once. They're a recurring cost of running a product that depends on APIs you don't own. The apps that survive long-term aren't the ones that never get hit — they're the ones that notice within minutes instead of weeks.

I'm Wilson — I write about how third-party API schemas break, quietly, against apps that depend on them. If you integrate with Shopify, Stripe, GitHub, Twilio, or any of a dozen others, FlareCanary polls your critical endpoints and alerts on shape changes before your customers notice. Free tier. No card required.

DEV Community: FlareCanary

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

GitHub GraphQL drops Team.viewerSubscription + 17 audit-log entries on July 1 — and partial errors are the silent surface

What "removed" actually returns

1. The Apollo / urql / Relay "log and continue" pattern

2. Persisted queries and codegen don't help

3. The audit-log surface is a different problem

4. The Insights/Analytics integrations don't surface this

How to find what's affected before July 1

Azure SQL Database 2014-04-01 APIs retire June 30 — your tools auto-upgrade, the response shapes change

1. Eight endpoint groups have no replacement at all

2. Table-based auditing silently maps to blob-based auditing

3. Threat Detection Policies were renamed to Advanced Threat Protection Settings

4. Disaster Recovery Configurations became Failover Groups

5. Restorable Dropped Databases now points at managed instances

How to find what's affected before June 30

SharePoint silently retired the EnableAzureADB2BIntegration setting in May — and your old guest links break in July

1. The setting is gone but the cmdlet still answers

2. Auto-rollout means you can't time your migration

3. July's access-denied is silent from the admin side

4. Anyone-links and Anonymous-links are unaffected — which matters because people will assume otherwise

5. Audit-log event types: the sharing event itself looks different post-rollout

Timeline summary

What this looks like on a monitoring dashboard

References

Shopify Scripts stop executing June 30 — and the failure is silent: checkout completes at full price, no error

1. The cutoff itself fails silent — checkout just stops applying your rules

2. A deployed Function does nothing until a discount node exists in the Admin

3. The input query: a field you forget to request comes back null

4. combinesWith and discount strategy: a Script that always applied may now lose

What to actually do

Google retires every Imagen model on June 24 — and the Gemini image migration fails silently in 4 places

1. The endpoint and response shape changed — and a half-migrated parser fails quiet

2. sampleCount is gone — your batch silently collapses to one image per call

3. Aspect ratio moved namespaces — and became a suggestion

4. personGeneration has no clean equivalent — your safety posture shifts without a diff

5. The two things to also budget for

What to actually do

Atlassian Admin v1 APIs Go Dark on June 30 — Your User-Provisioning Script Probably Hits Eleven of Them

The eleven endpoints to grep for

What v2 actually looks like

OAuth scopes — one easy miss

What the failures will look like

The use cases that quietly break

What to do this quarter

Auth0 removes enabled_clients from connection reads July 13 — Terraform/Pulumi will silently see every client as disabled

The Two Silent Failure Modes

Mode 1: Drift-detection wipe

Mode 2: Multi-tenant provisioning over-restriction

What Actually Changed

Why It Slips Through Normal Detection

How To Detect It Now

The Pattern

Shopify Changed heldBy From a String to an Object in 2025-01 — Your Query Still Returns 200 OK

The heldBy → heldByApp Change

PrivateMetafield Is Just Gone

accountNumber and routingNumber, Also Gone

Why CI Tests and Type Systems Don't Catch This

What Actually Catches It

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`

3. The input query: a field you forget to request comes back `null`

4. `combinesWith` and discount strategy: a Script that always applied may now lose

2. `sampleCount` is gone — your batch silently collapses to one image per call

4. `personGeneration` has no clean equivalent — your safety posture shifts without a diff