Overview
Rate limits are applied per merchant, per endpoint, with a sliding window algorithm. Each endpoint has its own limit based on expected usage patterns.Rate Limits by Endpoint
Payment Endpoints
| Endpoint | Method | Limit | Window |
|---|---|---|---|
/v1/payment | POST | 100 requests | 1 minute |
/v1/payment/:id | GET | 300 requests | 1 minute |
/v1/payment/list | GET | 200 requests | 1 minute |
Payment Link Endpoints
| Endpoint | Method | Limit | Window |
|---|---|---|---|
/v1/payment-link | POST | 50 requests | 1 minute |
/v1/payment-link/:id | GET | 100 requests | 1 minute |
/v1/payment-link/list | GET | 100 requests | 1 minute |
/v1/payment-link/:id | PATCH | 50 requests | 1 minute |
/v1/payment-link/:id | DELETE | 50 requests | 1 minute |
Rate Limit Headers
Every API response includes rate limit information in headers:Header Definitions
- X-RateLimit-Limit: Maximum requests allowed in the window
- X-RateLimit-Remaining: Requests remaining in current window
- X-RateLimit-Reset: Unix timestamp when the limit resets
Rate Limit Exceeded Response
When you exceed the rate limit, you’ll receive a 429 response:Best Practices
1. Monitor Rate Limit Headers
Check headers proactively to avoid hitting limits:2. Implement Exponential Backoff
Retry with increasing delays when rate limited:3. Cache Responses
Cache GET responses to reduce API calls:4. Batch Requests
Use list endpoints instead of multiple single-item requests:5. Request Queuing
Queue requests to stay within rate limits:6. Parallel Request Management
Limit concurrent requests:Rate Limit Strategies by Use Case
High-Volume Integration
For applications with high request volumes:Monitoring Rate Limits
Track Usage
Alert on High Usage
Increasing Rate Limits
Default rate limits accommodate most use cases. If you need higher limits:- Email: [email protected]
- Include:
- Your merchant ID
- Current usage patterns
- Required rate limit
- Use case description
- Expected request volume
FAQ
What happens if I exceed the rate limit?
You’ll receive a 429 response. Wait for the time specified inretryAfter (or use the X-RateLimit-Reset header) before making new requests.
Are rate limits per API key or per merchant?
Rate limits are per merchant. All API keys for a merchant share the same rate limit pool.Do rate limits reset exactly every minute?
No. Rate limits use a sliding window algorithm. The window moves continuously, not in fixed 1-minute blocks.Can I check my rate limit without making a request?
No, but you can make a lightweight GET request and check the headers:Do failed requests count toward rate limits?
Yes. All requests (successful or failed) count toward your rate limit.Are webhook deliveries rate limited?
No. Outgoing webhooks from CeyPay to your endpoint are not rate limited (but they have a retry policy).What about burst traffic?
The sliding window algorithm allows for short bursts. For example, with a 100 req/min limit, you could make 100 requests immediately, but then you’d need to wait ~1 minute before making more.Related Documentation
- Error Codes - Handling 429 errors
- Authentication - API authentication
- Quick Start - Getting started
- Webhooks - Webhook integration
Support
Need help with rate limiting?- Email: [email protected]
- Documentation: https://docs.ceypay.io