Developer Changelog / Webhooks

Cart operations that change nothing
no longer trigger carts/update webhooks

For operations that leave the cart contents unchanged, such as simply resending the same value, carts/update is no longer sent. Webhooks now fire once per change instead of once per request, so duplicate notifications go away.

On this page
  1. What's changing (30-second overview)
  2. How it works: requests vs. webhooks
  3. Before / After comparison
  4. What the article does and doesn't say
  5. 5 key points for developers
  6. 3 practical use cases
  7. One-line summary for proposals

1What's changing

Before: Every cart operation always triggered carts/update being sent.
Now: Only when the cart's contents or properties actually change is sent.

Before: 1 request = 1 webhook

Even resending a value the cart already had triggered carts/update . As a result, duplicate notifications were delivered.

Now: 1 change = 1 webhook

Nothing is sent for operations that don't change the cart. Apps receive one carts/update per cart change.

2How it works: requests vs. webhooks

Cart operation request Shopify's check What the app receives Request ①: quantity 1 → 2 Contents change Changed carts/update ×1 Request ②: quantity 2 → 2 (same value resent) Contents don't change Unchanged Not sent Request ③: change properties Cart properties change Changed carts/update ×1 3 requests → previously 3 webhooks, now 2 (one per change)
The quantities and properties in the diagram are illustrative. The only concrete example in the article is the "Resend the same values the cart already has" operation. The trigger condition is "when the cart'scontents or properties change".

3Before / After comparison

ItemBeforeAfter
Trigger Every request Always sent on every cart operation Only on change When contents or properties change
Resending the same values carts/update is sent Not sent
Duplicate notifications Yes Resolved
What the app receives One webhook per request One webhook per cart change

4What the article says / doesn't say

Stated

What it says

For operations that don't change the cart, carts/update is not sent
Sent every time there is a change
Previously sent on every cart operation
No more duplicate notifications; one webhook per change
Related docs: Cart webhooks / Ajax Cart API

Not stated

What it doesn't say

Applicable API version: not stated
Opt-in / opt-out: not stated
Effective date and time (published 2026-10-12): Not stated
Impact oncarts/create and other topics: Not stated
Payload format changes: Not stated

The article also doesn't give detailed criteria for what counts as a change. If your logic depends on edge cases (such as only the item order differing), verify the actual behavior on a development store.

55 key points for developers

Δ

1. Webhooks now represent actual changes

carts/update arriving means something in the cart actually changed. You can now rely on "received = real change."

2. You may receive fewer webhooks

Duplicates are gone, so if you treat the raw receive count as "cart activity," your numbers will shift. Compare the periods before and after the change separately.

3. "Sent = user action" no longer holds

If you relied on it as a liveness check or heartbeat for user actions via carts/update , actions that change nothing will no longer trigger it. If you need to track whether actions happen at all, you'll need another method.

4. Keep your deduplication logic

The article only says webhooks won't be sent for actions that change nothing. It says nothing about duplicates from delivery retries, so keep your processing idempotent.

AJAX

5. Storefront Ajax Cart API calls are affected too

The related docs list the Ajax Cart API. Even if a theme or app block calls the cart API repeatedly with the same values, the webhook receiver only gets actual changes. However,the unnecessary calls themselves don't go away, so redundant frontend requests are still worth reviewing.

63 practical use cases

USE CASE 1

Reviewing cost and load for webhook-consuming apps

Problem
carts/update triggered external API calls or DB writes on every receipt, so processing ran even for duplicate notifications.
Action
Measure the receive count and processing time after the change and compare them with the previous numbers. Check whether your queue and worker settings are oversized.
Result
Less wasted processing, since duplicate notifications no longer need handling. How much it drops depends on the store's usage patterns.
Tech note
Your own "skip if identical to last time" logic may no longer be needed, but the article doesn't cover every case, so verify the actual behavior before removing it.
Change date
USE CASE 2

Adjusting dashboards and reports that track cart behavior

Problem
carts/update counts tracked as a "cart update count" KPI will appear to drop around this change.
Action
Annotate reports with the change date (published 2026-10-12). Redefine the metric as "number of changes" rather than "number of requests."
Result
You won't mistake a drop caused by the spec change for a real business decline.
Tech note
The exact effective date isn't stated in the article. Check your receive logs for when the count dropped and use that as the cutoff.
USE CASE 3

Auditing logic that assumes "received = user action"

Challenge
carts/update webhooks: if any logic (such as extending a timer) treats their arrival as a signal that the customer is still active in the cart, it will no longer fire when identical values are resent.
Action
Audit your webhook handlers and identify logic that depends on how many webhooks arrive or when they arrive. Rewrite it to rely on actual changes to the cart contents.
Impact
Catch unexpected behavior from this change before it turns into a production incident.
Tech note
Add a test case on a development store that confirms no webhook is sent when a cart is updated with identical values.

7One-line summary for proposals

"carts/update now notifies "per change" instead of "per request."
No more duplicate notifications: you receive exactly one per actual change.
Apps and reports that use webhook volume as a metric should be reviewed, with the change date as the cutoff."