Datenbank-Updates und Legacy-Food-Handling

Unsere Food-Datenbank wird kontinuierlich aktualisiert. Das bedeutet, dass sich durchsuchbare Food-Daten häufig ändern können, teilweise sogar innerhalb eines Tages.

Wir erhalten und verarbeiten regelmässig grosse Mengen neuer und aktualisierter Food-Daten. Dazu gehören neu angelegte Foods, umbenannte Foods, aktualisierte Nährwerte, geänderte Produktinformationen sowie Foods, die entfernt oder ersetzt werden.

Diese Updates sind wichtig, um die Datenbank korrekt und aktuell zu halten. Ausserdem können wir damit auf aktuelle Produktverfügbarkeit, saisonale Sortimente und zeitlich begrenzte Produkte reagieren, z. B. Süsswaren oder Markenprodukte rund um Feiertage wie Ostern oder Weihnachten. Nutzer erwarten, dass sie neue Produkte aus dem Supermarkt zeitnah auch in unserer API finden.

Daher sollten Suchergebnisse als dynamisch betrachtet werden. Ein Food, das heute in der Suche erscheint, kann später umbenannt, ersetzt, zusammengeführt werden oder in dieser Form nicht mehr auftauchen. Das ist erwartetes Verhalten und nicht zwingend ein Fehler.

Das bedeutet aber nicht, dass zuvor getrackte Foods sofort unbrauchbar werden. Um bestehende User-Historien und Integrationen zu unterstützen, pflegen wir nach Möglichkeit interne Mappings für gelöschte, umbenannte, zusammengeführte oder anderweitig geänderte Foods.

Wir garantieren 6 Monate Legacy-Handling: Wenn ein Nutzer ein Food getrackt hat, bevor es entfernt oder geändert wurde, kann es sein, dass das alte Food nicht mehr in Suchergebnissen erscheint. Auswertungen mit der zuvor gespeicherten Food-Referenz lassen sich in der Regel dennoch über unser Legacy-Handling verarbeiten.

Empfohlenes Integrationsverhalten

• Suchergebnisse als dynamisch und änderungsanfällig behandeln.
• Food-IDs bzw. Referenzen speichern, die für getrackte Foods verwendet wurden.
• Nicht aus der Suchverfügbarkeit ableiten, ob ein zuvor getracktes Food noch gültig ist.
• Für Auswertungen weiterhin die zuvor gespeicherten Food-Referenzen senden.
• Getrackte Foods nicht automatisch ersetzen, nur weil ein aktuelles Suchergebnis anders aussieht.
• Damit rechnen, dass Namen, Nährwerte, Portionsgrössen, Processing-States und Produktmetadaten sich im Laufe der Zeit verbessern oder ändern.
• Wenn User-Logs oder historische Protokolle über den garantierten Kompatibilitätszeitraum hinaus reproduzierbar bleiben müssen, speichern Sie Auswertungsergebnisse und weitere notwendige Informationen auf Ihrer Seite.

Legacy-Data-Handling

Wenn Ihre Anwendung langfristige Reproduzierbarkeit historischer User-Logs über den garantierten Kompatibilitätszeitraum hinaus benötigt, sollten Sie die finalen, userseitigen Auswertungsergebnisse und erforderliche Protokollinformationen auf Ihrer Seite speichern, vorbehaltlich Ihres Lizenzvertrags mit Newtrition Data.

Für vertraglich lizenzierte Produktdaten setzt das Speichern oder Cachen von API-Antworten und abgeleiteten Food-Daten eine gültige, aktive Lizenz mit Newtrition Data UG (haftungsbeschränkt) voraus. Daten, die diesen vertraglichen Einschränkungen unterliegen, müssen beim Ende der Lizenz bzw. des Vertrags gelöscht werden und dürfen nicht an nicht lizenzierte Dritte weitergegeben werden. Rechte aus quellenspezifischen offenen Lizenzen, einschließlich BLS und OFF, richten sich weiterhin nach diesen Lizenzen. Siehe Lizenzen und Hinweise für API-Kunden.

Historische User-Logs und Protokollergebnisse sollten daher so gespeichert werden, dass nach Ende der Lizenz keine Newtrition Data Food-Einträge rekonstruiert oder weiterverwendet werden. Wenn Langzeitaufbewahrung erforderlich ist, empfehlen wir, statt vollständiger Food-Objekte oder wiederverwendbarer API-Antworten nur finale Auswertungsergebnisse und die minimal für Ihre Anwendung benötigten Protokollinformationen zu speichern.

Weitere Informationen finden Sie hier