同じ値を再送しただけのような「カートの中身が変わらない」操作では carts/update が送られなくなった。Webhook は「リクエストごと」ではなく「変更ごと」に 1 回になり、重複通知がなくなる。
carts/update が送られていた。カートがすでに持っている値と同じ値を再送しただけでも carts/update が発生。結果として重複通知が届いていた。
カートが変化しない操作では送信されない。アプリはカートへの変更 1 回ごとに 1 通の carts/update を受け取る。
| 項目 | 以前 | 今後 |
|---|---|---|
| 送信のきっかけ | 毎リクエスト カート操作のたびに必ず送信 | 変更時のみ 中身・プロパティが変わったとき |
| 同じ値の再送 | carts/update が送られる |
送られない |
| 重複通知 | あり | 解消 |
| アプリが受け取る単位 | リクエスト 1 回につき 1 通 | カートの変更 1 回につき 1 通 |
・カートが変わらない操作では carts/update が送信されない
・変更があれば毎回送信される
・以前は全カート操作で送信されていた
・重複通知がなくなり、変更ごとに 1 通になる
・関連ドキュメント ： Cart webhooks / Ajax Cart API
・対象の API バージョン ： 記載なし
・オプトイン／オプトアウトの有無 ： 記載なし
・適用開始の日時（公開日は 2026-10-12）： 記載なし
・carts/create など他のトピックへの影響 ： 記載なし
・ペイロード形式の変更 ： 記載なし
carts/update が届けば、カートに何かしらの変更があったと考えてよい。「受信 = 実際の変更」という前提が成り立つ。
重複分がなくなるので、受信数をそのまま「カート活動量」として扱っていると数値が変わる。比較するときは変更前後で分けて見る。
操作の生存確認やハートビートとして carts/update を使っていた場合、変化のない操作は届かない。操作の有無そのものを追うなら別の手段が必要。
記事が言っているのは「変化のない操作では送らない」ことだけ。配信リトライによる重複について記載はないので、冪等な処理は今後も残す。
関連ドキュメントに Ajax Cart API が挙げられている。テーマやアプリブロックが同じ値で何度もカート API を呼んでいても、Webhook の受け手側には変更分しか届かない。ただし不要な呼び出し自体がなくなるわけではないので、フロント側の無駄なリクエストは引き続き見直す価値がある。
carts/update を受けるたびに外部 API 呼び出しや DB 書き込みをしているため、重複通知の分まで処理が走っていた。carts/update の件数を「カート更新回数」として KPI 化していると、この変更の前後で数値が下がって見える。carts/update の受信を「顧客がまだカートを触っている」というシグナルとして使っている処理（タイマー延長など）があると、同じ値の再送では届かなくなる。carts/update は “リクエストごと” から “変更ごと” の通知になった。