Events

GET /v1/address/:address/events (owner session) is one newest-first stream of what happened to your orders, so a bot does not have to poll the listing, offer, collection-offer, and purchase histories separately.

curl -s "$API/v1/address/bc1q.../events?limit=50" -H "x-session-token: $TOKEN"

The JSON response contains result and next_cursor.

Kind	Role	When
listing_filled, listing_delisted, listing_expired, listing_invalidated	seller	A listing ended
offer_accepted, offer_cancelled, offer_expired, offer_retired, offer_consumed_by_counter	bidder	An exact-target offer ended or lapsed
exact_authorization_used, exact_authorization_retired	bidder	An exact authorization settled, or was cancelled or invalidated
collection_offer_filled, collection_offer_cancelled, collection_offer_expired, collection_offer_retired	bidder	A collection offer alternative ended or lapsed (retired covers superseded siblings)
purchase_confirmed, sale_confirmed	buyer / seller	The market saw the settlement confirm

Each event carries event_id, kind, at, role, the subject’s current status, asset / collection, price_sats, the settlement txid when there is one, and whichever of listing_id, offer_id, authorization_id, parent_txid, funding_slot_id, and asset_utxo apply. Never a PSBT, a signature, or a raw transaction.

Polling

• Poll the first page and dedupe on event_id. Re-read a short overlap (for example the last minute) rather than stopping exactly at the last id you saw: several events can share one second.
• Follow next_cursor only to catch up on older events. The cursor is opaque and valid only for this route.
• at is when the market observed the event. A confirmation is stamped when the market first saw it in a block, not with the block time, so new events arrive at the head. An expiry is derived at read time and carries its expires_at, the moment it became true.
• A cancel or delist you made yourself appears too: the feed is what happened, not only what others did.

Things to know

• purchase_confirmed belongs to the fill’s buyer, which for offers is the delivery address. If your offers deliver elsewhere, offer_accepted, exact_authorization_used, and collection_offer_filled still carry the settlement txid.
• An event reflects its row’s current state. If a reorg undoes a confirmation, its *_confirmed event disappears until it confirms again.
• An on-chain spend supersedes a marketplace cancel for collection offers: a soft-cancelled offer whose funding you then spend with the hard cancel moves from collection_offer_cancelled to collection_offer_retired (status invalid), a new event_id. A cancelled exact offer whose slot you release stays offer_cancelled.
• An exact offer accepted by a seller shows offer_accepted once the market sees its funding slot spent, usually within a watch cycle of the settlement.
• Another address’s feed answers 403 forbidden; no session answers 401.

The public market feed

GET /v1/events (no session) is the whole market moving, newest first: what the activity page shows. kind=sales, kind=listings, or kind=offers narrows it to one family.

curl -sS "$API/v1/events?kind=offers&limit=50"

Kind	When
sale	A listing was bought or an offer accepted (the /v1/fills tape)
listed, delisted	A public listing was placed or ended (reason: owner, expired, invalid)
offer_placed, offer_ended	An asset offer was placed or ended
collection_offer_placed, collection_offer_ended	A collection offer was placed or ended (reason: cancelled, expired, invalid, superseded, filled)

A filled listing or offer has no separate ended event: its sale is the event. Each event carries event_id, kind, at, reason, asset / asset_longname / collection, price_sats, seller / buyer / bidder, and on sales the txid, fill_kind, and confirmed_at. Private counters, PSBTs and signatures never appear. Responses are edge-cached for 15 seconds.