SpherePay enforces rate limits on all API requests to ensure reliability and fair performance for all users. Understanding these limits and designing your integration around them will help you avoid disruptions as you scale.Documentation Index
Fetch the complete documentation index at: https://docs.spherepay.co/llms.txt
Use this file to discover all available pages before exploring further.
Standard rate limits
SpherePay measures rate limits in requests per second (RPS) per application.| Operation | HTTP methods | Rate limit |
|---|---|---|
| Read | GET | 100 RPS |
| Write | POST, PUT, PATCH, DELETE | 100 RPS |
If you have arranged custom limits with the SpherePay support team, your rate limits may differ from the defaults above.
Requesting a rate limit increase
If your use case requires higher limits — for example, during a product launch or a high-traffic event — contact support@spherepay.co to request a temporary or permanent increase.Load testing
If you need to conduct load testing against SpherePay APIs, simulate requests using realistic latency parameters rather than maximum throughput. For complex integrations or dedicated load testing windows, reach out to support@spherepay.co before running tests.SpherePay can provide designated load testing windows for integrations that require it. Contact the support team to arrange this in advance.
Best practices
Following these guidelines will help you stay within rate limits and maintain a reliable integration:- Monitor API usage — track your request rates regularly so you can identify spikes before they cause errors.
- Implement exponential backoff — when you receive a rate limit error, wait and retry with increasing delays. See the AWS Retry with Backoff Pattern guide for a reference implementation.
- Cache efficiently — store frequently read data locally to reduce repeated GET requests for the same resources.
- Optimize requests — batch operations where possible and request only the data your application actually needs.