Food Central API schema incorrect/inconsistent

[micimize]

The results of /v1/foods/search's nutrients have nutrient* prefixes for some fields and value instead of amount. I haven't found inconsistencies elsewhere, but have not looked thoroughly (although /v1/foods/list looks alright)

curl -X POST "https://api.nal.usda.gov/fdc/v1/foods/search?api_key=$API_KEY" -H  "accept: application/json" -H  "Content-Type: application/json" -d "{\"query\":\"peas\"}"

{
  "nutrientId": 1087,
  "nutrientName": "Calcium, Ca",
  "nutrientNumber": "301",
  "unitName": "MG",
  "derivationCode": "LCCD",
  "derivationDescription": "Calculated from a daily value percentage per serving size measure",
  "value": 0
}

[micimize]

one way to test this would be to run a strict json schema validator like ajv against every endpoint for a handful of criterion

[hphungnal]

@micimize Thanks for bringing this to our attention. I confirmed the issue and have posted it to the team. Hopefully it will be fixed in our upcoming October update.

[chris-heney]

This is a huge issue; I also noticed this as I was getting "undefined" randomly with our integration when referencing foodPortions[i].amount property. The data inconsistencies can be found using the specific examples below.

dataType and foodClass do not depict any indication of harmonious response in the data schematic returned.

No foodPortions property AND no servingSize / servingSizeUnit

[https://api.nal.usda.gov/fdc/v1/food/169814?api_key=KEY](https://api.nal.usda.gov/fdc/v1/food/169814?api_key=KEY) { dataType: 'SR Legacy', foodClass: 'finalFood' }

Has foodPortions property BUT no servingSize / servingSizeUnit

[https://api.nal.usda.gov/fdc/v1/food/171353?api_key=KEY](https://api.nal.usda.gov/fdc/v1/food/171353?api_key=KEY) { dataType: 'SR Legacy', foodClass: 'finalFood' }

No foodPortions property BUT has servingSize / servingSizeUnit

[https://api.nal.usda.gov/fdc/v1/food/1497403?api_key=KEY](https://api.nal.usda.gov/fdc/v1/food/1497403?api_key=KEY) { dataType: 'Branded', foodClass: 'Branded' }

The Bottom Line

Without having the weight that the nutrients represents, the foodNutrients data is useless as it cannot be converted / applied to our own Unit of Measure for our meals and recipes.

Moreover, I would prefer the /foods/search endpoint to return the serving size and serving size unit of measure. Otherwise, all of the nutrient data that comes back in the search response is useless because you don't know what weight/portion-size of the ingredient is being measured.

Either (A) take the nutrient data off the search response to save overhead of useless data, or (B) include the 2 critical points of data bringing the nutrient data into some sort of applicable context. Even if it worked as expected, developers would have to make an additional API call for each search result (👎 ).

I'm going to have to investigate other nutrition providers like Eamons and Fat Secret to see if I can get more reliable datasets.