Hi all, especially Python users,

Given the nature of PagerDuty the product and its APIs, some basic use cases are sufficiently useful and near ubiquitous, making them too important to not implement. For these use cases I am considering breaking a convention of “not making an API for the API”.*

A few features in this category that I’ve been considering:

• Fetch incident notes
• Create overrides, for all on-call shifts of a given user and time period to another user (or round-robin the shifts among a group of user IDs)
• Fetch all historical records from all time (i.e. log entries), using a shifting time window to avoid hitting the pagination limit
• Add abstraction for the bespoke pagination styles of:
  • POST /analytics/raw/incidents
  • GET /alert_grouping_settings

Which of these do you think would be the most useful and save the most time? What more general automation use cases do you believe are worth building an opinionated method into an API client that in this area has previously been un-opinionated?

I’m also considering a refactor of the module structure and shifting the underlying HTTP client from Requests to HTTPX (which enables asynchronous use and thread safety).

* This tradition, I realize, has already been broken: the methods of the events API clients are very simplified and opinionated interfaces. This is in part because the APIs are simple enough to make an opinionated wrapper without boxing in the end user or risking code bloat (and also, its use cases demand the integrations be simple). Moreover, Ashley Brooks, during her tenure at PagerDuty, added the “api_key_access” property to the client, which indicates whether the REST API key being used is an account-level (admin permissions) token or a user-level token. It was sufficiently powerful and generally useful enough feature to add, even though it is a specialized method for accessing the Users API.