Salt and Sodium Consistency Is a Nutrition API Requirement

A small data-quality flag with large product implications

Nutrition data looks precise because it is numeric. That is also why it can mislead product teams. A recipe or meal-planning app may show sodium, salt, calories, protein, and serving-level totals with two decimal places, while the underlying data came from a label, a supplier feed, OCR, a user edit, an AI extraction pass, or a computed recipe aggregate. If those sources disagree, the API can still return a valid JSON response. The product is the thing that becomes wrong.

A useful current signal came from Open Food Facts on July 6, 2026. The project added a new salt/sodium consistency data-quality facet, en:nutrition-packaging-as-sold-100g-salt-does-not-match-sodium, to flag products where declared salt and sodium values are inconsistent. The change landed in Open Food Facts server commit 4a792c0, including unit tests and expected export changes. The same day, the project published release 2.97.0, whose changelog lists the salt/sodium consistency facet among the release features.

That may sound like a packaged-food database detail, not a recipe API topic. It is the opposite. Most modern recipe products blend recipes, branded products, pantry items, restaurant-like meals, and grocery substitutions. Sodium is one of the first nutrients users filter, clinicians care about, and meal planners summarize. If an API treats salt and sodium as isolated columns, rather than as related measurements with source and validation state, downstream products inherit silent errors.

The lesson is not merely “check sodium.” It is that nutrition APIs need relationship validation: rules that understand how fields should correspond, where tolerance is allowed, and how to represent uncertainty without overwriting evidence.

Salt and sodium are not interchangeable fields

Developers often encounter both fields because food labels and datasets vary by jurisdiction and source. Some product feeds expose salt. Others expose sodium. Some expose both. Recipe nutrition calculators may compute sodium from ingredient databases, then display salt equivalents for users in markets where salt is the familiar label term.

The relationship is straightforward enough to validate but easy enough to mishandle. Salt is sodium chloride. Sodium is only part of that compound. In common nutrition conversions, salt is approximately sodium multiplied by 2.5, and sodium is approximately salt divided by 2.5. The important API design point is not the chemistry; it is that a value pair has a known relationship and should not be accepted as two independent facts.

Consider a product record that says:

{
  "nutrients_per_100g": {
    "salt_g": 1.2,
    "sodium_g": 1.2
  }
}

A schema validator can confirm both values are numbers. A type system can confirm both are grams per 100 grams. A UI can render both. But a nutrition-quality rule should flag the record because 1.2 g sodium would imply roughly 3.0 g salt, not 1.2 g salt. The most likely problems are unit confusion, duplicated label values, OCR extraction error, a supplier mapping bug, or a user entering the visible salt value into a sodium field.

For recipe APIs, this matters in three common workflows:

• A meal planner filters recipes below a sodium threshold.
• A grocery-aware recipe app substitutes branded products into a recipe and recomputes nutrition.
• A health-focused product explains why a recipe is “high sodium” or “low sodium.”

All three fail if the API cannot distinguish declared sodium, declared salt, computed salt equivalent, and suspect values.

The API should preserve evidence and add validation state

A tempting fix is to normalize everything at ingestion and store only one canonical nutrient. That works for simple search filters, but it throws away useful evidence. If a package label declares salt and a supplier feed declares sodium, the API should preserve both declarations, store their sources, and add a quality assessment.

A more durable model separates raw observations, normalized nutrient values, and validation results:

{
  "food_id": "off:example",
  "nutrition_basis": "as_sold",
  "quantity_basis": "per_100g",
  "nutrients": {
    "sodium": {
      "amount": 0.48,
      "unit": "g",
      "source": "derived_from_declared_salt",
      "source_field": "salt",
      "confidence": 0.92
    },
    "salt": {
      "amount": 1.2,
      "unit": "g",
      "source": "package_label",
      "confidence": 0.98
    }
  },
  "quality_flags": [
    {
      "code": "salt_sodium_consistency_checked",
      "severity": "info",
      "basis": "salt ~= sodium * 2.5",
      "checked_at": "2026-07-06"
    }
  ]
}

For a mismatch, the API should not silently choose a winner unless the source hierarchy is explicit. A safer response is to return both values with a warning:

{
  "quality_flags": [
    {
      "code": "salt_sodium_mismatch",
      "severity": "warning",
      "message": "Declared salt and sodium values are inconsistent for the same 100g basis.",
      "expected": { "salt_g_from_sodium": 3.0 },
      "observed": { "salt_g": 1.2, "sodium_g": 1.2 }
    }
  ]
}

This is better for product teams than returning a single “clean” sodium number. It lets the UI decide whether to hide a claim, show a caveat, request review, or use a fallback data source.

Validation must be basis-aware

The Open Food Facts change is specifically framed around packaging nutrition “as sold” values per 100 g. That detail matters. Nutrition data can be per 100 g, per 100 ml, per serving, per package, as sold, as prepared, or recipe-yield adjusted. A salt/sodium check is only meaningful when both values share the same basis.

Recipe APIs should therefore avoid nutrient fields that float without context:

Risky field	Better field design
sodium: 480	nutrients.sodium.amount, unit, basis, quantity, source
salt: 1.2	nutrients.salt.amount, unit, basis, quantity, source
nutrition.valid: true	quality_flags[] with rule code, severity, and affected fields
servingSize: "1 bowl"	structured serving quantity plus display text
overwritten derived values	declared values plus derived equivalents and provenance

Basis-aware validation is especially important for recipes. A recipe may have ingredient-level nutrition per 100 g, a total cooked yield, a serving count, and optional branded grocery items. Sodium can change dramatically when the user switches from canned beans to no-salt-added beans, or from unsalted butter to salted butter. The API should know whether it is validating an ingredient label, a normalized ingredient entity, or the final recipe total.

Product behavior should change when quality flags exist

Quality flags are only useful if products consume them. For developer-facing APIs, the response contract should make it obvious how to act.

A practical decision framework:

Quality state	API behavior	Product behavior
Values consistent and sourced	Return values normally with provenance	Enable filters, claims, and meal-plan summaries
One value declared, the other derived	Return declared value and derived equivalent	Display one user-facing value; keep derivation in details
Values inconsistent	Return both values and a warning flag	Avoid strong health claims; route to review or fallback
Basis mismatch	Do not compare values	Ask for serving/yield normalization before ranking
Missing source	Return lower confidence	Use for broad discovery, not regulated or clinical messaging

This approach helps both engineering and business teams. Engineers get deterministic rules and testable behavior. Product managers get a way to decide when a nutrition feature is safe enough to ship. Technical buyers evaluating a recipe API can ask whether the provider exposes nutrition provenance and quality flags, not just whether it has “nutrition data.”

Implementation checklist for recipe and meal-planning APIs

Use the salt/sodium example as the first rule in a broader nutrition-quality layer:

• Store nutrient amount, unit, basis, and source separately.
• Preserve declared label values before deriving equivalents.
• Validate known nutrient relationships, including salt/sodium and macro subcomponents where applicable.
• Treat per-100g, per-serving, as-sold, and as-prepared values as different contexts.
• Return machine-readable quality flags with stable codes.
• Include severity levels so clients can filter warnings from hard errors.
• Expose affected fields and expected ranges when a value fails validation.
• Keep validation rule versions so old cached results can be rechecked.
• Add tests for unit confusion, duplicated values, zero values, and serving-basis mismatches.
• Document how clients should handle nutrition warnings in search, meal planning, and grocery substitution workflows.

The point is not to block every imperfect record. Food data is messy. The point is to make the mess visible and operational.

Where Recipe API should position the feature

For Recipe API customers, this is a strong example of why “has nutrition fields” is not enough. Builders need nutrition data that can survive product use: filtering, personalization, grocery substitutions, generated recipes, and user-facing explanations.

A Recipe API response that includes sodium should also help a developer answer:

• Was this value declared, computed, inferred, or manually corrected?
• Is it per 100 g, per serving, per recipe, or per prepared yield?
• Is there a related salt value, and does it agree?
• Can this value be used for ranking and dietary filters?
• Should the UI show a caveat or request review?

Those answers turn nutrition from a static data column into infrastructure. They also reduce support risk. When a user challenges a sodium value, the product can show source and validation state rather than hand-wave behind a black-box number.

Sources

• Open Food Facts, commit adding the salt/sodium consistency data-quality facet, July 6, 2026.
• Open Food Facts, server release 2.97.0 changelog commit, July 6, 2026.
• Open Food Facts, Food Data Quality documentation, background on quality flags and product-data checks.