Skip to main content
A shopping assistant helps a shopper find and buy from one store: a chat widget on the storefront, a voice interface, or an assistant in another product. The assistant’s model decides what to ask and what to suggest; the client.agent tools supply the facts it cannot know — live stock, the price the shopper is charged, the promotion that applies, shipping and tax for an address — and the checkout the shopper confirms. Agentic Commerce describes the surface as a whole, and the Agent reference documents every method. Steps 1–6 take a publishable key and are safe to call from a browser. Step 7 places an order, and step 8 takes payment on your server with the secret key. The responses are captured from a sandbox store, and each is trimmed to the fields the step uses. Workflow Examples has the client setup.
Every tool returns the same envelope: the result in data, and evidence naming the operation and field each figure was read from, alongside computed_at, currency and environment. The envelope is shown in full once, in step 2, and elided after that.

1. Registering the tools

The manifest lists every tool with its HTTP operation, a JSON Schema for its request and for its response data, the credential it needs, and a cost_class. An assistant can register its tools from the manifest rather than from a hand-written list, so a tool added to the API reaches the assistant without a code change.
Response
auth is publishable, shopper (a shopper credential is required), shopper_optional, shopper_or_guest_token, or secret. hosted_helpers_available is false on this store because the merchant has not turned the hosted helpers on; step 9 covers them. assistant is the name and logo the merchant has given their shopping assistant, each null until set, so an assistant can introduce itself the way the store does.

2. Searching with constraints

Search takes the constraints a shopper states — free text, a price range, a category, attribute values, in stock only — and returns products with match_reasons listing which constraint each one met. A model can say why a product is on the list without guessing.
Response

3. Reading one product

The product dossier carries each variant with its own price and live stock, the promotion that applies to one unit, published specifications, the review summary, the shipping zones with their base fees, and the return window. A specification the merchant has not published is absent rather than inferred.
Response
The dossier is cached at the edge for up to five minutes and purged when the catalogue changes.

4. Comparing and checking fit

compare sets two to five products side by side, with their specifications aligned into rows; a specification one product does not publish is null in its column. checkFit sorts a shopper’s constraints for one product into those it meets, those it misses, and those it cannot be judged on.
Response
The colour lands in unknown because this product publishes no color specification — the variant name says “Grey / M”, but the tool reports only what the merchant published. An assistant can ask the shopper, or read the variant names from step 3, rather than assert a colour. When a constraint is missed, alternatives lists in-stock products that meet more of them; getAlternatives returns the same kind of list directly, by similarity, lower price, stock, or matching specification.

5. Pricing a basket

A quote prices a basket the way an order is priced: each line at the price the shopper is charged, the best promotion, then shipping and tax for the address. total_is_final is true only when every line is available and both shipping and tax were priced; without an address, both report address_required and the total is not final. A line that cannot be bought is flagged with unavailable_reason, never dropped, so the assistant can tell the shopper what changed.
Response
This store’s prices include tax, so tax.amount is the share of the total that is tax and is not added to it: the grand total is the subtotal, less the discount, plus shipping.

6. Keeping a cart draft

A cart draft holds a basket the assistant is building without touching the shopper’s live cart. It carries its own quote, is re-quoted on every read, and expires after 24 hours. When the shopper wants the items in their cart, applyCartDraft adds them — that call needs the shopper’s credential.
Response
getCartInsights reads a draft or the shopper’s live cart and reports what has moved since items were added: lines no longer available, price changes, the gap to free shipping, and complementary products.

7. Creating and confirming a checkout intent

The assistant does not place the order. It creates a checkout intent, which prices the basket for the address, freezes that price, holds the stock for 30 minutes, and returns a single-use confirmation_token. The application shows the frozen quote to the shopper; the order is placed only when the shopper approves and the application confirms the intent with the token. idempotencyKey is required. A retry with the same key and basket returns the same intent without the token, so the token is kept from the first response.
Response
An intent is refused, with the current quote in error.details, when a line cannot be bought (409 items_unavailable), the store does not deliver to the address (409 shipping_not_deliverable), or shipping or tax cannot be priced for it (409 quote_incomplete).

Confirming on the store’s page

An assistant with no checkout interface of its own sets confirmation_mode: 'hosted'. The intent then also carries confirmation_url, a link to the store’s own confirmation page with the token in the URL fragment, which a browser does not send to any server. The assistant gives the link to the shopper, and the page shows the frozen quote, takes the shopper’s contact details, confirms the intent and passes payment to the store’s payment provider. In this mode the confirmation calls below and step 8 happen on the page rather than in your application.
A replay with the same idempotencyKey returns confirmation_url: null, as it does the token, so the link is kept from the first response. agent.checkout_intent.confirmed reports the confirmation either way.

Confirming for a guest

A guest confirms with contact — an email and a name, and optionally a phone number.
Response
Confirmation prices the basket again. If anything the shopper would pay has changed — a line price, the discount, shipping, tax, or the total — nothing is placed, and the response is 409 quote_changed with the new quote in error.details; the shopper decides on the new figures and a new intent is created for them. Otherwise the order is placed with payment pending, using the stock the intent held. The token works once: a second confirmation returns 409 intent_not_pending, and a wrong token returns 403 invalid_token without revealing anything about the intent.

Confirming for a signed-in shopper

A shopper who is signed in confirms with their credential instead of contact, and the order is placed on their customer record. The credential is one of xAuthToken (a Galactic Core session token), xExternalAuth (an assertion your backend signs after the shopper signs in with your own identity provider), or xIdpToken (a token from the store’s registered identity provider). Customers & auth shows how to sign the assertion.
An intent created with a shopper credential is tied to that shopper and must be confirmed with the same credential.

Reading an intent

getCheckoutIntent returns the intent’s status, lines and frozen totals to any key. The shopper’s shipping address (quote.shipping_address) and customer_id are included only for a secret key, or for a publishable key sent with a credential for the intent’s own shopper. A publishable key alone receives the intent without those two fields, because the publishable key is public and a hosted intent’s id appears in its confirmation link. The same applies to the intent returned by cancelCheckoutIntent.

Declining

An intent the shopper declines is cancelled at once, which releases its stock hold. One that is left unconfirmed reads as expired after 30 minutes and its stock is released the same way.
Response

8. Taking payment (server, signed)

A confirmed intent leaves an order with payment pending. payment.initialize_body is the body that initializePayment takes, and the call is made from your server with the secret key, an HMAC signature and an idempotency key, exactly as in Storefront checkout.
The order is recorded as an agent order: its order.created webhook carries source_channel: "agent" and agent_client_ref, which identifies the API key or connected application that created the intent. The intent itself raises agent.checkout_intent.created, agent.checkout_intent.confirmed and agent.checkout_intent.expired.

9. Supplying the reasoning

Every tool above is deterministic: structured input, structured output, read from the store’s data. The model that turns a shopper’s sentence into those calls can come from either side.

Your own model

The assistant runs on your model and calls the tools from step 1 as functions. The tools cost what any storefront request costs, counted against the plan’s normal request allowance; no Agent Compute credits are involved. A tool loop registers the manifest entries and executes each call the model makes:
The figures the model repeats to the shopper come from data, and evidence gives it a source to cite for each one.

Hosted helpers

Two tools run a model on the store’s side and are paid for from the store’s Agent Compute credits:
  • interpret turns a request in plain language into the constraint object search accepts, and lists any part it could not map in unresolved.
  • draftCartFromIntent turns an intent and an optional budget into a priced, stock-checked cart draft. It chooses only among in-stock search results, by variant, and every amount in the draft comes from the quote; over_budget reports whether the total exceeds the budget.
Response
usage.credits_debited is the amount taken from the store’s balance for the call, in US dollars. A call that fails is refunded in full. The helpers are off until the merchant turns them on, which requires automatic recharge of the credit balance. When they cannot run, they answer with an error and every deterministic tool keeps working. A publishable key receives one answer whatever the reason, so no store reads publicly as switched off or out of credits:
Response (403)
A secret key — the store’s own server — receives the reason: hosted_helpers_available in the manifest from step 1 reports whether the helpers can run before a call is made, so an assistant can leave the helpers out of its tool list and fall back to its own model. A server holding the secret key reads the balance, the recharge state and the month’s helper spend with getUsage.

What’s next

  • The Agent reference documents the shopper-scoped tools — consent, personal context, reorder suggestions, wishlist insights and order status.
  • Storefront checkout covers the same purchase built directly on the catalog, cart and order services.
  • Webhooks & automation handles order.created and the checkout intent events.