Console administration

Services and integration keys

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

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 a monitoring source sends with every alarm. It does three jobs:

• authenticates the monitoring source;
• routes the alarm to the service whose escalation policy should run; and
• limits the key to one alert source, such as Alertmanager or Datadog.

A key works only at its own alert source’s address. Sent to any other WarnFire address, it never opens or changes an incident, and the response is exactly what that address returns for an unknown key, so it never reveals which source the key belongs to. A leaked Datadog key cannot open incidents through the generic webhook or the Events API. Connect each monitoring tool with its own key.

The source is chosen when the key is created and cannot be changed. Rotation keeps it. To send from another tool, create another key.

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

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 Alert source that will send to this key. The key works only for that source, and the endpoint shown after creation is that source’s address.
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. Select the Alert source that will use the key.
3. Enter a descriptive Key name, such as Production Grafana.
4. Choose an expiry and the warning periods for expiry and inactivity.
5. 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.
6. Select Create integration key.
7. Copy and store the key before closing the one-time display.

The service list shows each key’s alert source, 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

Select Rotate beside a key and confirm. WarnFire replaces that key’s secret in place: its ID and name stay the same, and the old secret immediately stops working. The key keeps its alert source. Copy the new secret from its one-time display and update the sender. Repeated rotation does not add keys to the list.

The console resets expiry to no expiry, the event limit to the plan limit, and expiry and unused warnings to 7 days, as before. Review these settings when rotating a credential.

For an uninterrupted sender change, use Create integration key to add a separate key, update and test the sender, verify Last used, then revoke the old key. This overlap is separate from Rotate.

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

• Run the complete configuration-readiness and end-to-end test .
• Connect a provider-specific webhook adapter or send a trigger through the Events API .