Conditions to use the Open Food Facts API

BE HELPED 💬
1

All the documentation about API usage can be found on the API documentation page, but here is a quick summary:

  • The Open Food Facts database is available as open data under the Open Database License (ODbL), see Terms of use, contribution and re-use for the legal details. The two conditions are attribution and share-alike. If you combine data from Open Food Facts with other databases, then the ODbL requires that the resulting database must be released as open data as well. It also means that you can combine the data only with sources that would allow such redistribution.

  • You must always use a custom User-Agent when performing API calls to identify your app.

  • Rate-limits are enforced for each API endpoint.

1 Like
2

API Usage, Caching, and User-Agent Handling for iOS Apps and Web App

Hi,

I’m developing several iOS applications and a web app, and I’m considering integrating a barcode scanner feature using the Open Food Facts API. I’m currently experimenting with the API through https://www.nutridata.io/, and I have some questions regarding API usage, caching strategies, and best practices.

Current Observations and Concerns

  1. While direct API calls generally work well, I occasionally encounter long delays or even no response. This could significantly impact user experience and potentially lead to negative app reviews.

  2. To mitigate these issues, I’m considering implementing a local app cache. However, this may not fully address the problem for all users.

Proposed Solution: Additional Caching Layer

To further improve reliability and reduce API load, I’m contemplating adding an intermediate caching layer between the API and my apps (both iOS and web). This cache would have a relatively long retention time.

Potential Benefits:

  • Mitigates possible issues with API availability
  • Reduces overall API load
  • Improves response times for frequently requested data

Potential Concerns:

  • Initial period when the cache is empty could lead to a high number of API requests
  • Possible conflict with API rate limits

Questions

  1. Is implementing such an intermediate caching layer acceptable according to Open Food Facts’ terms of use and best practices?

  2. If caching is acceptable, how should I handle the ‘User-Agent’ header? I have both iOS apps and a web app to consider:

    • For iOS apps: Should I pass the original custom User-Agent from the iOS app to the API through the caching layer?
    • For the web app: Should I pass the browser’s User-Agent to the API, or use a custom User-Agent for my web app?
    • Alternatively, should I use a fixed User-Agent for the caching server that’s different for iOS and web requests?
    • Would it be beneficial to add information about the caching server to the User-Agent string?

  3. Given that requests from the caching layer will come from the same IP address (or perhaps 2-3 IPs for redundancy), should I implement and pass an ‘X-Real-IP’ header to indicate the original requester’s IP?

  4. Are there any specific parameters I can use in API requests to filter out products with incomplete data? I’ve noticed that search results often include products with missing names or images.

I appreciate any guidance you can provide on these matters. My goal is to create a reliable and efficient integration for both my iOS apps and web app while respecting Open Food Facts’ infrastructure and policies. I want to ensure that I’m following best practices and using the API in a way that’s beneficial both to my users and to the Open Food Facts project.

Thank you for your time and assistance. I look forward to your insights and recommendations.

3

Hello corundex,
Implementing an intermediate server cache is a good idea, that’s what most larger third-party app who use our data do.
The best way to populate the cache is to use our JSONL export, so that you don’t have to query the API with many requests (and get rate-limited).

1 Like