Updating an order's shipping address recalculates taxes as of API version 2026-10

As of API version 2026-10, changing the shipping address on an unfulfilled order through the orderUpdate GraphQL mutation or the REST Admin API order update endpoint recalculates the order's taxes against the new destination. Previously, orderUpdate saved the new address but left the original tax lines unchanged, so the order's totals no longer matched the destination it was shipping to.

Why it matters

The order's financial data is now corrected as part of the update, now totals stay accurate to the shipping destination. After updating a shipping address, query the order to read the updated taxLines, totalTaxSet, and totals, as you would for any other order edit. You don't need to make any changes to adopt this.

How it works

This change applies to API versions 2026-10 onwards, on both the GraphQL Admin API and the REST Admin API.

Taxes aren't recalculated when:

• The request uses an API version earlier than 2026-10: The address is saved and tax lines are left unchanged, matching the behavior on those versions today.
• The order is partially fulfilled or fully fulfilled: The address is updated but taxes are left unchanged, because some or all units have already shipped to the original destination, and recalculating the whole order against the new address would apply the new destination's tax to units that didn't ship there, producing totals that don't match what was actually fulfilled.
• The order can't be edited: Recalculation runs through order editing, so the same order-editing considerations apply. When an order isn't eligible for editing, the address is saved but taxes aren't recalculated.

Subscribers to the orders/edited webhook receive a notification when an address change results in a tax recalculation.

Because recalculation can change the order's total, an already-paid order can be left with an outstanding refundable or payable balance. After the update, compare the order's balance against its pre-update value: if it increased within your app's tolerance, mark the order as paid (orderMarkAsPaid); for larger increases, merchants can send an invoice (orderInvoiceSend); if it decreased, refund the difference (refundCreate).

To learn more, see the orderUpdate mutation and the developer community discussion.