Incoming API

If something in your stack can detect a problem and send an HTTP request, it can create alerts in Warrn. Add the Incoming API integration on a team or service, copy the URL it gives you, and POST your alerts to it. You can send Warrn’s native schema or map the JSON your source already produces. This is the right choice when:

You want a simple URL to give to a script, a monitoring tool, or a homegrown system.
You don’t want to manage API keys or set request headers.
The alerts should always land on the same team (or same service).

If you instead want one API key that can create alerts on different teams from one place, use the Alerts REST API.

Set it up

Add the integration

Open the team or service you want alerts to land on, go to the Integrations tab, and add Incoming API.

Added on a service → alerts go to that service (and are routed to the service’s team).
Added on a team → alerts go straight to the team.

Warrn will show you a URL that looks like:

https://api.warrn.io/integrations/webhook/<your-key>

Copy it. Anyone with this URL can create alerts on this team or service, so treat it like a password.

Create your first alert

Send a POST to the URL with a JSON body. The only thing you need is a name.

curl -X POST "https://api.warrn.io/integrations/webhook/<your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High CPU on web-01",
    "description": "CPU has been above 90% for 5 minutes.",
    "severity": "high",
    "alert_alias": "cpu-high-prod-web-01",
    "tags": ["infrastructure", "cpu"],
    "metadata": {"host": "web-01", "region": "us-east-1"}
  }'

You’ll see the alert appear in Warrn within a second.What you can send:

Field	What it’s for
`name` (required)	The headline you’ll see in the alert list
`description`	More detail, shown on the alert page
`severity`	`critical`, `high`, `medium`, or `low`. Defaults to `medium` if you don’t set it.
`alert_alias`	A stable name you choose for this alert (e.g. `cpu-high-prod-web-01`). See “Stop duplicate alerts” below.
`tags`	A list of strings for filtering and search
`metadata`	Any extra JSON you want to keep with the alert (host names, links to graphs, runbook URLs)

Map an existing payload (optional)

If the sending system cannot change its JSON, select Map existing JSON during setup. Paste a representative payload and choose Map & preview. Warrn AI proposes the JMESPath expressions, prefills every mapping field, and renders the alert that payload would create. Review or edit any rule before saving; subsequent previews use your edited rules without overwriting them. You can also choose Remap with AI explicitly.For example, a source payload shaped like this:

{
  "alert_type": "PIPELINE_DISABLED",
  "severity": "HIGH",
  "data": {
    "display_message": "Pipeline disabled",
    "integration_id": "42",
    "recommendation": "Enable the pipeline to resume replication."
  }
}

can use these mappings:

Warrn field	JMESPath expression
Name	`data.display_message \|\| alert_type`
Description	`data.recommendation`
Severity	`severity`
Deduplication key	`join(':', [alert_type, data.integration_id])`
Tags	`[alert_type]`
Additional properties	`data`

Warrn normalizes supported severity values to lowercase, so HIGH becomes high. Use || for fallbacks and join() to construct stable values such as a deduplication key.The additional-properties mapping is stored in the alert’s metadata. Mapping data promotes every field inside that object into directly addressable additional properties. Use @ to put the complete source object there, or construct a smaller object such as {environment: data.env, region: data.region}. Warrn also retains the untouched request under metadata.raw_payload, regardless of the mapping.Use the preview in setup to confirm the resulting alert and expand its additional properties before saving. The mapping belongs to this integration URL; another Incoming API integration can use a completely different payload shape.

Tell Warrn when the problem is fixed

When the issue clears on your side, POST to the same URL with status: "resolved" and the alias you used when you created the alert. For custom payloads, map the source’s lifecycle and identity fields to status and alert_alias; the same mapping is used for create and resolve events.

curl -X POST "https://api.warrn.io/integrations/webhook/<your-key>" \
  -H "Content-Type: application/json" \
  -d '{"status": "resolved", "alert_alias": "cpu-high-prod-web-01"}'

Warrn finds the matching open alert and closes it. If there’s nothing open with that alias (already resolved, or never fired), you’ll still get a 200 OK so you can safely retry without worrying about duplicate close events.

Stop duplicate alerts with `alert_alias`

If your system fires the same alert every minute until the problem is fixed, you don’t want Warrn to create a new alert every minute. That’s what alert_alias is for. Pick a name that’s unique to the thing being alerted on, not unique per fire. Good examples:

cpu-high-prod-web-01
disk-full-db-primary
payments-error-rate-checkout-service

Send the same alias every time the alert fires. While the first alert is still open or acknowledged, Warrn updates its counter instead of creating a new one. After someone resolves it (or you send the resolve webhook), the next fire creates a fresh alert. This is also what lets you close the alert without ever having to remember its Warrn ID - you just send the alias back when the problem is fixed.

What this integration doesn’t do

No acknowledge over webhook. You can create alerts and resolve them via this URL, but acknowledging happens in the Warrn UI or via the REST API.
One destination per URL. Each URL is tied to one team or service. If you want one credential that can create alerts on any team, the REST API is the better fit.

Incoming API vs REST API

	Incoming API (this page)	REST API
How you authenticate	Key is part of the URL	Bearer token in a header
Where alerts go	Always the team or service you set up the URL on	You pick a team per alert
What’s in the body	Warrn’s native fields, or any JSON with a configured mapping	`name`, `description`, `severity`, `team_id`
What you can do	Create alerts, resolve by alias	Create, acknowledge, resolve, list, search
Best for	Giving a URL to a tool or script that just needs to fire alerts at one place	Custom scripts, CI jobs, anything managing alerts across multiple teams

​Set it up

​Stop duplicate alerts with alert_alias

​What this integration doesn’t do

​Incoming API vs REST API

Set it up

Stop duplicate alerts with `alert_alias`

What this integration doesn’t do

Incoming API vs REST API