Skip to main content

We are rolling out some updates to PagerDuty’s REST API rate limits, including:




  1. A refreshed rate limiting system to more consistently and accurately enforce REST API rate limits

  2. New response headers within our REST APIs so that customers can programmatically control the request load sent to PagerDuty

  3. Four dimensions used to enforce the rate limit




Best practices 💪


Ensure your application is ready to handle being rate limited

Update your application to slow down the rate of requests after receiving a 429 response code. For fine-grained control your application can make use of the ratelimit-reset header to wait the appropriate number of seconds before retrying.


Avoid hitting rate limits

These guidelines will help your application avoid hitting rate limits:



  • Make requests serially for a given authentication token.

  • Avoid excessive polling for changes whenever possible. Make use of available Webhooks to receive push updates to data.


One “bot user” per application deployment

If you use PagerDuty Users / User API Keys as “bot users” for applications; create a separate bot user for each deployment of the application (e.g. “Acme Production Bot User”, “Acme Test Bot User”, etc.). This will keep the limits for each deployment of the application separate.



👉 Learn more about PagerDuty’s 🆕 REST API rate limits:


ate limits on PagerDuty’s REST API help ensure that our resources are available for users and their apps when they need them, and also protect against fraudulent activity.


In order to make the best use of REST API rate limits and minimize disruptions to your applications, we recommend the following:




  • Make use of rate limit headers : You can update your application to parse the ratelimit-remaining and ratelimit-reset response headers. If your application is being rate limited, the ratelimit-reset header will let you know how many seconds to wait before retrying.


  • Use one “bot user” per application deployment : If you use PagerDuty user API keys as bot users for applications, create a separate bot user for each application deployment (e.g., “Acme Production Bot User”, “Acme Test Bot User”, etc.). With this approach, rate limits for each application deployment will be kept separate

API Rate Limit implementation is Great to avoid distributed denial-of-service attacks and how much it impact on response time as if user want to not compromise on response time then should we avoid rate limit headers or not ?

Documentation not found


Not Found


Could not find what you are looking for

https://developer.pagerduty.com/api-reference/

https://developer.pagerduty.com/api-reference/

I just fixed the last link here @ybavn49 – if that’s the one that was giving you trouble? Let me know if you’re still having problems.

Reply


Terms & ConditionsCookie settings