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
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
2. Cache Menu Data
2. Cache Menu Data
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
| Endpoint | Recommended | Maximum | Reason |
|---|---|---|---|
/orders/get-current | 30-40s | Every 30s | Real-time order updates |
/foods/get-foods | 30-60min | Every 30s | Menu doesn’t change often |
/restaurants/status/get | 5min | N/A | Status changes infrequent |
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.