Events API

Events API

Authenticate events and control incident lifecycle, correlation, idempotency, and metadata.

The canonical Events API accepts one event per request. This makes success and retry behavior unambiguous and lets every accepted delivery map to one incident transition or update.

Endpoint

POST https://api.warnfire.com/v1/events

Send events to https://api.warnfire.com/v1/events.

Authentication

Create a service and integration key , then send that key in the integration_key field of the JSON request. Never place integration keys in query strings or generic Events API URLs, where proxies, browsers, and providers commonly log them. The provider adapters that require a dedicated URL-key format document that exception separately.

The canonical field name is integration_key. Existing Events API senders may continue to use the deprecated routing_key alias during migration. Do not send both fields unless they contain the same key. PagerDuty Events API v2 uses routing_key as part of that provider protocol; it is not deprecated on the PagerDuty-compatible /v2/enqueue endpoint.

Event actions

WarnFire currently models these canonical actions:

• trigger — open an incident or add a trigger/update delivery to the active incident with the same deduplication key.
• resolve — resolve the active incident identified by the same deduplication key.
• acknowledge — record a source-side acknowledgement on the incident timeline. It never stops paging. An authorized human acknowledgement from the web or mobile app, a linked Slack responder, or the targeted voice call does stop escalation (see the incident lifecycle ).

Repeated trigger deliveries with changed visible payload values become numbered incident updates. Exact retries use client_event_id idempotency and do not double-page.

Metadata

Use the payload to provide a human-readable summary and description, severity, source, component, observed timestamp, environment, region, tags, labels, typed key/value details, and relevant links. Preserve provider timestamps in UTC with an explicit offset; WarnFire clients display them in the viewer’s local timezone.

Reference

Download the current OpenAPI document for complete request, response, field-limit, and error schemas.

Follow the implementation path

1. Send your first event to open and close a disposable incident.
2. Add client_event_id for safe retries before enabling automatic retries.
3. Review the two limits before choosing sender concurrency and backoff.
4. Configure a maintenance window when planned work should record alarms without paging responders.