PRODUCT_UNAVAILABLE_IN_BUYER_LOCATIONStarting with the 2026-07 Storefront API, when a Cart line contains a product that isn't carried in the buyer's location, the Cart returns a warning for each affected line. The target field holds the CartLine ID, so it maps directly to the line in your UI.
Even when a product that can't be sold in the region stayed in the cart, there was no dedicated warning code, so it tended to be noticed right before checkout or to turn into a support inquiry.
The Cart's warnings now include PRODUCT_UNAVAILABLE_IN_BUYER_LOCATION , andtarget holds the matching CartLine ID is placed in. You can pinpoint that exact line and highlight it in red in the UI.
PRODUCT_UNAVAILABLE_IN_BUYER_LOCATION. Indicates that a cart line contains a product not available for sale in the buyer's location.
Applies CartLine ID. You can directly pinpoint which line in the UI the warning is about.
One warning is issued per affected cart line (multiple affected lines = multiple warnings).
| Item | Legacy | 2026-07 and later |
|---|---|---|
| Detecting products not purchasable in a region | Custom implementation You need your own check logic | The API notifies you Returned as a Cart warning |
| Identifying the affected line | Ambiguous across the whole cart | CartLine ID A target is tied to it |
| Handling multiple lines at once | — | A separate warning is issued per line |
| UI reflection | Tends to be delayed until checkout | Can immediately flag it in red / show a removal path on the cart page |
| Positioning | — | warning Builds on the existing cart warnings mechanism |
Cart will start issuing it in the 2026-07 version. Clients pinned to older versions won't benefit.
In the Cart query response, warnings you need to include and fetch it, andcode and target read it.
Update your Storefront client's version to 2026-07 or later.
cart { warnings { code target } } Request and retrieve it.
Map the target's CartLine ID to the row in the UI to show a warning and a remove CTA.
GraphQL's errors , but rather the Cart's warnings is how it's returned. The query still succeeds, and the design layers this information on as a business-level note.
The behavior is "2 unavailable products in the cart → 2 warnings." Build the UI implementation on the assumption that you loop over them as an array.
When reconciling against the UI's data, you need a design that joins warnings using the CartLine ID as the key. Note that it's not the product ID.
If your client pins the API version, this warning won't come through unless you explicitly bump to 2026-07. Include it in your version-upgrade plan.
Cases that previously "errored out right before checkout" can now besurfaced proactively on the cart screen. This is a design change you can use as the basis for UX improvements that reduce abandonment and support costs.
PRODUCT_UNAVAILABLE_IN_BUYER_LOCATION pick up, then flag the affected CartLine in red on the cart screen with a remove CTA.warnings Set up a shared hook that collects in one place, andcode === 'PRODUCT_UNAVAILABLE_IN_BUYER_LOCATION' centrally manage known codes—including—in an enum.PRODUCT_UNAVAILABLE_IN_BUYER_LOCATION tag the sessions where a warning was raised and emit the event to your analytics stack (GA4 / BigQuery, etc.).