Looking for every endpoint rather than the walkthrough? See the API reference.

API tokens and inbound webhooks

Two kinds of token, two directions. A write token lets your own scripts post incidents. An ingest token gives another tool a URL it can call to page you. Create both in Integrations.

Post an incident from your pipeline

A write token authenticates against the same endpoints the dashboard uses, so a failed deploy can open an incident before anyone opens Slack.

curl -X POST https://api.incidentflare.com/v1/incidents \
  -H "Authorization: Bearer $INCIDENTFLARE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Deploy 1.42 failed","severity":"P3","message":"Rolling back"}'

Resolve it from the next pipeline step by posting an update:

curl -X POST https://api.incidentflare.com/v1/incidents/$ID/updates \
  -H "Authorization: Bearer $INCIDENTFLARE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status":"resolved","message":"Rollback complete"}'

Write tokens deliberately cannot change your password or mint more tokens, so a leaked CI secret cannot take over the account. Revoke one and it stops working immediately.

Let Sentry or Grafana page you

Anything you send to /v1/ingest opens an alert and runs your escalation policy. Send the token as a header when you can — a token in a URL ends up in browser history and proxy logs.

curl -X POST https://api.incidentflare.com/v1/ingest \
  -H "Authorization: Bearer $INGEST_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Queue backed up","dedup_key":"queue","severity":"critical"}'

Sentry and Grafana only let you paste a URL, so the token may also travel in the path: https://api.incidentflare.com/v1/ingest/ift_i_…. Treat that URL as the secret it is, and revoke the token if it leaks.

• dedup_key — a flapping source re-sending the same key will not open a second page. Send {"status":"resolved","dedup_key":"queue"} when it recovers.
• incident: true — also opens a public incident, so customers see it without you touching the dashboard. Sentry and Grafana send a fixed payload and cannot set it, so their alerts page you privately and the Alerts page carries a Publish to status page button for the moment you decide customers should know. Publishing links the two: resolving the alert resolves the incident.
• Native payloads — Grafana alert bodies and Sentry issue webhooks are understood as-is; no transformer needed. Grafana’s fingerprint becomes the dedup key, so a re-fire never double-pages and its resolve notification closes the alert. Sentry’s action is respected: resolving or ignoring an issue stands the alert down, and assigning or commenting on one alerts nobody.
• Resolving — a resolve closes the public incident that the alert opened, and emails everyone subscribed to the page.