Zuckerzufuhr-Rechner

Der Pfad ist reine deterministische Arithmetik ohne Netzwerkanrufe und ohne Zufallsseed, sodass Coaching-Apps, Mahlzeitenplaner und vorausbezahlte API-Clients jedes Mal identisches JSON erhalten. Nicht positive Kalorienzufuhr wird als invalid_input abgelehnt, weil ein Null- oder Negativ-Energiebudget keine Zuckerzulage definieren kann.

Was der Rechner misst und welche Eingaben Sie brauchen

Senden Sie calorie_intake als positive endliche Zahl von Kilokalorien pro Tag; Aliase calories, kcal, energy_kcal und calorie_intake_kcal werden akzeptiert, damit Wellness-Apps vorhandene Feldnamen ohne Umbenennung der Nutzlasten zuordnen können. Senden Sie guideline_percentage als positive endliche Zahl größer als null und höchstens einhundert; lassen Sie sie weg, verwendet die Engine zehn, die übliche WHO- und FDA-Energieanteilsgrenze. Aliase percent, pct, sugar_percent und added_sugar_percent zeigen auf dasselbe Feld. Fehlende Kalorienzufuhr, leere Zeichenketten, nicht endliche Zahlen und jede Kalorienzufuhr von null oder negativ scheitern mit invalid_input und werden nicht berechnet. Identische Eingaben ergeben immer identisches JSON, weil der Pfad nie Netzwerk, Sprachmodell, Uhr oder Zufallsgenerator berührt.

Antwortfelder lesen und typische Fallstricke

Bei Erfolg echo't die Antwort calorie_intake_kcal und guideline_percentage, dann sugar_kcal (die Energiescheibe für zugesetzten Zucker), max_added_sugar_g (die Haupt-Gramm-Obergrenze) und teaspoons mit vier Gramm je Teelöffel, damit Küchenlöffel mit Etiketten vergleichbar sind. Das Feld kcal_per_gram ist stets vier, unit stets g/day, formula stellt dar, dass Gramm gleich Kalorien mal Prozent durch einhundert durch vier sind, und method ist stets energy_percent_added_sugar, damit Downstream-Code ohne Shape-Sniffing verzweigen kann. Nutzen Sie max_added_sugar_g, wenn ein Mahlzeitenplaner nur eine skalierbare Tagesobergrenze braucht; nutzen Sie sugar_kcal, wenn Bildungsmaterialien das Energiebudget neben der Grammzahl zeigen müssen; nutzen Sie teaspoons, wenn Sie mit Menschen sprechen, die in Löffeln statt in Gramm denken.

API-Nutzung, Preise, Coaching-Workflows und praktische Grenzen

Rufen Sie den kostenlosen Zuckerzufuhr-Rechner im Browser für schnelle Checks, Kundenbildung, Vorlesungsdemos und Etikettenplanung beim Einkauf auf, ohne eine Ernährungstabelle zu installieren. Bevorzugen Sie Kalorienzufuhren, die bereits zur täglichen Energieschätzung Ihres Produkts passen—kennen Sie nur Makros, rechnen Sie diese zuerst in Kilokalorien um. Halten Sie die Erwartungen pädagogisch: dies ist ein Planungs- und Literalitätswerkzeug, kein diagnostisches Medizinprodukt, und Nutzer mit atypischen Bedarfen sollten klinischer Führung folgen statt einer einzelnen Formel allein. Zehn Prozent von zweitausend Kalorien sind fünfzig Gramm; fünf Prozent sind fünfundzwanzig Gramm; diese beiden Prüfpunkte zitieren die meisten Public-Health-Seiten, und dieser Rechner reproduziert sie genau, damit Ihre Oberfläche nie von einer Etikettenfußnote abweicht. Senden Sie einen JSON-Body mit erforderlichem calorie_intake (oder einem Alias) und optional guideline_percentage. Nutzen Sie die vorausbezahlte API, wenn ein Wellness-SaaS, ein Telehealth-Aufnahmeformular, ein Schulkantine-Planer oder eine Kalorien-Tracking-Pipeline einen stabilen Vertrag zu $0.002 pro erfolgreichem Element braucht; Validierungsfehler verbrauchen nach Ablehnung durch die Engine nie Guthaben. Koppeln Sie diesen Endpunkt mit Ihrer eigenen Essensprotokoll-Datenbank: berechnen Sie hier die Gramm-Obergrenze und bewerten Sie protokollierten zugesetzten Zucker gegen max_added_sugar_g auf dem Client. SDK-Autoren können max_added_sugar_g, sugar_kcal und teaspoons in Dashboard-Karten und CSV-Spalten mit den Labels Gramm-Obergrenze, Zuckerenergie und Löffel mappen—dieselben Zahlen, die Ernährungsfachkräfte von Hand schreiben, wenn sie zehn Prozent der Kalorien geteilt durch vier auf Papier anwenden.