Database Updates and Legacy Food Handling

Our food database is updated continuously. This means that searchable food data can change frequently, sometimes even within the same day.

We regularly receive and process large amounts of new and updated food data. This includes newly created foods, renamed foods, updated nutrient values, changed product information, and foods that are removed or replaced.

These updates are important to keep the database accurate and relevant. They also allow us to react to current product availability, seasonal collections, and limited-time products, such as sweets or branded products released around holidays like Easter or Christmas. Users expect to find new food they see in the supermarket to directly find in our API.

As a result, search results should be treated as dynamic. A food that appears in search today may be renamed, replaced, merged, or no longer appear in the same form later. This is expected behavior and not necessarily an error.

However, this does not mean that previously tracked foods immediately become unusable. To support existing user histories and integrations, we maintain internal mappings for deleted, renamed, merged, or otherwise changed foods where possible.

We guarantee a 6 months legacy handling: For example, if a user tracked a food before it was removed or changed, the old food may no longer appear in search results. However, evaluations using the previously stored food reference can usually still be processed through our legacy handling.

Recommended integration behavior:

• Treat search results as dynamic and subject to frequent changes.
• Store the food IDs or references used for tracked foods.
• Do not rely on search availability to determine whether a previously tracked food is still valid.
• Continue sending previously stored food references for evaluation.
• Avoid automatically replacing tracked foods only because the current search result looks different.
• Expect names, nutrient values, serving sizes, processing states, and product metadata to improve or change over time.
• If you need to guarantee that user logs or historical protocols remain fully reproducible for more than the guaranteed compatibility period, store the evaluated results and any other required information on your side.

Legacy Data Handeling

If your application requires long-term reproducibility of historical user logs beyond the guaranteed compatibility period, you should store the final user-facing evaluation results and any required protocol information on your side, subject to your license agreement with Newtrition Data.

Please note that storing or caching API responses, individual food entries, nutrient data, serving sizes, processing states, or other database-derived food data is only permitted while you maintain a valid and active license with Newtrition Data UG (haftungsbeschränkt). All such stored or cached data must be deleted when the license or contract ends, and it must not be shared with unlicensed third parties.

Historical user logs and protocol results should therefore be stored in a way that does not recreate or continue to use Newtrition Data food entries after the license has ended. If long-term retention is required, we recommend storing only the final evaluated results and the minimum protocol information required for your application, rather than storing full food objects or reusable API responses.

More information can be found here