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.
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 responsedata, 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 withmatch_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
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
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
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-useconfirmation_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
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 setsconfirmation_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.
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 withcontact — an email and a name, and optionally a phone number.
Response
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 ofcontact, 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.
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 asexpired 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.
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: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:interpretturns a request in plain language into the constraint objectsearchaccepts, and lists any part it could not map inunresolved.draftCartFromIntentturns 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_budgetreports 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)
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.createdand the checkout intent events.

