Skip to main content
This walks the whole loop: get a key, store a buyer, create a checkout, poll it, answer a variant question, answer a card question, read the receipt. A self-serve signup gets you a sandbox tenant. It is the real engine against a store we control — a genuinely placed order, a real variant prompt, real card entry — with no path to a real merchant. The sandbox is free with no card on file; see Sandbox for what confinement means, and Going live and Pricing for when you are ready to spend real money.
The API base URL is https://api.farthing.ai. Every authenticated call takes Authorization: Bearer <your key>.

1. Sign up

Response (201)
apiKey is shown exactly once. Only a SHA-256 hash is stored — there is no endpoint, no support process, and no database query that can recover it. Lost key means POST /v1/api-keys for a new one.

2. Store a buyer profile

The agent needs somewhere to ship. A buyer profile is reusable identity and shipping detail; you pass its id when creating a checkout.
Response (201)
administrativeAreaCode is not optional in practice for US and CA addresses. Shopify will not offer a shipping method until the state/province is set, and without a shipping method the order can never be placed.

3. Create the checkout

Response (201)
Idempotency-Key is what makes a create safe to retry: send the same key twice and you get the original checkout back with 200 instead of buying the item again. A fresh uuidgen per run is right here because each run of this command is a new intent; in your own code the key should come from the purchase — a cart id, an order row — so that a retry of that purchase reuses it. See Idempotency.

4. Poll

Within a few seconds the browser is up and the agent is on the product page. When it needs something from you, pendingUserAction appears:
Response (200) — abridged timeline
Render pendingUserAction, not status. The status tells you the run is waiting; the action tells you what to put on screen. Answering it returns the checkout to running.
browser.embedTokenUrl marks that a browser exists. POST to it to mint a short-lived viewable URL — see Live view.

5. Answer the variant

Read responseSchema.properties, build an object with the same keys, and submit:
The response is the full checkout again, with pendingUserAction gone. The run resumes: it adds the variant to the cart, walks the checkout, fills contact and shipping from your buyer profile, and picks a shipping method.

6. Answer the card

At the payment step the run stops again. This action always has exactly the same shape, whichever engine drove the checkout:
pendingUserAction
Use single-use or agent-issued card numbers. Raw values go to a transient, delete-on-read store and are erased once the step that types them completes; only a redacted copy is kept for audit. That is a good posture, not a vault — do not send a card you would mind seeing used exactly once.
The cardholder name is never asked for. It comes from the buyer profile.

7. Receipt

Final poll (200) — abridged

The same flow in TypeScript

No SDK yet — this is plain fetch and it is the whole client. Node 20+ or any modern runtime.
checkout.ts

Next

Checkout lifecycle

Every status, every failure reason, and what actually causes each one.

User actions

The full human-in-the-loop contract: keys, schemas, TTLs, decline.

Webhooks

Stop polling. Signature verification included.

Going live

What a sandbox tenant cannot do, and the three self-serve facts that lift it.