Rate Limits

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, these defaults apply across the v3.0 API suite:

The window is a fixed 60-second period — there's no burst allowance on top of the stated limit. Sending an access token on every request gets you the higher, authenticated-tier limit.

Legacy v1.0 endpoint overrides

A small number of legacy v1.0 (Consumer Orders) endpoints have their own limits instead of the default:

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.