Difference between Events API v1 (/generic/2010-04-15/create_event.json) and Events API v2 (/v2/enqueue)

We want to gain a Basic Understanding of the Difference between the Events API v1 (/generic/2010-04-15/create_event.json) and Events API v2 (/v2/enqueue). We tried looking through the documentation as well as the topics in the PagerDuty Community, but couldn’t find a clear and precise answer to our question.

Our client uses PagerDuty Integration (both v1 and v2) for different events. As v1 uses service_key and v2 uses routing_key, is there any way to transform the events from v1 to v2?

Important Note: Our client uses “event_action” as a “trigger” in both v1 and v2 (Shown in the sample payload at the end). This eliminates the difference in the parameters of v1 and v2.

Shall we request our client to stick to a single version of the Events API (v2) and stop using v1?
What would be the consequent behavioral changes/pros and cons of doing the same?

We noticed that executing both v1 and v2 using the common integration key (Services > Event Rules > Default Global Ruleset) triggers alerts in the common page (Incidents > Alerts).

Example Payload for V1:

{

"service_key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",

"event_type": "trigger",

"description": "This is a sample description"

}

Example Payload for V2:

{

"routing_key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",

"event_action": "trigger",

"payload": {

    "source": "abc",

    "severity": "pqr",

    "summary": "This is a sample summary"

}

}

References:
https://developer.pagerduty.com/docs/events-api-v1/overview/
https://developer.pagerduty.com/docs/events-api-v1/trigger-events/
https://developer.pagerduty.com/docs/events-api-v2/overview/
https://developer.pagerduty.com/docs/events-api-v2/trigger-events/

Hi Yug! Happy to answer your questions here.

You can read some information about when to use V1 Events API over the V2 Events API here in our KnowledgeBase.

Our client uses PagerDuty Integration (both v1 and v2) for different events. As v1 uses service_key and v2 uses routing_key, is there any way to transform the events from v1 to v2?

There isn’t a way for PagerDuty to transform the payload sent in V1 Events API to the V2 Events API.
If you are using an integration which can having the payload content changed, you could continue to use the same integration key but send the event to the V2 Events API URL in the PD-CEF format accepted with V2 Events API.

Shall we request our client to stick to a single version of the Events API (v2) and stop using v1?

If it is possible to switch from V1 to the V2 Events API, we highly recommend doing so!

What would be the consequent behavioral changes/pros and cons of doing the same?

We would not see any negative behaviour beyond the transitioning process where event rules may need to be adjusted if using the Global Ruleset.

Allowing use of the V2 Events API increases the different paths that can be used in additional features such as content based alert grouping in our Event Intelligence.

The V1 Events API does not follow the PD-CEF that are leveraged across our partner integrations but it is still an acceptable way to send events if transitioning to the V2 Events API is not possible.

A useful benefit of the v2 format and PD-CEF fields is the ability to use the source, group, category, and component fields with metadata from your environment (service, application, function, team, tool, etc.) and expose that data in the Alerts view in the PagerDuty Web UI by selecting those fields via customized columns. This allows your responders to filter and sort based on meaningful alert data, something not possible anywhere else in PD.