Eat App · Rate Limits

Eat App Rate Limits

Eat App's public API documentation states that endpoints are rate limited to approximately 60 requests per minute per API key. This applies to both the Partner API and the Concierge API. Requests are authenticated with a Bearer token (the issued API key) and scoped per group / per restaurant via headers, so throttling is effectively per credential. Beyond the request-rate cap, usage is bounded by the per-location plan (cover allowances) rather than by API quotas.

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

It captures 3 rate-limit definitions, measuring requests and covers.

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

Tagged areas include Restaurant, Reservations, Hospitality, Rate Limiting, and Quotas.

3 Limits Throttle: 429
RestaurantReservationsHospitalityRate LimitingQuotas

Limits

Partner API Requests apiKey
requests
~60 per minute
Documented approximate per-key request-rate cap for the Partner API.
Concierge API Requests apiKey
requests
~60 per minute
Documented approximate per-key request-rate cap for the Concierge API.
Monthly Covers location
covers
per plan
Free plan caps monthly covers (100); Starter caps at 300; Essential and Pro are unlimited.

Policies

Idempotency
Concierge reservation creation accepts an idempotency_token so retries do not create duplicate reservations.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.
Compression
The Partner API supports Gzip response encoding via the Accept-Encoding header to reduce payload size.

Sources