Opening a war room from a remote source

This page is about opening incidents automatically from a service you host that speaks the Landfall Source Protocol. It is not about reading telemetry; if you want the investigator to query your service once an incident already exists, see Remote source instead. The two are independent, and most teams eventually set up both.

How it works

The protocol defines its own trigger payload. Your service posts it to the same endpoint every other automated source uses, POST /triggers, authenticated by the same per-organization bearer ingest token as Datadog, Coralogix, CloudWatch and Sentry. Landfall recognizes the body by its landfallSource: "remote" discriminator, checked last in the chain of known shapes so it can never change how the existing sources are recognized.

What is different from those sources is attribution. The payload names the connection it comes from, so each remote connection has its own trigger identity: the incident is attributed to that connection, its severity is taken from the payload directly (never from another source's default), and the dedup key you supply gives it the same open / attach / record / ignore handling described on Integrations architecture. The Alertmanager webhook format is not accepted as an alias; a remote source speaks its own payload.

What you'll need

• A remote source connection that is configured and currently connected, per Remote source. A payload naming a connection the organization does not have, has uninstalled, or whose last health check failed is rejected.
• An admin seat on your Landfall organization, to mint the ingest token below.
• The connection id. It is default for the first connection of a source, and shown on the connection's card for any other.

1. Mint a trigger ingest token

If you've already minted one for another source on this endpoint, reuse it: the same token works for every source. Otherwise it is 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. Post the source trigger payload

From your service, when a condition worth a war room fires, post this body. Only landfallSource, connectionId, title and severity are required:

curl -i -X POST https://api.landfalls.ai/triggers \
  -H "Authorization: Bearer <your ingest token>" \
  -H "Content-Type: application/json" \
  -d '{
    "landfallSource": "remote",
    "connectionId": "acme-metrics",
    "title": "checkout p99 > 2s",
    "severity": "sev2",
    "occurredAt": "2026-09-06T18:00:00Z",
    "entityHints": ["service:checkout"],
    "dedupKey": "checkout-p99-2026-09-06",
    "summary": "p99 latency on /checkout has been above 2s for 5 minutes",
    "url": "https://alerts.example.internal/checkout-p99",
    "kind": "trigger"
  }'

Opens an incident titled checkout p99 > 2s at sev2, attributed to the remote connection acme-metrics, with checkout as the affected service.

Payload fields

Dedup and recovery

The dedupKey is the alert's identity. Landfall decides one alert at a time against the rooms that are still open: a first trigger opens a room, a repeat trigger with the same key attaches to it as a repeat, and a body with kind: "recovery" and the same key is recorded on the open room as a fact. The room stays open: a service saying its alert stopped is not the same as the incident being over, and resolving is a person's decision. A recovery for an alert with no open room is accepted and does nothing. Once a person resolves the room, the next trigger with the same key is a new situation and opens a new room.

Attribution to the connection

Before an incident is opened, Landfall looks up the named connection in your organization: it must exist, be installed in the marketplace for this organization, and have passed its last health check. When it does, the incident's provenance badge names the remote connection, its severity basis records remote connection=<id> severity=<sev>, and the investigation that starts already has that connection in its signal catalog. A payload is never attributed to a different source by fallback.

When a payload is refused

Reference