Feature request: updateLineItemQuantity in the POS UI Extensions Cart AP

Extensions
1

Hi POS team,

I’m writing to ask if it would be possible for you to provide a first-class way to change the quantity of an existing cart line:

updateLineItemQuantity(uuid: string, quantity: number): Promise<void>;
// or additive: incrementLineItemQuantity(uuid: string, delta: number)

Semantics we need: line-scoped (no full-cart rewrite), preserves the line’s
properties/discounts/price as-is, triggers the same downstream behavior as
a merchant tapping +/- on the native cart line (including one cart-transform
pass where applicable), and returns after the cart state reflects the change.

Why the current API can’t express “one more of the same”

Our extension configures items with modifiers, then adds them to the cart.
When staff ring the same configured item twice, the correct outcome is a
quantity bump on the existing line. Today there is no safe way to do that:

  1. addLineItem(variantId, qty) (bare re-add): POS creates a SEPARATE
    line instead of merging into the visually identical existing line (see
    our linked report). Until a follow-up property write lands, that line is
    invisible to our routing (kitchen printers / KDS) — on-device we measured
    30–60 seconds of a property-less, unexpanded line sitting in the cart.
  2. addLineItem(variantId, qty, { properties }) (our current
    workaround):     works, but only because POS sometimes merges identical
    fully-propertied lines after cart-transform expansion — behavior we have
    observed to vary across POS app versions and cannot rely on. Worst case
    the merchant sees two lines where they expect one line × 2.
  3. bulkCartUpdate: the only API that can express a quantity change,
    but it requires rewriting the ENTIRE cart. We have measured two failure
    modes on-device: (a) payloads carrying computed fields (title/price on
    variant lines) hard-reject with a GuardError, and (b) full-cart rewrites
    intermittently repricing existing lines to $0.00. It also interacts
    badly with cart-transform-expanded bundles: bumping a main line without
    re-running expansion leaves component quantities stale.

So the natural operation — “this exact line, quantity + 1” — is expressible
by a merchant’s finger on the native cart UI, but not by an extension.

Concrete use cases

  • Duplicate add → merge (our case): rush-hour cafe orders where the
    same configured drink is rung repeatedly. Today: extra lines, or
    version-dependent merge behavior, or a dangerous full-cart rewrite.
  • Quantity steppers in extension UI: any extension that renders its own
    cart-adjacent UI must round-trip through remove + re-add (destroying
    discounts and property state) or bulkCartUpdate.
  • Custom sales: addCustomSale lines have no variantId, so the bare
    re-add “workaround” doesn’t even exist for them — bulkCartUpdate is the
    ONLY option today.

What we’d retire the day this ships

Our duplicate-add path is isolated behind one interface; with
updateLineItemQuantity we would delete a version-dependent merge
workaround for variant lines and a full-cart bulkCartUpdate rewrite for
custom sales, replacing both with a single line-scoped call.

Prepared 2026-07-31. Happy to share repro extensions, device logs, and
the measured timings above with the POS extensibility team.

1 Like