sentry: add 16 doc-sourced samples

[garethx]

New provider: Sentry Integration Platform webhooks. This is the last stage of the add-a-source pipeline. Before it came the skill (hookdeck/webhook-skills#212), the core source type (hookdeck/core#5771), the registry row (hookdeck/webhook-registry#85, with citation fixes in #86) and the check record (hookdeck/webhook-registry-checks#17).

• Bodies: 16 complete example deliveries, verbatim from the nine event pages under docs.sentry.io/integrations/integration-platform/webhooks. They were read from the pages' .mdx sources in getsentry/sentry-docs. No example on any of the nine pages elides an object, so every body is exported whole.

• Not included: 13 of the 29 documented event types have no published body. The docs give one example per resource, so the other actions of each resource are described in prose only:

  • comment: updated, deleted
  • installation: deleted
  • issue: resolved, assigned, unresolved, ignored
  • metric_alert: critical, warning, open
  • seer: pr_ready_for_review, iteration_started, iteration_completed

  Swapping action on a sibling body would ship a payload Sentry never published.

• Topic names are composed: resource.action (issue.created, event_alert.triggered, seer.pr_created). The body carries no event type. The resource travels only in the Sentry-Hook-Resource header and the verb in body.action. These are the tokens Sentry's own server enum (SentryAppEventType) uses.

• topic_identifier: sentry-hook-resource, matching the github precedent (resource in a header, verb in body.action). There's a known limitation for future captures. requestReceiver.ts resolves one field, so a real Sentry delivery would be named by resource only (issue.json, seer.json), and all seven seer actions would land on one name. Naming these doc samples by header value would have collapsed 16 samples into 9 topics, so they're named by the composed token instead, and every file carries an explicit topic. Strava, the other composed-key provider here, took the opposite trade-off (topic_identifier: null). Either is defensible, and switching is a one-line change if you prefer that.

• Headers: synthesized: content-type and sentry-hook-resource only. Without the resource header, the body alone can't say what event it is. Sentry-Hook-Signature (an HMAC keyed with an integration's Client Secret), Request-ID and Sentry-Hook-Timestamp are per-delivery values that documentation can't supply.

• Version: latest. Sentry has no webhook version scheme: no version header, no version field, no dated generations.

• Provenance: latest is sourced_via: docs, sourced_on: 2026-10-02. Each file carries source.type: vendor-documentation and its page URL.

• Preserved verbatim: metric_alert.resolved's data.description_text contains a double-escaped newline (\\n) exactly as Sentry publishes it. I didn't normalise it.

Checklist:

• There's no existing providers/sentry and no scripts/sentry harness, so no captures are displaced. Existing files changed: 0.
• Regenerating the registry harvest (harvest_sentry.py at webhook-registry 1215f4b) into a scratch tree is byte-identical to the committed samples-doc/ and to these files.
• yarn compile passes: 148 → 149 providers, 16 sentry topics, no collisions. yarn test: 14/14 passed.
• Registry verify.py: FAIL (0).

Evidence and non-assertions are in hookdeck/webhook-registry#85.

🤖 Generated with Claude Code

https://claude.ai/code/session_015kRW6XJtGqr2KESnYgmE64

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
webhook-samples	Ready	Preview	Oct 3, 2026 11:08pm UTC