Events API v2 resolve by incident_key

events-api

(Stephen Cleary) #1

I don’t see any examples or documentation on how to use the events API with an event_action of resolve. The v2 events API reference docs are actually for the v1 API: https://v2.developer.pagerduty.com/v2/page/events-api-reference

In my particular case, I’m triggering successfully, and then retrieving the incident from the REST API, so I have an incident_key. With events API v1, I could use that to resolve, but I don’t see how to do that with v2. Adding incident_key to the root object does not seem to work; I get a 400 Bad Request.


(Mary Foran) #2

For the v2 Events API - you are going to use a dedup_key instead of the incident_key to link the resolves to the triggered events.

Here is the documentation on the v2 Events API: https://v2.developer.pagerduty.com/docs/send-an-event-events-api-v2 (If you like, you may test it out at the bottom of the page)

Attend PagerDuty Summit!
Mobilize a team response with a single click, from either the web or mobile app - Learn how!


(Stephen Cleary) #3

To clarify, I do need to set payload.summary, payload.source, and payload.severity, even though these values are ignored, correct?


(Mary Foran) #4

If you are using our v2 Events API Developer Page, you do need to set the payload.summary, payload.source, and payload.severity because this is a built-in limitation function of the page itself. The page is formatted to allow you to trigger events and is not intended to handle all event commands.

If you are using a curl command, you do not need to set payload.summary, payload.source, and payload.severity in order to resolve an event.

Attend PagerDuty Summit!
Mobilize a team response with a single click, from either the web or mobile app - Learn how!


(Stephen Cleary) #5

I’m using a direct HTTP client, and I keep getting a 400 Bad Request unless payload.summary, payload.source, and payload.severity are set. I have not tried different combinations of these; when they are all present (with dummy values), it works; when they are all missing, I get a 400.


(Mary Foran) #6

Per our documentation (https://v2.developer.pagerduty.com/docs/send-an-event-events-api-v2 click on “resolve”), here is a properly formatted resolve event.

{
  "routing_key": "routingkeyhere",
  "dedup_key": "dedupkeyhere",
  "event_action": "resolve"
}

If you are still having an issue, please email support@pagerduty with a sample payload and we would be happy to take a closer look.

Attend PagerDuty Summit!
Mobilize a team response with a single click, from either the web or mobile app - Learn how!


(Simon Fiddaman) #7

@StephenCleary: payload is required on the trigger, but not on the resolve.

The following examples (with real “routing_key”) work for me:

curl -X POST --header ‘Content-Type: application/json’ -d’{“routing_key”: “xxx”, “event_action”: “trigger”, “dedup_key”: “123456”, “payload”: {“summary”: “TEST 123456”, “severity”: “critical”, “source”: “api”}}’ ‘https://events.pagerduty.com/v2/enqueue

curl -X POST --header ‘Content-Type: application/json’ -d’{“routing_key”: “xxx”, “event_action”: “resolve”, “dedup_key”: “12345”}’ ‘https://events.pagerduty.com/v2/enqueue

The way the Events API works / expects you to use it is via async/anonymous means - basically you post a blob (trigger) and then later you post another blob (resolve) and you don’t need to know what ID was created for the alert/incident a the PagerDuty end because you’re providing it via “dedup_key”.

This means you don’t actually need to poll the REST API for the incident key or any other details. :+1:


(system) #8