Event types

Each webhook listens to one of the events below. The event name is sent in the type field of every payload, and the object it concerns in data. See Payload format for the body.

Users

The data field holds the user, as returned by GET /api/v1/users/{id}.

Event	Fires when
user.creation	A user account is created: sign-up on the marketplace, social login, creation from the back office or the API.
user.update	A user account is saved: profile, group, status, settings. It can also fire after technical updates of the account, so compare with the data you hold if only some fields matter to you.
user.delete	A user account is deleted. data holds the account as it was, or only its id and object when it no longer exists.

Listings

The data field holds the listing, as returned by GET /api/v1/listings/{id}, including its owner and supplier.

Event	Fires when
listing.creation	A listing is created, from the front office, the back office, the API or an import.
listing.update	A listing is saved: content, price, stock, status, moderation.
listing.delete	A listing is deleted, from the front office, the back office or the API. data only holds the listing’s id and object.

Orders

The data field holds the order, as returned by GET /api/v1/orders/{id}, with its customer, supplier and items. Each status has its own event, named after the status the order enters.

Event	The order enters status…	Typical trigger
order.status.draft	draft	A customer starts a checkout. The order is not paid.
order.status.pending	pending	The payment is awaited, for instance a bank transfer.
order.status.new	new	The customer has paid or validated the order. This is the “new order” event most integrations want.
order.status.accepted	accepted	The vendor accepts the order.
order.status.declined	declined	The vendor refuses the order.
order.status.shipped	shipped	The vendor ships the order.
order.status.service_provided	service_provided	The vendor marks a service as provided.
order.status.customer_confirmed	customer_confirmed	The customer confirms reception.
order.status.completed	completed	The order is completed.
order.status.failed	failed	The payment or the order processing fails.
order.status.canceled	canceled	The order is canceled, by the customer, the vendor or an administrator.
order.delete	—	The order is deleted. data only holds the order’s id and object.

When the status change comes with a comment (for instance the reason given by an administrator), the payload carries it in a top-level comment field.

Things to know

• The object is sent in its latest state, read when the webhook is delivered, not when the event happened. Two quick edits of the same listing usually produce a single listing.update showing the final version. See Delivery, retries and logs.
• Which statuses an order goes through depends on the marketplace: its payment provider, whether vendors accept orders, whether items are shipped or services. Subscribe to the statuses your workflow relies on, and read data.status rather than assuming the previous step happened.
• There is no catch-all event. To follow every order status, create one webhook per status; they can share the same URL.