Watch a live product demo 👀 See how Sanity powers richer commerce experiences

Webhooks (Legacy)

Add webhooks to your project that are triggered when content changes.

This article is deprecated

This article bcame deprecated with the release of Groq-powered webhooks in API v2021-10-04! To learn about the current webhook API, click this link.

If you need to emulate the legacy webhook behavior using the current API, visit this help article.

Webhooks allow you to build or set up applications which subscribe to events inside of your Sanity datasets. When an event is triggered, we'll send an HTTP POST payload to the webhook's configured URL. Webhooks can be used to send emails when documents are published, trigger a website build, update a backup, notify Slack when content changes and many other creative and useful scenarios. You're only limited by your imagination.


A webhook is called every time a published document is changed, created or deleted. If you are not interested in all of these events, you will currently have to filter based on the delivered payload.

Example payload

POST /your-endpoint HTTP/1.1

Connection: close
Accept-Encoding: gzip
Content-Length: 303
Content-Type: application/json

  "transactionId": "28711ce3-07c4-4c8f-8577-fc8f3c4cbde0",
  "projectId": "3do82whm",
  "dataset": "production",
  "ids": {
    "created": [],
    "deleted": [],
    "updated": [
    "all": [

As you will see, the delivered payloads include an object of created, updated and deleted ids. It is then up to the consumer to fetch the documents (if necessary) and trigger whichever action is wanted.

The all array contains all the touched IDs, regardless of which operations were performed. For instance, a transaction could have performed both a create and an update on the same document, in which case the array would only contain the ID once.

Adding webhooks

There are two ways of adding webhooks:

  1. Using the project management console.
  2. Using the Sanity CLI tool (sanity hook create)

Debugging webhooks

Sanity will use the HTTP status code to determine if a delivery is successful:

  • 200-range will be treated as a success
  • 400-range will be treated as undeliverable, as the server said it was a client error
  • 500-range will be retried using an exponential back-off pattern before giving up after 10 unsuccessful deliveries.

To see the responses from your webserver, use the CLI tool: sanity hook logs --detailed

Was this article helpful?