Skip to main content

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

HTTP Status: 429 Too Many Requests

Polling Strategy

❌ Wrong Approach

Handling 429 Errors

Best Practices

Don’t fetch menu on every order - cache it!

Monitoring Rate Limits

Testing Rate Limits

Common Mistakes

Avoid These Patterns:

  1. Polling too frequently - Always use 30+ second intervals
  2. Immediate retry on 429 - Wait the full 30 seconds
  3. Multiple simultaneous requests - Space out requests
  4. Not caching menu data - Cache locally, don’t refetch constantly
  5. Ignoring 429 errors - Handle them gracefully

Production Configuration

Summary

  • 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
  • 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.