Skip to main content
Every event has the same outer shape, and its data depends on its type. To get events, see Webhooks.
string
The event’s id, evt_ and 32 hex characters. It never changes, including across retries, so dedupe on it.
string
order.completed, listing.sold or shipment.updated.
string
When the thing happened: the order finished, or the shipment’s status changed. Not when we sent the event.
object
Depends on type.
This list isn’t final. We’ll add more events without notice, so ignore a type you don’t recognize.
An event never identifies a buyer, and no part of a customer’s address is ever in one.

Order completed

order.completed: a pack order, card order or sell-back you made through the API finished. It includes an order we closed from our records after you lost its response. Orders and sell-backs made in our app send nothing. order is the same object List orders returns for it: type is pack_purchase, card_purchase or sell_back, and reconciled is true if we closed it. For its pulls or card, call Get an order with its checkout_id. From the time your webhook is set up, every finished order in List orders gives one event. A sell-back of several cards is one order, and one event, per card. If two keys on your account both have webhooks, both get it. An order held for review sends no event.

Listing sold

listing.sold: someone bought one of your listings, wherever you listed the card. order is the same object List orders returns for a sale, with type: "listing_sale". It doesn’t say who bought it. If two keys on your account both have webhooks, both get it.

Shipment updated

shipment.updated: a shipment made with this key changed status. shipment is the object List shipments returns, without destination_country and address_removed, which both come from the customer’s address. Get a shipment has them. A shipment event tells you a shipment moved, not every step it took. Get a shipment always has the current status.
  • It follows the order’s status after the order exists. Creating a shipment sends no event, because the response has already told you, and neither does a shipment coming out of needs_review.
  • Only the key that created the shipment gets it, even if another key on your account has a webhook. That key needs ship:cards as well as read:account. A key that loses ship:cards stops getting new ones, though what’s already queued still goes out. A shipment made with a key you’ve since replaced sends nothing further, and is still on List shipments.
  • Two quick changes can collapse into one event. We read each shipment’s latest status when we look for new events, so two changes between looks reach you as one event with the later status: delivered can arrive with no shipped before it. The last change is never skipped.
  • Each change has its own id, including a shipment going back to an earlier status.
  • status can repeat one you already hold, because some internal changes have the same public status. It’s still a change, with its own id.
  • An order our team removes turns cancelled with no event.
  • Delivery is unordered, so compare status_updated_at to tell which of two events is newer.