Instacart for AI Agents

The full shopping loop is here. select_store navigates to a specific retailer's storefront, search_products searches that store's catalog, view_product opens the product detail dialog, and add_to_cart puts an item in the cart. Cart management is granular: view_cart, increment_quantity, decrement_quantity, and remove_from_cart let the agent shape the order exactly, and the checkout chain ends with a URL your user can pay at.

The account side is mapped too. view_orders returns order history as structured records, view_order opens any single order, and reorder pushes an entire past delivered order back into the cart. For an order that is still being shopped, view_order_items plus update_order_item_quantity let the agent change quantities or remove items mid-flight, with quantity '0' removing an item. view_addresses, add_address, and view_payment_methods round out account management. add_address rides Instacart's Google Places autocomplete and takes the first suggestion automatically.

These come straight from the mapped action behavior, not guesswork.

**The store slug threads through everything.** After select_store, the resulting URL carries a store_slug (the path segment between '/store/' and '/storefront', e.g. 'costco-warehouse'). search_products requires that slug because Instacart's URL-based ?q= search no longer respects the query param on its new AI-search rollout, so Rindler drives the storefront search input directly. Carts are also scoped per store: switching stores shows a different cart.

**add_to_cart adds exactly one unit.** Once an item is in the cart Instacart swaps the Add button for a quantity stepper, so a repeat call is a safe no-op and the response's data.item_added tells you which case you hit. To order more than one unit, call view_cart and then increment_quantity per extra unit. Do not call add_to_cart in a loop.

**Delivered and active orders behave differently.** reorder only works on delivered orders; in-progress orders do not show the add-all button. Active orders are edited instead through view_order_items and update_order_item_quantity. Also, view_orders only populates after select_store has warmed a store session, and a cold direct navigation to an order can throw a transient 'Something went wrong' page; the fix is simply to retry view_order.

**Filters are dynamic.** The filter set on a listing page depends on the current category, so the mapping exposes list_available_filters actions per screen rather than a hardcoded set. Call them in context.

The agent builds the order; your user pays. The chain is strict: view_cart opens the cart dialog, go_to_checkout moves to the checkout aisle (an upsell page), continue_to_checkout advances past it to the real checkout, and get_checkout_url is the terminal action. It returns the checkout page URL with the 'Fast' delivery tier preselected by default.

One constraint matters: that URL contains a session ID bound to Rindler's active browser session, so it cannot be opened in a different browser. Present it to the user and let them complete payment there. The agent never touches card entry.

Instacart uses email OTP. The login action takes an email, Instacart sends a verification code, and the user supplies that code through Rindler's staged Connect form. The login page is instacart.com/accounts/login, and Rindler tracks the session via Instacart's own auth cookies afterward, so your agent does not re-authenticate every session.

select_store, search_products, view_product, and result paging are not marked auth-gated in the mapping. Sign-in gates the stateful actions, including view_cart, add_to_cart, view_orders, the checkout chain, update_order_item_quantity, and address and payment method management.

Every mapped surface is a named screen: landing, storefront, search_results, product_detail, checkout_aisle, checkout, orders, order_detail, addresses, and payment_methods. Your agent always knows which screen it is on and what actions apply there.

The richest structured read is order history. view_orders returns data.listings with one record per order, most recent first: an order_url (its trailing path segment is the order_id you pass to view_order or reorder), a summary with store, status, and date, and the total. Up to 5 orders come back per call; when more exist, data.listings_truncated flips true and data.listings_total carries the full count. Cart writes are legible too: add_to_cart reports data.item_added so the agent knows whether it clicked a fresh Add button or hit an item already in the cart.