Promptwatch Logo

Sanity Webhooks

Sanity's webhook service that delivers real-time event notifications for content changes and other events.
Sanity
Webhook

What is Sanity Webhooks?

Sanity Webhooks reacts to changes in a project's Content Lake. A webhook configuration chooses create, update, or delete triggers, then applies a GROQ filter to decide which documents qualify. Its GROQ projection builds the JSON body sent to the configured URL. Draft and version documents are ignored by default unless their delivery is enabled in the webhook settings.

The request method is configurable, and Sanity includes Sanity.io webhook delivery as the user agent. A configured secret produces a signature in sanity-webhook-signature. The official @sanity/webhook toolkit checks that signature against the raw body and shared secret. A project can also add an HTTP header such as Authorization when the receiving service requires another credential.

Sanity uses at-least-once delivery and supplies an idempotency-key header for duplicate detection. A webhook can have one request in flight at a time, and an attempt times out after 30 seconds. Sanity retries a 429 or 5xx response twice at 30-second intervals. Other 4xx responses are treated as undeliverable rather than retryable.

These requests move selected content-change data between Sanity and an application chosen by the project owner. They do not crawl the receiving site and have no documented role in AI search or model training. robots.txt cannot control the configured method, payload, or delivery of a webhook.

Not relevant for AI search

Is Sanity Webhooks relevant for AI search?

No. Sanity Webhooks is not part of AI search or training, so allowing or blocking it does not change your AI visibility.

Sanity Webhooks is not a crawler. It delivers webhook notifications to endpoints you registered, so it never fetches public content for an AI product. Robots.txt does not apply, and allowing or blocking it has no effect on AI search or training.

How to handle Sanity Webhooks

Keep each webhook's filter and projection limited to the documents and fields the receiver needs. Set a separate random secret, retain the body as text until verification finishes, and use @sanity/webhook or next-sanity/webhook to validate the signature. Reject an invalid signature before triggering a build, cache purge, or data update.

Store idempotency-key before applying the payload so a retry cannot repeat the action. Return a 2xx status after durable acceptance. Use 429 or a 5xx response only when another attempt could succeed, since Sanity retries those responses twice but does not retry ordinary 4xx failures.

The attempts log shows the response recorded for each delivery. Disable or delete the webhook in Sanity when it should stop, or remove the relevant trigger. A robots.txt entry would not change this outbound configuration.

Examples

  • Publishing an updated `post` document matches a GROQ filter. Sanity sends the projected slug to a signed endpoint, which verifies the body and revalidates that page.
  • A receiver returns 500 during an outage. Sanity makes two more attempts 30 seconds apart, and the shared `idempotency-key` prevents repeated processing if an acknowledgment is lost.
  • Deleting a document triggers a projection containing its ID. The application removes the corresponding record from its own site search without requesting any other Sanity documents.

Frequently asked questions about Sanity Webhooks

Learn about AI visibility monitoring and how Promptwatch helps your brand succeed in AI search.

The webhook's selected create, update, or delete event is checked first, followed by its GROQ filter. The projection then determines the JSON body.

Be the brand AI recommends

Monitor your brand's visibility across ChatGPT, Claude, Perplexity, and Gemini. Get actionable insights and create content that gets cited by AI search engines.

Promptwatch Dashboard