LandfallDocs
Triggering integrations · Sentry

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.

Sentry
issue-alert rule fires
Webhook action
Sentry's own JSON body
Landfall
opens an incident

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:

Terminal
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 URLhttps://api.landfalls.ai/triggers
HeaderAuthorization: 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 fieldBecomes
data.event.title / .message / .culpritThe incident title, in that order of preference. Defaults to "Sentry issue" if none are present.
data.event.levelSeverity: fatal → sev1, error → sev2, everything else (warning, info, debug) → sev3.
data.event.timestampThe incident's occurrence time, parsed from Sentry's epoch-seconds value.
data.event.projectThe 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.culpritAppended 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:

Terminal · Worked example
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 seeWhat it means
401The 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.
422The 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 attachedExpected 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 deliveryYou'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 issueEvery 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

EndpointPOST https://api.landfalls.ai/triggers
AuthAuthorization: Bearer <ingest token> identifies the organization directly; there is no org path parameter
Mint a tokenPOST https://api.landfalls.ai/o/<your-org>/triggers/ingest-token
Accepted shapesDatadog webhook, Coralogix alert, CloudWatch alarm, Sentry issue alert — one endpoint, one token
Each deliveryOpens one new incident: no dedup, no auto-close on resolve
Rejected payloads422, no incident created; a missing or invalid token is a uniform 401