Hello @kevin clement!
The recommend way to create alerts in PagerDuty is to send events to the Events API and use the service integration key for proper redirection to the correct service. So you are doing it correctly.
You have an option to use REST APIs with a global integration key but that doesn’t allow you to send events to PagerDuty, it will only allow you to create incidents directly. This will also require you to provide the service id in the request payload to indicate in which service the incident will be associated to. This is not effective and I wouldn’t recommend it unless you have a strong reason for it.
Let me know if this helps.
Thanks @tiago barbosa.
Following up on some general knowledge, when posting an event to events v2 API, how can you then reference that alert/incident created from said event?
We get a dedup key back in the response, but not sure how to utilize that.
Hi @kevin clement!
When using the Events v2 API you either send Alert events or Change events. Alert Events create alerts in PagerDuty and therefore you can get the information on the events sent either that triggered the alert and potentially and incident by using the Incidents API. Still there is no reference to the event itself, as the event information will be added to the alert on creation time.
The dedup key you get when you send events to PagerDuty is the alert deduplication key. This is pretty helpful as it allows you to instruct PagerDuty to group events into the same alert. If you send multiple events with the same dedup key they get grouped into the same alert and target incident.
It is important to have this in mind when building a custom integration with PagerDuty through its APIs. I would recommend you to take a look at this page if you haven’t done so to understand the lifecycle of an event sent to PagerDuty.
Hey @tiago barbosa,
Looking into the OAuth endpoints here and noticed some discrepancy in the documentation for authorization.
The following shows Preamble with “Bearer”: https://developer.pagerduty.com/docs/e518101fde5f3-obtaining-an-app-o-auth-token
While the following shows Preamble with “Token”: https://developer.pagerduty.com/api-reference/3a6b910f11050-list-all-of-the-on-calls
Do we know if this is a discrepancy or not?
Hi @kevin clement!
Good catch! If you use Scoped OAuth with our APIs, you need to use the Bearer keyword on the Authorization header. If you go to our API reference you’ll see the OAuth permissions you need to have so you can call a specific endpoint and operation.
The discrepancy you are referring to is because our API reference page currently only supports the Token token="…" approach. I hope that makes sense.
Hmm, slightly confused as using the Token preamble seems to have worked on the oncalls endpoint just now.
