(S) Limited amount of calls per second.

Returns the list of most likely ingredients (recipe-like) associated with the recognized or confirmed food items.

Make sure you first confirm the correct food items through POST /v2/image/confirm/dish before calling this endpoint when the automatic prediction is not correct.

Otherwise, the top-1 prediction for each detected food-item position is considered the correct food and its recipe is returned.

By default, the information is scaled to the standard/average portion for one person.
If POST /v2/nutrition/confirm/quantity has been used, the ingredient quantities are rescaled according to the confirmed quantity of each food item.

The weight attribute associated with every recipe ingredient is expressed in grams or milliliters, depending on the ingredient/unit context.

For itemized intakes, the response may additionally include recipe_per_item, containing the recipe associated with each independent food_item_position.

This applies to both:

• segmentation intakes, whose positions commonly use values such as 1, 2, 3, ...;
• mixed/manual intakes, whose positions use values such as manual1, manual2, manual3, ...

Mixed/manual intakes can be created through POST /v2/intake/manualInput/USERID or obtained by confirming an existing image through POST /v2/image/confirm/dish.

For mixed intakes, each entry in recipe_per_item includes a type describing the effective top-level food item:

• dish
• ingredient
• custom_recipe
• barcode_food_item

Favorites are expanded when the intake is created, so they are returned as their effective resulting food items rather than with type=favorite.

Recipe components also include a type:

• ingredient
• barcode_ingredient

Barcode ingredients are identified through barcode_class_id.

A top-level item with type=ingredient may have dish_id=null because it does not correspond to a catalog dish. It can still contain a valid recipe and contribute to the intake's nutritional information.