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:

EndpointLimit
GET menu by ID and its sub-resources25 requests / 60s
Vouchers and customers endpoints6000 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 429 as 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 Forbidden instead of 429 due to a bug in an internal authorization step. This has been fixed — rate-limited requests now consistently return 429. If you're still seeing 403 where 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.