Rate Limits
Current default request rate limits for the Flipdish API and what happens when you exceed them.
To keep the platform stable for everyone, the Flipdish API applies request rate limits. This page describes the current defaults so you can build resilient retry behavior into your integration and, if you like, throttle client-side to avoid ever hitting them.
Default limits
Unless a specific endpoint states otherwise, this default applies across the v3.0 API suite, regardless of whether the request is authenticated:
50 requests per 60 seconds, per client IP.
The window is a fixed 60-second period — there's no burst allowance on top of the stated limit.
Legacy v1.0 endpoint overrides
A small number of legacy v1.0 (Consumer Orders) endpoints have their own limit instead of the default:
| Endpoint | Limit |
|---|---|
GET menu by ID and its sub-resources | 25 requests / 60s |
| Vouchers and customers endpoints | 6000 requests / 60s |
The menu endpoint's lower limit is why we recommend polling the menu version number rather than retrieving the full menu on a tight interval — see Build a POS Integration for guidance.
What happens when you're rate limited
Once a limit is exceeded, the API returns 429 Too Many Requests. We recommend that clients:
- Treat
429as retryable — back off and try again rather than treating it as a hard failure. - Use an increasing backoff between retries instead of retrying immediately.
- Avoid tight polling loops; prefer webhooks for real-time updates where available.
Previously seen as a 403?Some rate-limited requests were briefly relayed to clients as
403 Forbiddeninstead of429due to a bug in an internal authorization step. This has been fixed — rate-limited requests now consistently return429. If you're still seeing403where you'd expect a rate-limit response, contact [email protected].
If your integration has a legitimate need for a higher limit, email [email protected] with your use case.
Updated 20 days ago

