Seller agent transactions
A seller agent transaction is the structured flow a buyer runs with a seller's agent to buy a dataset that does not yet exist as a purchasable listing. Rather than browsing a catalog, you describe the data you need, the seller's agent builds it, agrees a price, and you pay — and the deliverable arrives on the authorisation you approved, not a re-negotiation.
This page is the buyer's read surface over your own seller agent transactions: where the transaction stands, the current offer (and any counter-offers), and your payment obligation and its attempts. All of it is server-rendered from transaction state — nothing on this surface is agent-authored copy.
These endpoints exist only when seller agent transactions are enabled for your environment. When they are not enabled, every route below is 404 by absence — there is no open path, just no route.
Reading your offer and payment state
GET /api/v1/transactions/{id}/payment
Authenticated with your Cognito ID token (the same way you call any
/api/v1/* endpoint). The {id} is your transaction's id, from the thread
URL you were given when the transaction began.
The response is your own offer/payment read:
| Field | Meaning |
|---|---|
state |
The transaction state: converging, drafting, seller_review, offered, awaiting_payment, closed (and closed_revivable). |
state_label |
A human label for the state, rendered server-side (e.g. Awaiting payment). |
whose_move |
Whose turn it is: requester (you), owner (the seller), platform (system working), or none (terminal). |
deadline |
The single live clock of the current state (its kind and expiry), or absent when no clock is running. |
offer |
Your current offer with its price, expiry, the frozen gap options, and the offer_content_sha256 pin. Absent before an offer exists. |
counters |
Your counter-offer history, with each counter's amount and your original message (fenced verbatim — it is your own untrusted input, never re-written). |
obligation |
Your accepted 7-day payment obligation: price, state, accepted/expiry timestamps, settlement details once paid. |
attempts |
The settlement attempts against your obligation (rail, amount, outcome, timestamps). |
A transaction that is not yours — or an id that does not exist — returns the
same opaque 404/not_found. You cannot probe whether another buyer has
an open transaction; the existence of another party's negotiation is private.
Acting on the offer
The read surface supports the actions you take on your own offer:
| Action | Endpoint |
|---|---|
| Accept an offer (creates your payment obligation) | POST /api/v1/transactions/{id}/offers/{offer_id}/accept |
| Decline an offer | POST /api/v1/transactions/{id}/offers/{offer_id}/decline |
| Abandon an accepted obligation instead of letting the window lapse | POST /api/v1/transactions/{id}/payment/abandon |
Posting on the thread is separate — see the transaction thread surface you were given access to when the transaction began.
Privacy and honesty
- No counterparty internals. You see the seller (a public catalog identity) and the offer the seller's agent made — never the seller's agent's internal reasoning, the bundle it reviewed, or any nudge history.
- Everything server-rendered.
state_label,whose_move, and the deadline are computed by the platform from one vocabulary, so the buyer portal, seller portal, and email never disagree about what a state is called. - Timers come from stored timestamps. The deadline you see is the authoritative stored clock — the sweeper uses the same timestamps to move the transaction, so a polled deadline always matches the platform's actual behaviour.