KI-Produktanalyse: Zusammenfassungen, die deine Nutzer wirklich verstehen

Das Problem mit rohen Nährwertdaten

Deine API-Antwort sagt sugars_g: 56.3. Dein Nutzer will wissen: Ist das viel? Diese Lücke zu schließen — Zahlen und Zutatenlisten in etwas zu verwandeln, mit dem ein Mensch etwas anfangen kann — ist meist der Punkt, an dem Ernährungs-Apps entweder viel investieren oder aufgeben.

Die Analyse-Endpunkte übernehmen diesen Schritt für dich: Ein Aufruf liefert eine kurze, sachliche und verständliche Analyse, die ausschließlich aus den Produktdaten erzeugt wird. Die Urteile — was hoch ist, was ein Pluspunkt ist, welche Allergene, welche Ernährungsformen — beruhen auf festen, veröffentlichten Schwellenwerten, die im Code angewendet werden. Die KI schreibt die Zusammenfassung in zwei Sätzen und liest die Zutatenliste, wo eine Einschätzung nötig ist. Keine erfundenen Zahlen, keine gesundheitsbezogenen Angaben und lieber „unbekannt“ als eine Vermutung.

Ein Katalogprodukt analysieren

POST /v1/analyze/product nimmt eine food_id oder einen barcode (eines von beiden), kostet 4 Credits und antwortet in jeder der 6 Sprachen:

curl -X POST "https://foodbase.dev/v1/analyze/product" \
  -H "X-API-Key: food_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"barcode": "3017620422003", "lang": "en"}'

{
  "food_id": "…",
  "lang": "en",
  "cached": false,
  "analysis": {
    "summary": "Nutella is a hazelnut and cocoa chocolate spread from Ferrero, made mainly with sugar and palm oil. It is energy-dense and high in fat, saturated fat and sugars (56.3 g per 100 g), while being low in salt.",
    "highlights": ["Low salt (0.11 g per 100 g)"],
    "warnings": [
      "High in fat (30.9 g per 100 g)",
      "High in saturated fat (10.6 g per 100 g)",
      "High in sugars (56.3 g per 100 g)",
      "Contains palm oil"
    ],
    "allergens": { "contains": ["soy", "milk", "nuts"], "may_contain": [], "text": "Contains: soy, milk, nuts." },
    "diets": { "vegan": "no", "vegetarian": "yes", "gluten_free": "yes", "lactose_free": "no" },
    "diets_detail": {
      "vegan": { "value": "no", "basis": "allergen_tag" },
      "gluten_free": { "value": "yes", "basis": "label_claim" }
    },
    "processing_level": "ultra_processed",
    "processing_basis": "nova",
    "per_serving": "Per serving (15 g): 81 kcal · 4.6 g fat · 1.6 g saturated fat · 8.4 g sugars · 0.02 g salt · 0.9 g protein"
  },
  "disclaimer": "AI-generated from the product's label data…"
}

(Gekürzt: Die Antwort enthält außerdem nutrient_levels, das vollständige diets_detail, nova_group und flags.) Ein paar Dinge, die du über die Struktur wissen solltest:

highlights sind nur Pluspunkte, warnings nur Hinweise — und ein Thema taucht nie in beiden auf. Ein Pluspunkt bedeutet, dass das Produkt die Bedingung einer EU-Nährwertangabe erfüllt (salzarm heißt höchstens 0,3 g pro 100 g; Proteinquelle heißt mindestens 12 % der Energie aus Eiweiß). Ein Hinweis ist ein „hoher“ Wert nach UK FSA, eine große Portion, die das FSA-Limit pro Portion überschreitet, oder Koffein, Süßstoffe, Alkohol oder Palmöl in den Zutaten.
allergens werden separat aufgeführt: die 14 EU-Allergene, die das Etikett angibt, als „enthält“ und „kann enthalten“, mit einem lokalisierten Satz. status: "not_stated" bedeutet, dass der Datensatz keine Allergenangaben hat — schau auf die Verpackung.
diets_detail sagt, woher jede Antwort stammt: aus einer Angabe auf dem Etikett, einem deklarierten Allergen oder der Zutatenliste. Glutenfrei und laktosefrei sind nur mit Etikettenangabe yes; eine Liste ohne glutenhaltige Zutaten ergibt no_known_source, weil ein nicht zertifiziertes Produkt trotzdem verunreinigt sein kann. diets behält die einfache Sicht yes / no / unknown — stell unknown als Fragezeichen dar, nicht als stilles Weglassen.
processing_level stammt aus der erfassten NOVA-Gruppe des Produkts; nur wenn es keine gibt, wird er anhand der Zutaten beurteilt (processing_basis: "model").
disclaimer kommt mit jeder Antwort. Zeig ihn an — die Analyse dient der Information und ist keine medizinische Beratung.

Analysen werden pro Produkt und Sprache gecacht: Der erste Aufrufer wartet auf die Generierung, alle danach bekommen sofort eine Antwort — zum selben Preis von 4 Credits. cached: true verrät dir, welcher Fall eingetreten ist.

Gerendert siehst du diesen Endpunkt auf jeder Produktseite — das Panel „KI-Analyse“ ist genau diese Antwort.

Eigene Produktdaten analysieren

Und was ist mit Produkten, die nicht im Katalog stehen — Eigenmarken, Neuheiten, interne SKUs? POST /v1/analyze/custom (ebenfalls 4 Credits) nimmt die Produktdaten im Request-Body entgegen und führt dieselbe Analyse aus:

curl -X POST "https://foodbase.dev/v1/analyze/custom" \
  -H "X-API-Key: food_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Protein bar cocoa",
    "brand": "MyBrand",
    "ingredients": "Oats, whey protein, cocoa, honey",
    "nutrients": { "energy_kcal": 380, "proteins_g": 30, "sugars_g": 18 }
  }'

Zwei Regeln halten das Ergebnis ehrlich:

Ein bloßer Name wird abgelehnt (422). Du musst Zutaten und/oder mindestens einen Nährwert pro 100 g angeben — sonst hätte das Modell nichts Sachliches zu analysieren.
Unplausible Werte werden abgelehnt, nicht stillschweigend korrigiert. Nährstofffelder haben Obergrenzen pro 100 g (Energie ≤ 900 kcal, Gramm ≤ 100, Natrium ≤ 10000 mg), und unbekannte Nährstoffschlüssel führen zu einem Fehler, statt ignoriert zu werden.

Das Objekt nutrients nimmt die Standard-Makros plus eine ausgewählte Reihe von Vitaminen und Mineralstoffen (Vitamin C, D, B12, Folat, E, Calcium, Eisen, Kalium, Magnesium, Zink). Je mehr du angibst, desto präziser werden die Pluspunkte: Gib Calcium- und Eisenwerte an, und du bekommst etwa „Calciumquelle (150 mg pro 100 g)“, sobald ein Wert den EU-Schwellenwert erreicht (15 % der Referenzmenge pro 100 g; das Doppelte für „reich an“).

Die Antwort entspricht der Katalog-Analyse, mit einem input_hash statt einer food_id — identische Eingaben ergeben denselben Hash, wiederholte Analysen derselben Daten sind also Cache-Treffer. Es gibt außerdem ein optionales Feld barcode: Es wird nicht analysiert, sondern markiert das Produkt als eines, das du gern im Katalog sehen würdest.

Lieber ein Formular als ein JSON-Body? Im Playground gibt es genau diesen Endpunkt als Formular zum Ausfüllen.

Praktische Hinweise zur Integration

Sprache: Übergib lang (en, fr, es, de, it, bg), und die gesamte Analyse — Zusammenfassung, Pluspunkte, Hinweise, Allergene — kommt in dieser Sprache zurück. Die Urteile sind konstruktionsbedingt in jeder Sprache identisch. Jede Sprache wird separat gecacht.
Credits: 4 Credits pro Aufruf, auch bei Cache-Treffern. Fehlschläge (ungültige Anfrage, Provider-Fehler, unbekanntes Produkt) werden automatisch erstattet — du zahlst nur für Antworten.
Idempotenz: gibt es nicht — doppeltes Absenden bedeutet zwei Abbuchungen. Deaktivier deinen Button, solange eine Anfrage läuft.
Darstellung: Die Antwort ist so gestaltet, dass sie sich direkt auf die Oberfläche abbilden lässt — Zusammenfassung als Absatz, Liste der Pluspunkte, Liste der Hinweise, eine Allergenzeile, vier Ernährungs-Badges mit ihrer Grundlage, ein Tag für den Verarbeitungsgrad. Genau so stellen die Produktseiten hier sie dar.
Kaputter Etikettentext? Wenn die Zutatenliste eines Produkts verstümmelt ist (fehlende Leerzeichen, kaputte Zeichen, NUR GROSSBUCHSTABEN), repariert POST /v1/correct/product sie für alle, und die Analyse wird aus dem korrigierten Text neu erzeugt.

Probier es aus

Hol dir einen kostenlosen API-Schlüssel (20 KI-Credits inklusive), öffne die Doku oder spiel mit den Live-Panels auf einer beliebigen Produktseite.