API バージョン 2026-04 から、3PL や配送アプリが fulfillmentOrderReportProgress でフルフィルメント注文の進捗を報告できる。「着手した」ことを伝え、任意で短いステータスメモを添えられる。マーチャントは配送パイプラインの状況が見えるようになる。
fulfillmentOrderReportProgress mutation で、3PL や配送アプリが「着手した」ことを Shopify に通知でき、マーチャント側からその進捗が見えるようになる。
注文を渡したあと、3PL が実際に作業を始めたのか、まだ手付かずなのかをマーチャントが API 経由で知る標準手段がなかった。
配送側が mutation で進捗を報告 → ステータスが更新され、webhook が発火。任意のメモ（reasonNotes）も添えられる。
fulfillmentOrder.supportedActions が REPORT_PROGRESS アクションを返すようになる。報告できる前提ステータスは、その注文が「3PL 管理」か「マーチャント管理」かで異なる。
| 項目 | 3PL 管理のフルフィルメント注文 | マーチャント管理のフルフィルメント注文 |
|---|---|---|
| 報告できるステータス | IN_PROGRESS | OPEN または IN_PROGRESS |
| 必要なスコープ | 記載なし（フルフィルメントサービス向け） | write_merchant_managed_fulfillment_orders |
| reasonNotes | 任意 最大 256 文字の補足メモを添付可能 | |
既にフルフィルメントサービスへ引き渡され作業が走っている（IN_PROGRESS）注文に対して進捗を返す想定。
まだ OPEN の段階でも報告でき、IN_PROGRESS に遷移させられる。ただし書き込みスコープが必要。
fulfillment_orders/progress_reportedフルフィルメント注文に進捗が報告されたときに発火する。
ペイロードに含まれるもの ：
fulfillment_orders/manually_reported_progress_stopped進捗を手動報告した（fulfillmentOrderReportProgress 経由の）マーチャント管理のフルフィルメント注文が、その後「fulfillment 準備完了（ready for fulfillment）」とマークされ、IN_PROGRESS から OPEN に戻ったときに発火する。
＝ マーチャントが、前に報告した「作業中」状態を「取り消した／キャンセルした」ことをアプリが検知できる。
「ピッキング開始」「在庫待ち」など、状況を表す短いメモを添えられる。マーチャントが配送パイプラインの今を把握する手がかりになる。webhook の reason_notes にも反映される。
進捗報告が可能な注文では fulfillmentOrder.supportedActions が REPORT_PROGRESS を返す。事前にこのアクションの有無を確認してから mutation を投げれば、無駄なエラーを避けられる。
この mutation・webhook・REPORT_PROGRESS アクションは API バージョン 2026-04 以降で利用可能。古いバージョンを叩いているアプリは更新が必要。
3PL 管理は IN_PROGRESS のみ、マーチャント管理は OPEN／IN_PROGRESS の両方。送る前に対象注文のタイプとステータスを確認する。
マーチャント管理注文に報告するには write_merchant_managed_fulfillment_orders スコープが要る。OAuth のスコープ設定を見直すこと。
progress_reported で着手を、manually_reported_progress_stopped で OPEN への巻き戻しを検知。後者はマーチャント管理注文が「準備完了」に戻された時のみ。
progress_reported webhook のペイロードには、報告したアプリ／ユーザーの attribution data と initial_status（更新前ステータス）が含まれる。監査ログや「どの 3PL がいつ着手したか」の追跡に使える。複数の配送アプリが共存する環境で特に有用。
fulfillmentOrderReportProgress を発行 → reasonNotes に「ピッキング開始」等を添える。supportedActions に REPORT_PROGRESS があるか確認してから叩く。fulfillment_orders/progress_reported と manually_reported_progress_stopped を購読し、受信を起点に通知を発火。initial_status と progress_report を使い、状態遷移とメモを通知本文に整形する。progress_reported webhook の attribution data（報告元アプリ／ユーザー）と時刻を保存し、注文単位の進捗ログを構築。reason_notes を注文 ID に紐づけて時系列保存。完了系イベントと突き合わせると着手→完了のリードタイムも算出可能。