TheMealDB · Rate Limits

Mealdb Rate Limits

TheMealDB does not publish explicit per-second, per-minute, or per-month request quotas for either the free or supporter tiers. The public test key "1" is shared across all unauthenticated consumers and is intended for development, testing, and personal use rather than high-volume production traffic. Supporter keys are individual production keys obtained via the lifetime upgrade (£10) and are better suited for production workloads. Because no hard limits are documented, consumers should implement sensible client-side throttling, caching of static resources (categories, ingredient lists, meal details), and exponential backoff on error responses to be a good API citizen.

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

It captures 3 rate-limit definitions, measuring requests_per_second and total_meals.

The profile also includes 4 backoff/retry policies defined.

Tagged areas include Rate Limiting, Recipes, Food, and Open Data.

3 Limits
Rate LimitingRecipesFoodOpen Data

Limits

Free tier request rate (test key "1") shared-key
requests_per_second · second
not publicly documented; shared key intended for development/personal use
The test key "1" is shared among all unauthenticated callers. No explicit quota is documented. Consumers should cache meal data locally and avoid rapid burst requests to avoid service degradation.
Supporter tier request rate (personal key) key
requests_per_second · second
not publicly documented; personal production key
Personal supporter keys are suited for production use. No explicit rate limit numbers are published. Apply standard HTTP backoff on 429 or 5xx responses.
Meal database size global
total_meals · static
669
The total number of meals in the database is 669 as of 2026. The free tier exposes the full V1 catalog; the supporter tier additionally enables custom meal submission.

Policies

Client-side caching
Cache semi-static resources such as category lists (/categories.php), area lists (/list.php?a=list), ingredient lists (/list.php?i=list), and individual meal details (/lookup.php?i=ID) locally with an appropriate TTL (e.g. 24 hours) to minimize redundant API calls.
Respectful polling
Because no documented rate limit exists, consumers should implement request throttling in their client (e.g. ≤1 request/second for the shared test key) and avoid burst patterns that could degrade service for other users of the shared key.
Exponential backoff
On HTTP 429 or 5xx responses, apply exponential backoff with jitter before retrying. Do not immediately retry failed requests.
Production use
High-volume or commercial production workloads should upgrade to a supporter key (£10 lifetime) rather than relying on the shared test key "1".

Sources