Opening a war room from a Sentry alert
This page is about opening incidents automatically the moment a Sentry issue-alert fires. It is not about reading telemetry — if you want the investigation agent to query your Sentry issues/events once an incident already exists, see Connecting Sentry instead. The two are independent, and most teams eventually set up both.
How it works
Sentry's own Internal Integration webhook action (or an alert rule's "Send a notification via an integration" webhook) posts a fixed body — unlike Datadog and Coralogix, there is no template for you to write. Landfall recognizes the shape Sentry sends and maps it directly; you only need to point Sentry at the right URL with the right header.
Sentry posts to the same endpoint every other automated source uses — POST /triggers — authenticated by the same per-tenant bearer ingest token as Datadog/Coralogix/CloudWatch. Landfall works out which platform sent the alert from the shape of the body, not from a URL path or a header naming the provider, so there is one URL and one token for every source (see Datadog & Coralogix alerts for how the same endpoint handles those).
What you'll need
- An admin seat on your Landfall organization, to mint the ingest token below.
- An Internal Integration in Sentry with a Webhook URL field, or an alert rule with a webhook action (Sentry → Alerts → Rules).
- At least one issue-alert rule already configured — this guide doesn't create one.
1. Mint a trigger ingest token
If you've already minted one for Datadog, Coralogix, or CloudWatch, reuse it — the same token works for every source on this endpoint. Otherwise, this doesn't have a settings-page UI yet, so it's two API calls, made once with your own Landfall account:
SESSION=$(curl -s -X POST https://api.landfalls.ai/auth/login \
-H "Content-Type: application/json" \
-d '{"email":"<you>","password":"<your password>","orgSlug":"<your-org>"}' \
| jq -r .accessToken)
curl -X POST https://api.landfalls.ai/o/<your-org>/triggers/ingest-token \
-H "Authorization: Bearer $SESSION"2. Point Sentry at Landfall
In Sentry, open your Internal Integration (or create one — see Connecting Sentry for that same integration's read token, if you want both in one place) and set its Webhook URL:
| Webhook URL | https://api.landfalls.ai/triggers |
|---|---|
| Header | Authorization: Bearer <your ingest token> |
| Alert Rule Action | "Send a notification via <your internal integration>" on the alert rule(s) you want to open a war room |
Sentry's own Sentry-Hook-Signature header (an HMAC-SHA256 over the body) is documented but not verified by Landfall for this integration — authentication here is entirely the bearer ingest token above, the same mechanism every shared-endpoint source uses. If you're curious why, see Integrations Architecture.
What Sentry's fields become
| Sentry field | Becomes |
|---|---|
| data.event.title / .message / .culprit | The incident title, in that order of preference. Defaults to "Sentry issue" if none are present. |
| data.event.level | Severity: fatal → sev1, error → sev2, everything else (warning, info, debug) → sev3. |
| data.event.timestamp | The incident's occurrence time, parsed from Sentry's epoch-seconds value. |
| data.event.project | The affected service/entity, when Sentry's payload carries a project slug. Sentry's current webhook shape sends this as a numeric project id, not a slug — when only the numeric id is present, the incident still opens correctly, just without a resolved service attached to it (no name is guessed). If you need the service attached automatically, configure Sentry's older per-project "WebHooks" plugin instead, which sends a guaranteed project_slug field. |
| data.event.culprit | Appended to the incident's summary line as context. |
Landfall recognizes a body as Sentry's when it carries an event_id alongside an issue_id or issue_url (the shape above) — or, for the legacy WebHooks plugin, a top-level project_slug alongside a nested event id. This check runs only after CloudWatch, Datadog, and Coralogix, so it can never change how those three are already recognized.
3. Test it
Sentry's Internal Integration settings have no built-in "send test payload" button for the webhook action, so the fastest check is posting a realistic body yourself — this is close to what a real issue-alert delivery looks like:
curl -i -X POST https://api.landfalls.ai/triggers \
-H "Authorization: Bearer <your ingest token>" \
-H "Content-Type: application/json" \
-d '{
"action": "triggered",
"actor": { "id": "sentry", "name": "Sentry", "type": "application" },
"data": {
"event": {
"event_id": "e4874d664c3540c1a32eab185f12c5ab",
"project": 1,
"issue_id": "1117540176",
"issue_url": "https://sentry.io/api/0/issues/1117540176/",
"level": "error",
"title": "ReferenceError: heck is not defined",
"culprit": "?(<anonymous>)",
"timestamp": 1566248777.677
},
"triggered_rule": "Very Important Alert!"
},
"installation": { "uuid": "a8e5d37a-696c-4c54-adb5-b3f28d64c7de" }
}'Opens an incident titled ReferenceError: heck is not defined at sev2 (from error) — with no service attached, since this fixture carries only a numeric project id.
Troubleshooting
| What you see | What it means |
|---|---|
| 401 | The token is missing, malformed, or no longer current. Minting a new ingest token invalidates the previous one — check the Internal Integration's Webhook URL header has the latest. |
| 422 | The body matched none of the four known shapes, and no incident was created. Confirm the Alert Rule Action is actually "Send a notification via" your Internal Integration, not a different notification type. |
| An incident opens, but with no service attached | Expected when Sentry's payload carries only a numeric project id (the current default shape) — see the field-mapping table above. Not a bug to fix; a provenance-only entity is opened rather than guessing a name. |
| No Sentry-Hook-Signature header on the delivery | You're using the legacy per-project "WebHooks" plugin rather than an Internal Integration — expected, and fine: Landfall doesn't verify that header either way, and the legacy shape is recognized too (it's the one that reliably carries a project slug). |
| Two incidents for one issue | Every delivery opens its own incident: there is no dedup and no auto-close on resolve, matching every other shared-endpoint source (Datadog/Coralogix/ CloudWatch). If your alert rule fires repeatedly for the same issue, narrow the rule's trigger conditions in Sentry. |
Reference
| Endpoint | POST https://api.landfalls.ai/triggers |
|---|---|
| Auth | Authorization: Bearer <ingest token> identifies the organization directly; there is no org path parameter |
| Mint a token | POST https://api.landfalls.ai/o/<your-org>/triggers/ingest-token |
| Accepted shapes | Datadog webhook, Coralogix alert, CloudWatch alarm, Sentry issue alert — one endpoint, one token |
| Each delivery | Opens one new incident: no dedup, no auto-close on resolve |
| Rejected payloads | 422, no incident created; a missing or invalid token is a uniform 401 |