Shopify Buyer-Requested Order Edits: Hold Fulfillment Until Requests Are Reviewed

Type: Developer Guide / Operations · Stage: Scale · Topic: Orders / Customer Accounts / Fulfillment

Why older “contact support to change your order” advice is incomplete

Before API version 2026-10, a customer could email support about an order change, but integrations had no standard, API-visible object representing that pending request. A fulfillment worker might see a paid, unfulfilled order and send it to the warehouse before a support agent even opened the email.

On October 1, 2026, Shopify introduced buyer-requested order edits as first-class records. That does not make Shopify a universal self-service order editor: the documented request flow currently covers removing quantities from unfulfilled line items. It is not a blanket API for changing addresses, adding arbitrary products, or editing already-fulfilled items.

Use the request state as an operational signal

Shopify added Order.requestedOrderEdits, Order.displayRequestedEditStatus, and an orders search filter named requested_order_edit_status. An integration can query orders that need attention:

query OrdersWithPendingEditRequests {
  orders(
    first: 20,
    query: "requested_order_edit_status:REQUESTED"
  ) {
    nodes {
      id
      name
      displayRequestedEditStatus
      requestedOrderEdits(first: 10) {
        nodes {
          id
          status
          requestedAt
        }
      }
    }
    pageInfo { hasNextPage endCursor }
  }
}

Read the individual request records as well as the aggregate status. An order may have multiple requests; the aggregate field is a display-oriented summary, not a replacement for inspecting each requested line item. Admin queries require read_orders; request mutations require write_orders and applicable user permissions.

Let a buyer submit a request from a customer account

The Customer Account API provides orderRequestEdit. The mutation accepts an order ID and a set of line-item removals, with the quantity to remove. This example requests removal of one unfulfilled unit:

mutation RequestRemoval(
  $orderId: ID!,
  $lineItems: RequestedOrderEditLineItemsInput!
) {
  orderRequestEdit(
    orderId: $orderId,
    lineItems: $lineItems
  ) {
    requestedOrderEdit { id status requestedAt }
    userErrors { field message }
  }
}

{
  "orderId": "gid://shopify/Order/10079785100",
  "lineItems": {
    "removals": [{
      "lineItemId": "gid://shopify/LineItem/10079785100",
      "quantity": 1
    }]
  }
}

Use the authenticated customer context and required Customer Account API permissions. Shopify documents the optional @idempotent directive for safely retrying the buyer mutation; implement it according to the directive’s schema if network retries are possible. Never allow a browser to submit a different customer’s order ID without Shopify’s authorization checks.

Wire requests into the fulfillment decision

1. Subscribe to requested_order_edit/created, requested_order_edit/resolved, and requested_order_edit/declined for your app, or use the corresponding supported event subscription mechanism.
2. Verify each webhook signature and deduplicate deliveries. Store the request ID, order ID, status, and received timestamp.
3. When a request is REQUESTED, mark the order as review needed in your integration and prevent your own outbound fulfillment release while it is being reviewed. If a warehouse already has the order, send a cancellation/hold instruction through that system’s supported workflow.
4. Have the merchant or an authorized app decide whether the underlying order can be edited. Review the financial calculation and fulfillment state before changing quantities.
5. Apply the permitted order edit through the appropriate Shopify order-editing workflow. Then resolve the request using requestedOrderEditResolve, or decline it with requestedOrderEditDecline when the change cannot be accepted.
6. Re-read the final order lines, quantities, financial status, and request state before releasing it to the 3PL. Reconcile with any shipment already in progress.

Important: The request’s status is not a substitute for an actual order change. Marking a request resolved is a lifecycle action; your integration must verify that the desired order edit was actually applied before it treats fulfillment data as final.

Use the webhooks as triggers, not as your only source of truth

Webhook deliveries can arrive more than once or be delayed. Treat them as a signal to fetch the current request and order state. A periodic reconciliation query for requested_order_edit_status:REQUESTED can catch missed events. Never implement “created means cancel the whole order”; the buyer may only be asking to remove one unit from a multi-line purchase.

If your warehouse integration already snapshots orders on creation, you need a clear policy for when the snapshot becomes irreversible. The earlier the fulfillment handoff, the smaller the time window for honoring customer requests.

Sources and further reading

Documentation checked October 23, 2026.