News and analysis
Order edits and returns: connecting customer requests to store policies
Shopify order-edit requests and return policies: align statuses, market rules and API permissions with customer, stock and payment outcomes.
After purchase, a customer asks to remove an item. Support sees the message, the warehouse is preparing shipment and the customer account still shows the original order. Calling the request an “order change” immediately may imply that the item has been removed and the money recalculated, even though the shop has not acted yet.
Shopify added two separate capabilities in API version 2026-10: buyer-requested order edits and access to return policy profiles. Both require the customer interface to agree with the shop's internal actions. However, return rules do not themselves authorise an order edit, and recording a request does not mean the change has been applied.
Give the customer's request its own record
In its buyer-requested order edits announcement, Shopify describes requests to remove unfulfilled line items. A RequestedOrderEdit object contains the status, requested changes and timestamps. GraphQL Admin API operations let applications create a request, mark it manually resolved or decline it. Customers can submit a request through orderRequestEdit in the Customer Account API.
This is not a universal mechanism for arbitrary changes to any purchase. The described capability concerns removal of unfulfilled line items. Returning a delivered product, changing an address or adding items are different scenarios; their availability cannot be inferred from this announcement.
Shopify also describes a financial preview through requestedOrderEditCalculate. A preview can explain an expected result, but the interface must distinguish an estimated amount from an executed financial operation. A “Submit request” button should explain what happens immediately and when the shop will give its final answer.
Separate the request from the executed change
A practical shop workflow might distinguish four states: request registered, decision being prepared, change confirmed and request declined. This is a design recommendation. Map it to the actual API states using the selected version's documentation.
Assign ownership at each transition. Support clarifies the customer's intention, the warehouse checks whether preparation can be stopped and an authorised employee or application makes the decision. A request state must not substitute for the actual order state. Marking a request manually resolved should reflect an action already completed, rather than hide an unprocessed task.
Customer product planning treats the interface together with the operational system behind it. This scenario makes the connection clear: a useful customer account shows more than a request form. It shows current status, response expectations and the reason for rejection.
Test a concurrent event: the customer submits a request while the warehouse finishes preparation. An API that can store a request does not, by itself, guarantee that shipment will stop. Agree on rules with the fulfilment system and confirm that revised quantities reach the relevant participants.
Return rules support a different decision
The return policy profiles announcement adds structured market rules in GraphQL Admin API 2026-10. Markets reference profiles; editing a shared profile affects all referencing markets.
Profiles are read-only through this API; creation, editing and deletion happen in Shopify admin. Reading requires read_legal_policies; managing market assignments requires write_markets. Order-edit requests separately use read_orders and write_orders. Similar terminology does not justify merging permissions.
For a business, the rules are a separate decision source. If a customer has received the product and asks to return it, determine the market and applicable terms before starting the return process. A return profile is not automatic permission for an earlier edit to an unfulfilled order.
Interpret null values in context
Market.returnPolicyProfile returns the direct assignment without resolving market hierarchy. Here, null means no direct assignment. Shopify also describes a default profile for markets without named assignments; absence of a direct profile does not establish absence of applicable terms.
In returnRules or editRules, null means disabled rules; Shopify describes unrestricted returns under returnRules: null. Do not generalise this meaning to other nullable fields or legal obligations.
Retain the applied profile identifier, relevant terms and checking time alongside the decision. Shopify says the aggregated updatedAt field changes when parts of the profile change. If a shared profile is updated between the request and the decision, staff need clear rechecking rules. Legal assessment of terms is separate from reading their technical representation.
Align the order, stock and money
After an approved change, check three independent results: order contents, warehouse action and financial records. A removed item should not remain in a picking task. Stock reservation should not be released twice. The interface should show the confirmed amount.
The Google Sheets inventory description provides context for stock movements and correction ownership. It does not establish use of the new Shopify APIs. The connection between orders and stock must be designed around the particular shop's current rules and constraints.
Across system boundaries, use stable order and request identifiers, visible errors and recovery from partial completion. These issues are covered in the API integration approach. Add payment reconciliation to the financial side: an order-change message does not prove that monetary records already agree.
Choose a small, complete first stage
Begin with one request type and a limited fulfilment segment. Check an unfulfilled order, an already fulfilled item, a decline, a policy change and a discrepancy between shop and warehouse. Acceptance means that the customer and employees understand the same outcome.
Also review friction in mobile commerce. Clear explanations of subsequent actions matter after payment as well as before it. When customers see a confirmed state and staff know the next step, the API supports a useful service rather than another form followed by hidden manual correspondence.