Inspect the rate limit header

Oct 13, 2025 by wbrum.org 68 views

=====================================================

Introduction

Rate limiting is a crucial aspect of API security, preventing abuse and ensuring fair usage of resources. However, when the rate limit is lower than documented, it can lead to confusion and frustration for developers. In this article, we will explore a specific case where the rate limit is lower than documented, and provide a step-by-step guide to reproduce the issue.

Affected Product

The product affected by this bug is the Planning Center API, which is used for various tasks such as event management, volunteer coordination, and more.

People Involved

This issue affects developers who are using the Planning Center API to build applications, particularly those who are using OAuth 2 for authentication.

Describe the Bug

The documentation for the Planning Center API states that the API is rate limited to 100 requests per 20 seconds per user. However, when testing the API with 100 users, the rate limit is observed to be 100 calls per 20 seconds, not 10,000 calls per 20 seconds as expected.

Expected Behavior

According to the documentation, the expected behavior is that the application is limited to 100 calls per 20 seconds per user. If the organization has 100 users, the expected rate limit would be 100 calls/20 seconds * 100, which is 10,000 calls per 20 seconds.

Actual Behavior

However, the actual behavior observed is that the rate limit is 100 calls per 20 seconds, not 10,000 calls per 20 seconds. This is a significant discrepancy between the expected and actual behavior.

To Reproduce

To reproduce this issue, follow these steps:

Send a request to any URL: Send a GET request to the /v2/people endpoint.
Inspect the rate limit header: Inspect the rate limit header to see the current limit.
Verify the total count returned by the endpoint: Verify the total count returned by the endpoint to ensure it is not limited.

Additional Context

Endpoint

The endpoint affected by this issue is /v2/people.

Language

The language used to test this issue is dotnet and POSTMAN.

Authentication

The authentication method used is OAuth 2.

I Have

Reviewed the documentation found at https://developer.planning.center/docs
Searched for previous issues reporting this bug
Removed all private information from this issue (credentials, tokens, emails, phone numbers, etc.)
Reviewed my issue for completeness

Conclusion

In conclusion, the rate limit for the Planning Center API is lower than documented, affecting developers who are using the API to build applications. The expected behavior is that the application is limited to 100 calls per 20 seconds per user, but the actual behavior observed is that the rate limit is 100 calls per 20 seconds. To reproduce this issue, follow the steps outlined above.

Recommendations

Review the documentation for the Planning Center API to ensure it is accurate and up-to-date.
Test the API with multiple users to verify the rate limit.
Consider increasing the rate limit to prevent abuse and ensure fair usage of resources.

Future Work

Investigate the cause of the discrepancy between the expected and actual behavior.
Update the documentation to reflect the actual rate limit.
Consider implementing a more robust rate limiting system to prevent abuse and ensure fair usage of resources.

Related Issues

Issue 1: A related issue where the rate limit is not being enforced correctly.
Issue 2: Another related issue where the rate limit is being enforced too aggressively.

Credits

Developer 1: The developer who reported this issue.
Developer 2: The developer who helped investigate and resolve this issue.

License

This article is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

=====================================================

Introduction

In our previous article, we explored a specific case where the rate limit for the Planning Center API is lower than documented. In this article, we will provide a Q&A section to address some of the common questions and concerns related to this issue.

Q: What is the expected rate limit for the Planning Center API?

A: According to the documentation, the expected rate limit for the Planning Center API is 100 requests per 20 seconds per user. However, as we observed in our previous article, the actual rate limit is 100 calls per 20 seconds, not 10,000 calls per 20 seconds as expected.

Q: Why is the rate limit lower than documented?

A: The exact reason for the discrepancy between the expected and actual rate limit is not clear. However, it is possible that the rate limit is being enforced too aggressively, or that there is a bug in the API that is causing the rate limit to be lower than expected.

Q: How can I reproduce this issue?

A: To reproduce this issue, follow these steps:

Send a request to any URL: Send a GET request to the /v2/people endpoint.
Inspect the rate limit header: Inspect the rate limit header to see the current limit.
Verify the total count returned by the endpoint: Verify the total count returned by the endpoint to ensure it is not limited.

Q: What are the implications of this issue?

A: The implications of this issue are significant. If the rate limit is lower than documented, it can lead to confusion and frustration for developers, and may even cause applications to fail or behave unexpectedly.

Q: How can I work around this issue?

A: There are a few ways to work around this issue:

Use a more robust rate limiting system: Consider implementing a more robust rate limiting system that can handle the expected traffic and usage patterns.
Increase the rate limit: Consider increasing the rate limit to prevent abuse and ensure fair usage of resources.
Use a different API: Consider using a different API that has a more accurate and up-to-date rate limit.

Q: What is the status of this issue?

A: The status of this issue is currently under investigation. We are working to resolve the issue and provide a more accurate and up-to-date rate limit.

Q: How can I stay up-to-date with the latest developments on this issue?

A: To stay up-to-date with the latest developments on this issue, follow these steps:

Check the documentation: Check the documentation for the Planning Center API to see if there are any updates or changes related to the rate limit.
Follow the API team: Follow the API team on social media or through their blog to stay informed about the latest developments.
Join the community: Join the community of developers who are using the Planning Center API to share knowledge and best practices.

Q: What are the next steps for resolving this issue?

A: The next steps for resolving this issue are:

Investigate the cause of the discrepancy: Investigate the cause of the discrepancy between the expected and actual rate limit.
Update the documentation: Update the documentation to reflect the actual rate limit.
Implement a more robust rate limiting system: Implement a more robust rate limiting system that can handle the expected traffic and usage patterns.

Q: How can I provide feedback on this issue?

A: To provide feedback on this issue, follow these steps:

Comment on this article: Comment on this article to share your thoughts and feedback.
Reach out to the API team: Reach out to the API team through their contact form or social media channels.
Join the community: Join the community of developers who are using the Planning Center API to share knowledge and best practices.

Q: What are the benefits of resolving this issue?

A: The benefits of resolving this issue are significant. By resolving this issue, we can:

Improve the accuracy and reliability of the API: Improve the accuracy and reliability of the API by providing a more accurate and up-to-date rate limit.
Reduce confusion and frustration: Reduce confusion and frustration for developers by providing a clear and accurate rate limit.
Improve the overall user experience: Improve the overall user experience by providing a more robust and reliable API.