Skip to content

Webhooks

Webhooks are real-time notifications that Depop sends to your server whenever something happens to your or your user's shop, for example when an item sells.

Instead of polling the API to find out what changed, you register a publicly accessible HTTPS URL and we send an HTTP POST request to it whenever an event you have subscribed to occurs. This means you can react immediately — updating your inventory, syncing other platforms, or starting order processing — and it reduces the risk of overselling if you list the same product elsewhere.

Event types

Every event has a versioned name in the format <version>:<resource>.<action>. We currently support the following events:

Event type Sent when
v1:order.new A new order is placed for one of your listings
v1:order.refund An order is fully or partially refunded
v1:order.update An order is updated, for example when it is marked as shipped
v1:product.like A Depop user likes one of your listings
v1:product.unlike A Depop user removes their like from one of your listings
v1:product.update One of your listings is updated

The payload of each event is documented in the API Reference.

Wildcard subscriptions

When subscribing, you can either name events in full (e.g. v1:order.new) or use a wildcard to subscribe to a group of events:

  • v1:* — all v1 events
  • v1:order.* — all order events
  • v1:product.* — all product events

Wildcards also automatically subscribe you to any new events we add in the future which match that scheme. A wildcard must specify an event version and can optionally name a full resource — partial matches such as v1:ord* or v1:product.u* are not valid.

Payload format

All webhooks share the same envelope:

{
  "id": "a210923f-c1f3-4d84-a2bd-7f18c68553e2",
  "event_type": "v1:order.new",
  "created_at": "2025-01-01T00:00:00Z",
  "data": { ... }
}

The data object is specific to each event type — see the API Reference for the full schemas.

De-duplicating order webhooks

For the order webhooks (v1:order.new, v1:order.refund, v1:order.update) the id is derived from the purchase ID, so it is stable per order and shared across those event types rather than unique per delivery. Combine it with event_type and created_at if you need to de-duplicate.

Managing your webhooks

You can manage your webhook configurations yourself using the webhook configuration endpoints:

  • POST /api/v1/webhooks/ — create a configuration with a URL and the event types you want
  • GET /api/v1/webhooks/ — list your configurations
  • PATCH /api/v1/webhooks/{webhookConfigId}/ — update a configuration, for example to change the subscribed events or temporarily disable it
  • DELETE /api/v1/webhooks/{webhookConfigId}/ — delete a configuration

A few rules apply:

  • The URL must be a valid, publicly accessible HTTPS URL.
  • Each URL can only be registered once — creating or updating a configuration to a URL that another one of your configurations already uses returns a 409 Conflict.
  • You can have a maximum of 10 webhook configurations at any time.
  • A configuration can be disabled ("enabled": false) to pause deliveries without deleting it.

If you haven't set up a webhook before, the Your first webhook guide walks through the whole flow end to end.

Security

When you create a webhook configuration, the response includes a secret. This is shown only once, at creation time — it is never returned again, so store it securely. We use it to sign every webhook we send to that URL via the X-Depop-Signature header, which lets you verify that a request genuinely came from Depop.

See Validate webhooks for how to verify the signature.

Delivery

Webhooks are delivered on a best-effort basis. Don't rely on them as your only source of truth — use the orders and products endpoints to reconcile periodically, so a missed delivery doesn't leave your systems out of sync.

Your endpoint should respond quickly with a 2xx status code to acknowledge receipt. If you need to do heavy processing, acknowledge first and process asynchronously.