Skip to main content

batch_get_item_options

Fetches the full spec and ingredient candidates of items across several shops in one call, grouped by shop. It is the cross-shop version of get_item_options — for a single shop, use that one. Use it when you have found a few shops, picked a few items in each, and want to compare specs and prices side by side. When shops come from a search, you do not know up front how many you will get, so calling per shop means writing a loop of unknown length into your orchestration; this tool gets everything in one call.
Each item is returned exactly as get_item_options returns it — sku_options / ingredient_options / the selected marking / promo_labels / price_steps all carry the same meaning and usage, so they are not repeated here; this page only covers the per-shop grouping layer. Everything that page warns about (candidates converging on your current selection, same-name-different-option, never multiplying by portion count, checking the price echo) applies here too.

Parameters

Every item_id must sit under the cart_id of the shop it belongs to. Item IDs are minted per shop, so an ID placed under a different shop will not be found (that entry returns PUBLIC_REFERENCE_INVALID).

Response

The top level is { "carts": [...] }, where carts maps one-to-one and in order with the carts you sent. Each element carries either items (that shop succeeded) or error (that shop failed as a whole) — tell them apart by whether error is present.
One failing shop does not affect the others. Carts expire, so when 1 of 5 has gone stale the other 4 still come back and the call still counts as successful. Only an invalid consent or too many items fails the whole call.Failures come in three independent layers: the whole call → one shop (carts[].error) → one item (carts[].items[].error).
The 500-item cap is a guard rail, not a target. Each item is roughly 3-7 KB, so 100 items is about 0.3-0.5 MB and 500 items can reach 3 MB — more than most models can hold in context. Ask for the items you actually intend to show or order, typically a handful per shop.When the cap is exceeded the whole batch is rejected; nothing is truncated — silently returning half the data while looking successful is far more dangerous than an error.For reference: 5 shops with 100 items total takes about 1.1-1.5 seconds on a first lookup.

Errors

Example call

Response (excerpt: the first shop succeeded with one invalid item ID; the second shop’s cart has expired):