grubhub · Rate Limits

Grubhub Rate Limits

Grubhub rate-limits its Partner Integration API endpoints to minimize abuse, protect backend systems, and maintain service quality. Per the official FAQs & Best Practices documentation, endpoint limits vary by endpoint but typically range between 200 and 400 requests per minute from a single source. Requests above the threshold receive an HTTP 429 response. Limits are enforced per source / OAuth client and assigned per partner integration. Grubhub recommends batching entity operations and subscribing to webhooks rather than polling to avoid hitting the limit.

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

It captures 3 rate-limit definitions, measuring requests_per_minute and varies.

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

Tagged areas include Rate Limiting, Food Delivery, Marketplaces, and Restaurants.

3 Limits Throttle: 429
Rate LimitingFood DeliveryMarketplacesRestaurants

Limits

Partner integration API requests (per source) source
requests_per_minute · minute
400
Endpoint limits vary but typically range between 200 and 400 requests per minute from a single source. Requests above the threshold receive a 429 error. The 400/min value is the documented upper bound of the typical range.
Partner integration API requests (per source, lower bound) source
requests_per_minute · minute
200
Documented lower bound of the typical per-source range. Specific endpoints may be throttled closer to 200/min; treat 200 as the conservative budget when the per-endpoint value is unknown.
Webhook delivery (Orders, Deliveries) partner-endpoint
varies
partner endpoint must accept burst order volumes
Grubhub posts events to the partner's webhook URL; the partner is expected to absorb peak restaurant order volume rather than rate-limit Grubhub-originated requests.

Policies

Backoff Strategy
Use exponential backoff with jitter on 429 / 503 responses; honor Retry-After when present. Repeated 429 errors should be escalated to your Grubhub technical contact.
Batch Entity Operations
When updating or removing individual or groups of menu items, include as many entity IDs as possible in a single request rather than sending one request per entity. For example, send one request with 10 out-of-stock item IDs instead of 10 separate requests.
Prefer Webhooks Over Polling
Subscribe to available webhooks that fire when jobs complete, or wait a few minutes before polling for status, rather than polling tightly in a loop. This is the primary recommended technique for staying under the per-source limit.
Webhook Reliability
Partners receiving Orders / Deliveries webhooks should respond quickly (2xx) and process asynchronously to avoid Grubhub-side retry storms.
Per-Source Scoping
Limits are enforced per single source / OAuth client; new integrations should pre-provision headroom with Grubhub before launch.

Sources