API automation
API and automation
Choose the correct WarnFire API surface, credential boundary, and retry behavior for an integration or automation.
WarnFire exposes separate public API surfaces for event ingestion, responder actions, and tenant administration. Use the narrowest surface and credential that can perform the job. A credential for one workspace never authorizes access to another workspace.
Pick the correct boundary
| Task | API boundary |
|---|---|
| Trigger, acknowledge, or resolve a monitoring event | Events API with a service integration key |
| Act as an individual responder | Responder API with that responder’s credential; see Personal API tokens for token issuance |
| Read or administer workspace configuration | Tenant API with a scoped API key ; inspect operations in the API reference |
Do not use a responder credential as a general tenant reader or reuse one integration key for unrelated monitoring sources. Separate credentials make rotation, audit attribution, and revocation local to the affected system.
Credential boundaries
WarnFire bearer credentials are not interchangeable:
- An integration key belongs to one service and can only submit events for that service.
- A responder token identifies one responder and is used for responder actions such as acknowledgement.
- A tenant API key authorizes the supported tenant operations allowed by its explicit scopes. A console session authorizes the operations allowed by that member’s role. Service-operations credentials and private support routes are not part of the public API contract.
Inbound integrations and delivery callbacks
Provider webhook adapters are inbound event sources: Alertmanager, Grafana, Datadog, cloud monitoring systems, and other monitoring tools send alert state to WarnFire. Those requests use a service integration key and enter the normal event-ingestion path.
Delivery callbacks serve a different purpose. Messaging providers such as Twilio, Telnyx, and Amazon SES report the outcome of a notification WarnFire already attempted. Provider callbacks are authenticated with the provider-specific signature or signed-envelope contract and reconcile an existing delivery attempt. They do not accept an integration key, create a monitoring event, or provide a general automation endpoint.
Outbound lifecycle webhooks go the other way: WarnFire sends each incident transition — triggered, acknowledged, severity changed, resolved, and escalation outcomes — to HTTPS endpoints you configure, signed and in order per incident. Use them to mirror incident state into a ticketing system or a data warehouse without polling.
Safe automation
- Store credentials in a secret manager and never in a repository, image, or log field. Do not put credentials in a generic API URL. A small number of documented provider adapters require a dedicated URL-key format; protect the entire adapter URL as a secret.
- Send the documented idempotency or event identifier when retrying a request.
- Retry transient failures with bounded exponential backoff and jitter.
- Treat authentication, authorization, validation, and rate-limit responses as distinct failures; do not retry all client errors blindly.
- Record WarnFire’s request or event identifier so an operator can correlate the automation with the incident and audit trail.
- Rotate or revoke a credential when its system owner changes or the integration is retired.
Use the Events API for ingestion semantics and retry rules. The API reference contains the public OpenAPI contract and interactive explorer. Role boundaries are described in Roles and tenant isolation .