購入者からの注文変更リクエストを管理する新API
API 2026-10で RequestedOrderEdit が一級リソースとして登場。購入者・マーチャント・外部システムの三者をAPIで繋ぐ。
このアップデートは注文管理・フルフィルメント・ERPと連携するアプリ開発者と、購入後の注文変更対応を効率化したいEC事業者が対象です。API version 2026-10から利用可能で、購入者が注文の未フルフィルメント行を削除申請し、マーチャント側のアプリがAPIを通じて承認・拒否・自動処理を行えるようになります。
1Before / After — 何が変わったか
2新規追加されたAPI要素一覧
| 種別 | 名称 | 役割 |
|---|---|---|
| Object | RequestedOrderEdit | 購入者リクエストを表す新オブジェクト。ステータス・変更内容・タイムスタンプを保持 |
| Mutation (Admin) | requestedOrderEditCreate | リクエストを作成する |
| Mutation (Admin) | requestedOrderEditResolve | リクエストを手動解決済みにする |
| Mutation (Admin) | requestedOrderEditDecline | リクエストを拒否する |
| Query (Admin) | requestedOrderEditCalculate | リクエスト作成前に財務上の影響を計算・プレビュー |
| Query (Admin) | orders (フィルター拡張) | requested_order_edit_status でリクエスト待ちの注文を絞り込み |
| Field (Admin) | Order.requestedOrderEdits | 注文に紐づくリクエストの一覧コネクション |
| Field (Admin) | Order.displayRequestedEditStatus | 注文のリクエスト状態を集約して表示用に返すフィールド |
| Mutation (Customer) | orderRequestEdit | 購入者がカスタマーアカウントから編集申請を送る。冪等キー対応 |
| Query (Customer) | requestedOrderEditCalculate | 購入者側で財務影響をプレビュー |
| Webhook | requested_order_edit/created | リクエスト作成時に発火 |
| Webhook | requested_order_edit/resolved | リクエスト解決時に発火 |
| Webhook | requested_order_edit/declined | リクエスト拒否時に発火 |
3業務別ユースケース
- 課題
- 購入後に「サイズを間違えたので削除したい」という問い合わせが毎日複数発生し、カスタマーサポートが手作業で注文を修正している
- 打ち手
- 打ち手
- Customer Account APIの
orderRequestEditをマイアカウントページに実装し、購入者が自分でリクエストを送れるUIを構築。Admin API のrequestedOrderEditResolveをCS管理画面に組み込み、ワンクリックで承認できるようにする - 効果
- CS対応コストを削減し、購入者は24時間いつでも変更申請が可能に。冪等キー対応で二重申請も防止できる
- 技術メモ
-
orderRequestEditは@idempotentディレクティブで冪等キーを指定可能。再試行しても元のオブジェクトが返るため、ネットワーク障害時の二重作成を防げる
- 課題
- 課題
- フルフィルメントシステム(WMS)が注文確定後すぐにピッキングを開始してしまい、変更リクエストが間に合わないケースが頻発している
- 打ち手
-
requested_order_edit/createdWebhookを受信したら、外部WMSに対して該当注文のフルフィルメントを自動で保留するAPIを呼び出す。その後resolvedまたはdeclinedを受け取ったタイミングで保留を解除する - 効果
- リクエスト中の誤出荷ゼロを目指せる。Webhookペイロードに
order_idと変更内容が含まれるため、WMS側のルーティングもシンプルに実装できる - 技術メモ
- Webhookペイロードにはリクエストのステータス・order_id・リクエストされた行変更と解決済み数量が含まれることが公式に明記されている
- 課題
- ERP側に注文変更の申請状況が反映されず、マーチャントが社内で「この注文は変更待ちか」を都度Shopify管理画面で確認しなければならない
- 打ち手
- Admin APIの
ordersクエリにrequested_order_edit_statusフィルターを追加し、定期ジョブでリクエスト待ち注文をERPに同期。Order.displayRequestedEditStatusを使って注文一覧に「変更申請中」バッジを表示する - 効果
- ERPと Shopify 間の情報ギャップが解消され、在庫引当や出荷計画の精度が向上する
- 技術メモ
- Admin API でクエリするには
read_ordersスコープ、ミューテーションにはwrite_ordersスコープが必要。既存のオーダー管理スコープを持つアプリは追加申請が不要な場合が多い
4技術者向けポイント
すべての新機能は 2026-10 で利用可能。それ以前のバージョン（2026-07以前）ではAPIに購入者リクエストの記録は存在しない。
Admin API クエリ: read_orders / Admin API ミューテーション: write_orders。Customer Account APIの orderRequestEdit は購入者自身のセッションで動作するため、マーチャントアプリのスコープとは別管理。
orderRequestEdit は @idempotent ディレクティブでオプションの冪等キーを受け取る。同一キーで再試行した場合、新規オブジェクトを作らず既存のオブジェクトを返す。
Admin API・Customer Account API の両方に requestedOrderEditCalculate クエリが存在する。リクエスト作成前に返金額や差額を確認できるため、購入者向けUIで「この変更で〇〇円返金されます」という表示が実装可能。
注文管理・ERP連携・フルフィルメント・3PL連携・カスタマーアカウントUIを構築するアプリが主な影響範囲。既存アプリへの破壊的変更はなく、機能追加の対応は任意。
3種のWebhookペイロードにはリクエストのステータス・order_id・リクエストされた行変更とその解決済み数量が含まれる。外部システムへの差分同期に利用できる。
購入後の注文変更を購入者自身がAPIで申請できるようになり、マーチャント側は承認・拒否・フルフィルメント保留をすべて自動化できるため、CSコスト削減と誤出荷防止を同時に実現できます。
Source: https://shopify.dev/changelog/new-apis-for-buyer-requested-order-edits | 公開日: 2026年10月1日
Share:
フルフィルメント先に州コード取得が可能に