Source · Sentry · Verified November 1, 2026
Sentry webhook source guide
Short answer: A Hooks Sentry endpoint verifies Sentry-Hook-Signature as hex HMAC-SHA256 with the Integration's Client Secret, deduplicates by Request-ID, and normalizes events to issue.created or event_alert.triggered.
Sentry sends both issue lifecycle changes and alert-rule actions. Hooks maps the project slug, permalink, level, and culprit onto the normalized subject, so a triage agent receives the same fields regardless of which Sentry event fired.
Set up the webhook in Sentry
- In Sentry, open Settings → Developer Settings → Custom Integrations and create an Internal Integration.
- Set the Webhook URL to the endpoint's ingestion URL and subscribe to issue and alert resources.
- Copy the Client Secret into the Hooks endpoint secret.
- Enable Alert Rule Action if you want
event_alert.triggereddeliveries, then trigger a new issue.
Signature verification
| Header | Sentry-Hook-Signature: <hex> |
|---|---|
| Algorithm | HMAC-SHA256 over the raw request body, hex encoded, constant-time compared. |
| Replay window | No timestamp header; replay protection relies on Request-ID deduplication. |
| Delivery id | Request-ID header. |
- The resource comes from Sentry-Hook-Resource and the action from the body, combined as
<resource>.<action>. occurredAtuses issuelastSeen(falling back tofirstSeen) or alertevent.datetime.project.slug(falling back to name) orevent.projectbecomesproject;levelis kept on the subject.
Events Hooks normalizes
| event.type | subject | What it means |
|---|---|---|
issue.created | issue | New issue group; permalink becomes URL and culprit becomes body. |
issue.resolved | issue | Issue marked resolved. |
issue.ignored | issue | Issue muted or ignored. |
event_alert.triggered | event_alert | Alert Rule Action fired; web_url and message are mapped. |
Normalized payload
Every adapter produces this shape before filters or templates run. The raw payload and sanitized headers stay attached for audit, but filters and templates read the normalized fields.
Normalized event
{
"id": "evt_01j9m9g8h9",
"source": "sentry",
"type": "issue.created",
"action": "created",
"deliveryId": "9b1c7d3e-2a4f-4e8b-8c6d-1f0a2b3c4d5e",
"occurredAt": "2026-11-01T09:33:08.000Z",
"actor": { "type": "application" },
"project": "checkout-web",
"subject": {
"kind": "issue",
"id": "4509123456",
"title": "TypeError: Cannot read properties of undefined",
"url": "https://acme.sentry.io/issues/4509123456/",
"body": "checkout.summary in app/checkout/summary.tsx",
"state": "unresolved",
"level": "error"
}
}Filter and template examples
Filter: new issues only
{
"allow": [
{ "field": "event.type", "op": "equals", "value": "issue.created" },
{ "field": "event.subject.level", "op": "in", "value": ["error", "fatal"] }
]
}Destination: Grok Bot triage task
{
"routineUrl": "https://grok.example.com/routines/abc123",
"key": "{{secret.GROKBOT_KEY}}",
"task": "Triage {{event.project}}: {{event.subject.title}}\n{{event.subject.body}}\n{{event.subject.url}}"
}Retries and the delivery log
408, 425, 429, and 5xx responses retry with backoff and honor Retry-After; other 4xx responses fail permanently with a named code. Every attempt keeps the rendered request and the target response, so a failure points at one field or one status instead of a guess.

Common errors
| Symptom | Fix |
|---|---|
SIGNATURE_INVALID | Use the Internal Integration's Client Secret, not a DSN or auth token. Sentry signs with the Client Secret shown when the integration is created. |
Alerts never arrive | event_alert.* requires Alert Rule Action to be enabled on the integration and an alert rule that uses it. |
The same issue fires repeatedly | Sentry sends an issue event per state change. Filter issue.created rather than matching by title, and use Request-ID deduplication for retried deliveries. |
Pair with a target
Reference
- Receiving eventshttps://hooks.events/docs/receive-events.md
- Verify signatureshttps://hooks.events/docs/signatures.md
- Payload templateshttps://hooks.events/docs/templates.md
Other sources
<event>.<action> (for example issues.opened) before any destination filter runs.StripeA Hooks Stripe endpoint verifies Stripe-Signature as HMAC-SHA256 over <timestamp>.<raw body> with a five-minute tolerance, then normalizes each event to <resource>.<action> such as invoice.payment_failed.SlackA Hooks Slack endpoint verifies X-Slack-Signature as HMAC-SHA256 over v0:<timestamp>:<raw body>, answers the url_verification handshake itself, and normalizes messages to app_mention.received or message.<channel_type>.LinearA Hooks Linear endpoint verifies Linear-Signature as hex HMAC-SHA256 over the raw body, rejects payloads whose webhookTimestamp is more than 60 seconds old, and normalizes events to issue.create, issue.update, and comment.create.GitLabGitLab project webhooks cover pushes, merge requests, pipelines, issues, notes, and releases.ShopifyShopify app webhooks send topic-scoped events such as orders/create, products/update, and refunds/create.IntercomIntercom sends conversation and contact notification topics, signed with the app client secret.ZendeskZendesk webhooks cover ticket, user, and organization events, signed with a timestamp plus body HMAC.JiraJira Cloud webhooks cover issue creation, updates, comments, and sprint changes.PagerDutyPagerDuty v3 webhooks cover incident trigger, acknowledge, resolve, and annotation events.Standard WebhooksStandard Webhooks deliveries carry webhook-id, webhook-timestamp, and base64 v1 signatures.SvixSvix Play and the Svix dispatcher use the Standard Webhooks headers with svix- prefixes.VercelVercel webhooks cover deployment, integration, project, and domain events.TwilioTwilio status callbacks cover messages, calls, and recordings, signed over the URL and form parameters.DiscordDiscord interaction webhooks use Ed25519 signatures plus a PING handshake.Generic HMACGeneric sources sign timestamp.deliveryId.body with HMAC-SHA256 and send the signature in x-signature.BitbucketBitbucket Cloud repository webhooks cover pushes, pull request changes, and issue events.