October 9, 2026 · Muhammad Rehan · More by Muhammad Rehan
Shopify's RequestedOrderEdit: What ERPs Need to Watch
Shopify's 2026-10 API adds a RequestedOrderEdit resource so ERP and 3PL integrations can finally see buyer-requested order edits before fulfillment.
Before Shopify's 2026-10 API version, a buyer who wanted an unfulfilled line item removed after purchase had to contact the merchant directly. The merchant edited the order manually, and no app — ERP, WMS, or 3PL — had any API-visible signal that a change was pending. Shopify's own changelog frames this plainly: apps "can't see the request, act on it, or keep external systems (ERP, WMS) in sync with pending changes before fulfillment." The 2026-10 release, stable since October 1, 2026, closes that gap.
A first-class resource for buyer edit requests
RequestedOrderEdit is now a first-class object in the GraphQL Admin API, carrying the request's status, requested changes, and timestamps for when it was made, resolved, or declined. Three new mutations — requestedOrderEditCreate, requestedOrderEditResolve, and requestedOrderEditDecline — let an app act on a request on the merchant's or buyer's behalf. The Order object gains a requestedOrderEdits connection and a displayRequestedEditStatus field, and the orders query adds a requested_order_edit_status filter so an integration can pull every order with a request still waiting on merchant action.
Webhooks, idempotency, and a pre-commit preview
Three new webhook topics — requested_order_edit/created, requested_order_edit/resolved, and requested_order_edit/declined — carry the request's status, order_id, and the resolved line item changes, which is enough for a sync pipeline to react without polling. On the Customer Account API, the new orderRequestEdit mutation is what a buyer actually calls, and it supports an idempotency key through the @idempotent directive: a retried submission returns the originally created object instead of creating a duplicate. Separately, requestedOrderEditCalculate returns the calculated financial outcome of a request before it's created — useful for an ERP that needs to pre-validate a refund or adjustment before it ever syncs downstream.
Fulfillment holds are still your integration's decision
Nothing in this release makes Shopify automatically pause fulfillment while a request is pending. Shopify's own wording is that apps "can now surface pending requests in their own workflows, hold fulfillment on orders with a REQUESTED status, and automate resolution or decline decisions" — can, not does. Whether a pending request blocks a warehouse pick-and-pack is a design decision for the integration, not platform-enforced behavior. An ERP or 3PL sync that wants that protection has to read displayRequestedEditStatus or the requested_order_edit_status filter and build the hold itself.
Reading orders through this API requires the read_orders scope; acting on requests through the mutations requires write_orders. For teams maintaining an existing order sync pipeline, this is worth evaluating before the next API version bump — the alternative is staying on an older version where buyer edit requests remain invisible to your integration entirely.