specification: API Commons Rate Limits specificationVersion: '0.1' schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits provider: fatsecret providerId: fatsecret created: '2026-05-04' modified: '2026-08-12' generated: '2026-08-12' method: searched source: https://platform.fatsecret.com/api-editions docs: editions: https://platform.fatsecret.com/api-editions error_codes: https://platform.fatsecret.com/docs/guides/error-codes limit_count: 2 note: >- Replaced the 2026-05-04 bulk-sweep scaffold, which invented X-RateLimit-* headers, HTTP 429 responses, per-minute limits and burst ceilings that fatsecret does not publish or emit. What the provider actually publishes is a single daily call quota on the free Basic edition and "Unlimited" on both Premier editions, with exhaustion signalled ONLY as a numeric error code inside the response body. tags: - Barcode Scanning - Calories - Nutrition - Rate Limiting - Quotas - Throttling description: >- Published rate limits for the fatsecret Platform API. The runtime signal is the weak point for agents: there are no rate-limit response headers of any kind, no Retry-After, and no distinct HTTP status. A client only learns it is over quota by parsing error.code == 11 out of a body that otherwise looks like a normal response. headers: limit: null remaining: null reset: null retryAfter: null policy: null observed: false note: >- No X-RateLimit-*, no RateLimit-* (RFC 9331 draft), and no Retry-After are documented in the guides or referenced anywhere in the editions page. responseCodes: throttled: null quotaExceeded: null note: >- Rate limiting is not signalled by HTTP status. The signal is the vendor error envelope: {"error":{"code":11,"message":"Application request limit reached: '
'"}} signals: - code: 11 scope: application meaning: Application request limit reached — the edition's call quota is exhausted source: https://platform.fatsecret.com/docs/guides/error-codes - code: 12 scope: profile meaning: User is performing too many actions — a per-member throttle, independent of the app quota source: https://platform.fatsecret.com/docs/guides/error-codes limits: - tier: Basic name: Basic edition daily quota scope: api-key metric: requests_per_day limit: 5000 burst: null timeFrame: day published: '"5,000 API calls/day"' source: https://platform.fatsecret.com/api-editions applies: - fatsecret Platform API - tier: Premier Free name: Premier Free edition scope: api-key metric: requests limit: -1 timeFrame: none published: '"Unlimited"' source: https://platform.fatsecret.com/api-editions applies: - fatsecret Platform API - tier: Premier name: Premier edition scope: contract metric: requests limit: -1 timeFrame: none published: '"Unlimited"' source: https://platform.fatsecret.com/api-editions applies: - fatsecret Platform API policies: - name: Per-profile throttle description: >- Error code 12 is scoped to one member, not the application. Back off for that profile only; other members are unaffected. - name: Backoff strategy description: >- With no Retry-After and no reset header, a client cannot compute a wait. On error 11 the only safe behaviour is to stop calling for that key and resume on the next day boundary; on error 12 use exponential backoff with jitter for that member. maintainers: - FN: Kin Lane email: kin@apievangelist.com