Flipdish · Rate Limits

Flipdish Rate Limits

Flipdish does not publish specific request-rate or concurrency numbers in its public developer documentation. The Error Handling guide documents the approved HTTP status codes (400, 401, 403, 404, 409, 414, 500) and a JSON error object with errorMessage and errorCode, but does not document a 429 (Too Many Requests) behavior, rate-limit headers, or backoff guidance. The values below are therefore recorded as undocumented/string limits pending confirmation with Flipdish support; the 429 code is listed because it is an approved status code in Flipdish's own API Design Guide. Limits are assumed to be scoped per OAuth client/application.

Flipdish Rate Limits is the machine-readable rate-limit profile for Flipdish on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring requests_per_second and varies.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled and serverError.

Tagged areas include Rate Limiting, Restaurant, and Online Ordering.

2 Limits Throttle: 429
Rate LimitingRestaurantOnline Ordering

Limits

API requests (per OAuth client) key
requests_per_second
not publicly documented — contact Flipdish support
No per-second or per-minute number is published. The Flipdish API Design Guide lists 429 as an approved status code, implying request throttling exists; the threshold is not disclosed.
Webhook delivery and event subscriptions account
varies
not publicly documented
Event subscriptions (v3) and webhook deliveries may be subject to provider-side delivery limits; not quantified in public docs.

Policies

Exponential backoff on errors
Treat 429 and 5xx responses as retryable. Apply exponential backoff with jitter; the public docs do not specify a Retry-After value, so use conservative client-side defaults.
Per-client scoping
Limits are assumed to be enforced per OAuth client (Client ID), not per IP. Provision separate App Store apps for independent workloads to isolate throttling.
Confirm with support before high-volume use
Because thresholds are undocumented, integration partners running high-volume polling or batch operations should confirm acceptable rates with Flipdish support (help@flipdish.com) before scaling.

Sources