Where agents can buy
Here are a few examples of merchants supported today:Flights
GET /buy/merchants with the same bearer token you send to /buy.
What you need
- A user with a card in the Vault (Adding a card).
- A user-scoped bearer token.
/buyalways runs as a single user, so org tokens are rejected.- Use the user’s connection
access_token, or mint abuy_tokenfor a cardholder you own:
Quickstart
Every call is aPOST /buy. A single purchase follows a turn-based loop, tied together by conversation_id.
1) Start (send an ask)
2) Loop: reply → ask (until a cart is ready)
If the API needs more info, it responds withstatus: "needs_input" and a natural-language reply.
Show reply to the user, then send the user’s answer back as the next ask with the same conversation_id:
3) Read the cart (use structured fields)
Once the API has enough details, the response includes acart and a cart.hash. Use these structured fields (not the prose) to show the user exactly what will be purchased.
unmatchedlists anything requested that didn’t make it into the cart (plus a reason). Show it instead of guessing from the prose.- The status can still be
needs_inputhere, because the API is asking for confirmation. - If the user wants a change (for example, “make it two bags”), send that as another
ask. You’ll get an updated cart with a newhash.
4) Confirm the cart hash (and choose a payment source)
When the user wants to proceed, confirm the exact cart you showed by sending thecart.hash (not a free-form “yes”). To pay with the user’s own card, pass payment_source: "vault".
5) If approval is required: send the approval URL, then retry confirm
A confirm may pause while the user approves:approval_url to the user. After they approve (Face ID), repeat the same confirm call from step 4.
When the purchase is placed:
The fields you branch on
Edge cases
If the price changed
A confirm authorizes one cart at one price. If anything drifted since the cart was shown, confirm returns409 with a fresh cart and a new hash. Show the user the new total, then confirm the new hash.
Track the order
Retail orders confirm asynchronously (often ~1 minute after placement).order.placed and order.confirmed webhooks instead of polling.
If a confirm times out
Don’t resend. First, read the conversation:turn_in_progress to clear, then check orders. A duplicate confirm while a turn is running returns 409 turn_in_progress, so the same cart can never place twice.
Over MCP
The same loop is available as thebuy tool on https://mcp.agentcard.sh/mcp, using the same bearer. The agent relays each turn, the user confirms in words, and the tool places the order.
Sandbox
Sandbox runs the real loop against real merchants up to the confirm. The confirm returnsdeclined with decline_code: "sandbox_mode" by design, because sandbox cards can’t pay a real merchant. Everything before it (conversation, cart, hash) is identical to production.