Overview
Rate limiting prevents excessive API calls and ensures fair resource usage for all integrators.Rate Limited Endpoints
/foods/get-foods
Limit: 1 request per 30 secondsWhy: Menu data doesn’t change frequently
/orders/get-current
Limit: 1 request per 30 secondsWhy: Prevents aggressive polling
How It Works
1
First Request
Your first call to a rate-limited endpoint succeeds normally.
2
Cooldown Starts
A 30-second cooldown timer starts from the first successful request.
3
Subsequent Requests
Any requests within the 30-second window return a 429 error.
4
Cooldown Expires
After 30 seconds, you can make another request.
Rate Limit Error Response
429 Too Many Requests
Polling Strategy
✅ Recommended Approach
❌ Wrong Approach
Handling 429 Errors
- Simple Wait
- Exponential Backoff
- Adaptive Polling
Best Practices
1. Use Appropriate Intervals
1. Use Appropriate Intervals
3. Implement Rate Limit Tracking
3. Implement Rate Limit Tracking
4. Queue Requests
4. Queue Requests
Monitoring Rate Limits
Testing Rate Limits
Common Mistakes
Recommended Intervals
Production Configuration
Summary
✅ Do
✅ Do
- Poll orders every 30+ seconds
- Cache menu data for 30+ minutes
- Handle 429 errors gracefully
- Wait 30 seconds before retry
- Monitor rate limit hits
- Use request queuing
❌ Don't
❌ Don't
- Poll more frequently than 30 seconds
- Fetch menu on every order
- Ignore 429 errors
- Retry immediately
- Make multiple simultaneous requests
- Default to aggressive intervals
Need Higher Limits?
If your use case requires higher rate limits, contact us to discuss options.