PagerDuty

Integrating Hotpot with PagerDuty.

Hotpot competes with PagerDuty, but not everyone is ready to switch directly to Hotpot to deliver pages. In the meantime, Hotpot can collect paging information from Hotpot, and more!

Hotpot supports two methods to integrate into PagerDuty. If you need narrowly scoped permissions, use the OAuth method. A simpler approach is to create an API key under Integrations -> API Access Keys (name the key well and do not select the read-only option).

Hotpot uses the following API endpoints in PagerDuty:

• GET /escalation_policies We include targets in the request, required to determine schedules and users involved in the escalation policy

• POST /escalation_policies for creating an escalation policy that Hotpot can manage

• GET /escalation_policies/:id

• PUT /escalation_policies/:id

• GET /schedules This call includes schedule_layers

• POST /schedules

• DELETE /schedules/:id: Deletes outdated schedules that have drifted (caused by changes made in PagerDuty but not in Hotpot, and will only delete schedules that are part of the escalation policy that Hotpot is managing)

• PUT /schedules/:id To update a Hotpot-managed schedule

• GET /users: This call is to map PagerDuty users to Hotpot users, also includes contact_methods for additional email address mapping

• Optional, only necessary if Hotpot is managing PagerDuty’s notification endpoints. Hotpot manages webhook subscriptions that will create Moments for relevant PagerDuty events:

  • GET /webhook_subscriptions

  • POST /webhook_subscriptions

  • PUT /webhook_subscriptions/:id

It's important that the PagerDuty sign-in email address is the same as what is in Hotpot. Hotpot uses that email address to map Hotpot users to PagerDuty users