NutritionSignals

Rate limits

NutritionSignals applies rate limits to protect the platform and ensure consistent performance for everyone. This page explains how rate limiting works and how to handle it safely in production.

Exact limits may vary by plan and can change over time. Your API responses may include headers that help you understand remaining quota and reset times.

What to expect

Most requests complete normally. When you exceed a limit, the API responds with:

  • 429 — Rate limited

See Errors for the full error format and examples.

1) Use exponential backoff

When you receive a 429, retry with exponential backoff and jitter to avoid synchronized retries.

Suggested strategy:

  • Start at 500ms
  • Double each retry: 500ms → 1s → 2s → 4s → 8s
  • Add small random jitter (±20%)
  • Stop after 5–7 retries and surface a user-friendly error

2) Respect retry hints

If the API returns a Retry-After header, treat it as the primary signal for when to retry.

HTTP/1.1 429 Too Many Requests
Retry-After: 2

3) Avoid bursty traffic

If you need to resolve many items (for example, importing a pantry or scanning a receipt), throttle requests on the client:

  • Limit concurrent requests (for example, 2–5 at a time)
  • Queue the rest
  • Use backoff when you hit 429

Example backoff helpers

# Constant-delay retry using curl flags
curl --retry 6 --retry-all-errors --retry-delay 1   -H "Authorization: Bearer $NUTRITIONSIGNALS_API_KEY"   -H "Content-Type: application/json"   https://api.nutritionsignals.com/v1/foods/resolve   -d '{"text":"Chobani Greek Yogurt, strawberry, 5.3 oz"}'

The cURL example uses a constant retry delay. For true exponential backoff in shell scripts, wrap curl in a loop and double the delay after each 429.

Errors

  • 429 — Rate limited
  • 401 — Missing/invalid API key (often confused with rate limiting)
  • 5xx — Server error
Read Errors

Was this page helpful?