Lunchbox · Rate Limits

Lunchbox Rate Limits

The Lunchbox 2.0 Open API documentation (a Postman-published reference) states that the API uses standard HTTP status codes to indicate success or failure and that all schemas are JSON, but it does not publish specific per-second, per-minute, or daily request-rate numbers, nor documented rate-limit response headers. Access is provisioned per restaurant chain and authenticated with a team token (Authorization: Token ) for the Core, Management, and POS APIs, and with an Api-Key for the Loyalty API; enabling order webhooks requires coordination with the Lunchbox team. Concrete throttling limits are therefore established per integration partner via that onboarding process and are not reconciled here against a published limits page.

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

It captures 5 rate-limit definitions, measuring varies.

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

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

5 Limits Throttle: 429
Rate LimitingRestaurantOnline OrderingOpen API

Limits

Core API requests chain/token
varies
not publicly documented; provisioned per chain during onboarding
Authenticated with a team token scoped to the restaurant chain.
Management API requests chain/token
varies
not publicly documented; administrative throughput agreed with Lunchbox
Loyalty API requests merchant/key
varies
not publicly documented; scoped to the loyalty engine Api-Key
POS API order submission chain/pos-store
varies
not publicly documented; coordinated with the POS integration partner
Order webhooks chain/endpoint
varies
event-driven; delivery cadence coordinated with the Lunchbox team
Transaction, store-update, and order-update webhooks are enabled only after providing Lunchbox with a destination URL.

Policies

Token-Scoped Access
Limits and quotas are bound to the per-chain team token (Core, Management, POS) or the loyalty Api-Key, not to individual end users.
Partner Onboarding
Rate limits, webhook cadence, and POS throughput are negotiated and configured during partner onboarding rather than self-service.
Standard HTTP Semantics
Clients should treat 4xx/5xx responses with standard HTTP semantics and retry idempotent operations (GET, PUT, DELETE) with backoff on transient 5xx errors.