WarnFireDocs

Console administration

Services and integration keys

Create a service, issue its first integration key, test the paging path, and rotate credentials without interrupting alarms.

Version 1.0 Status Needs verification For Tenant administratorsFor Tenant owners servicesintegration-keysonboardingcredentials

A service is the system or area of responsibility that an incident belongs to. Its escalation policy determines who WarnFire pages. An integration key lets one monitoring source create and update incidents for that service only.

What an integration key is

An integration key is the service-scoped credential included with every Events API alarm. It does two jobs:

  • authenticates the monitoring source; and
  • routes the alarm to the service whose escalation policy should run.

A complete live key begins with wf_live_ and is supplied in the JSON request’s integration_key field. This is the complete key issued during the documented validation run. It was revoked after capture and cannot authenticate:

wf_live_NmG54bE2EM7bA_DsKVW9hc4LGFLUFWZERZGUWrDynt4

Workspace-ready screen showing the complete integration key and Copy key button.

The key appears in the dark field. Select the image to open it full size.

Before you begin

You need tenant-owner or tenant-administrator access. Create the escalation policy that should handle incidents for the service. Decide which monitoring system will send the first alarm, and have a secret manager ready for the key.

Create a service and its first key

  1. Open Configuration → Services.
  2. Under New service, enter a recognizable operational Name.
  3. Select the Escalation policy that owns incidents for this service.
  4. Select the first Alert source. This changes the endpoint and authentication instructions shown after creation; the key itself works with every supported source.
  5. Select Create service + integration key.
  6. In Your new integration key, select Copy key and store it in the secret manager. WarnFire will not show the complete key again.
  7. Copy the displayed endpoint or open the linked setup guide.
  8. Select Done — I’ve copied it.

Create one service for a system with a distinct operational owner or escalation path. Do not create a separate service for every alarm rule, host, or container.

Add a key to an existing service

Use a separate key for each independently managed monitoring source:

  1. Under Create an additional key, select the Service.
  2. Enter a descriptive Key name, such as Production Grafana.
  3. Choose an expiry and the warning periods for expiry and inactivity.
  4. Set Events per minute. A value of 0 uses the plan limit; a key can impose a lower limit but cannot raise the plan limit.
  5. Select Create integration key.
  6. Copy and store the key before closing the one-time display.

The service list shows each key’s status, disguised value, creation time, last use, expiry, and effective event limit.

The key controls mean:

  • Expires is when WarnFire stops accepting the key. The console offers Never, 30, 90, 180, or 365 days.
  • Expiry warning marks a still-active key when its expiry is within the selected number of days. It has no effect on a key that never expires.
  • Unused warning marks a key after the selected number of days without a successful event. For a key never used, WarnFire measures from its creation time.
  • Events per minute is a trigger ceiling for this key. 0 uses the plan ceiling; any positive value can lower but never raise that ceiling. Resolve and acknowledge events do not consume trigger slots.

Rotate or revoke a key

To rotate without interrupting alarms:

  1. Select Rotate beside the active key.
  2. Copy the replacement key from the one-time display.
  3. Update the monitoring source and send a test alarm with the replacement.
  4. Confirm that Last used changes on the replacement key.
  5. Select Revoke on the old key and confirm the warning.

Rotate creates a second active key named after the old key with replacement appended. The replacement defaults to no expiry, the plan event limit, a 7-day expiry-warning setting, and a 7-day unused warning; it does not copy the old key’s settings. Review those defaults before adopting the replacement as your long-lived credential.

Revocation is immediate. A sender still using the revoked key receives a 401 response, so do not revoke the old key until the replacement has been observed in use. WarnFire also refuses to revoke the last usable key on an enabled service.

Verify it worked

Verify the service path

  1. Select Send test alert beside the enabled service.
  2. Confirm that WarnFire opens the test incident automatically.
  3. Check that the incident names the expected service and captured escalation policy.
  4. Confirm that the intended responder receives the page.
  5. Have that responder acknowledge the incident and confirm that its status changes to Acknowledged.
  6. Open Delivery Activity and confirm the expected attempt and strongest available evidence.
  7. Select Force resolve, enter a reason that identifies the incident as a service-path test, and confirm that it closes.

The test follows the real escalation path. Do not run it without notifying the responder who is currently on call. It validates the service and policy, but it does not prove that a particular newly issued or rotated key works. SMS and voice consume allowance or prepaid credits for every contacted destination.

If delivery or acknowledgement fails, use Force resolve with a reason that records the failed test before troubleshooting the path.

Verify a specific key

Send a disposable Events API trigger using the exact key your monitoring source will store:

curl --include --fail-with-body \
  --request POST 'https://api.warnfire.com/v1/events' \
  --header 'Content-Type: application/json' \
  --data '{
    "integration_key": "YOUR-INTEGRATION-KEY",
    "event_action": "trigger",
    "dedup_key": "integration-key-validation",
    "payload": {
      "summary": "Integration key validation",
      "source": "documentation-check",
      "severity": "info"
    }
  }'

Confirm all of the following before replacing or revoking another key:

  1. The response is 202 Accepted and returns an incident identifier.
  2. Last used changes on the intended key, not a different key on the service.
  3. The incident belongs to the intended service and the expected responder can acknowledge it.
  4. Send a resolve event with the same dedup_key, or resolve the incident in the console with a reason, and confirm that it closes.

The trigger follows the selected escalation channels. SMS and voice consume allowance or prepaid credits for every contacted destination.

Next steps