Confirms or corrects the food items associated with an existing image intake.

This endpoint supports two different request contracts:

• Legacy confirmation using confirmedClass and source.
• Unified mixed confirmation using dishes.

These two formats are mutually exclusive. A request must use either confirmedClass / source or dishes, never both.

Legacy confirmation

The legacy format keeps the existing dish-confirmation behavior.

confirmedClass contains the confirmed food classes and source identifies where each class comes from.

By default, source is logmeal, in which case each corresponding confirmedClass value must be an existing LogMeal dish ID.

source may also be other, allowing a free-text food label. Free-text foods are stored as feedback but cannot be used for calculations that require a LogMeal dish, such as generating catalog ingredients or nutrition.

When confirming a segmentation image, food_item_position must identify the segment corresponding to each confirmed item.

If an additional food item does not correspond to an existing segment, a unique string position may be supplied for that item.

The complete desired list must be sent. Food items omitted from the confirmation are removed from the stored dish/recipe feedback.

For regular API intakes, valid LogMeal dish IDs can be retrieved through GET /v2/dataset/dishes.

For kiosk/tray intakes, the legacy format must be used and valid restaurant dish IDs can be retrieved through GET /v2/kiosk/external/dishes.

The intake type can be inspected through GET /v2/intake/{imageId} or GET /v2/history/getIntakesList.

If is_kiosk_image is true, the image belongs to the kiosk/tray flow. In that case, the legacy confirmation contract must be used together with the corresponding restaurant dish IDs.

Unified mixed confirmation

The unified format uses the same typed food-item contract as POST /v2/intake/manualInput/USERID.

It supports:

• dish
• ingredient
• favorite
• custom_recipe
• barcode_food_item

Nested ingredients may use:

• ingredient
• barcode_ingredient

The image owner determines the context used to resolve private resources.
Therefore:

• favorites must belong to the image owner;
• custom recipes must belong to the image owner's APICompany;
• ingredient-measure permissions are evaluated using that user's context.

An APIUser may confirm their own image. An APIUserManager may confirm an image belonging to an APIUser they are authorized to manage.

Top-level items of type ingredient must provide name in this endpoint.
Unlike a catalog dish, an ingredient-only item has no GeneralClass ID from which a food name can be obtained.

The unified dishes format is not supported for kiosk/tray images.
Those images must continue using the legacy confirmedClass / source contract.

Recognition-only images

Recognition-only images do not have independent food-item positions.

When they are confirmed using dishes, the API converts the confirmed foods into an itemized mixed intake and automatically generates stable positions:

manual1, manual2, manual3, ...

No artificial segmentation regions are created.

Segmentation images

Segmentation images already contain independent food-item positions.

In this case, food_item_position must be supplied and each position must correspond to the final resolved food-item list.

Existing recipes are preserved when their food item is unchanged.
Explicit ingredient, quantity and modifier changes provided in dishes are then applied to their corresponding positions.

A favorite may expand into several saved food items. If that happens, food_item_position must contain one position for every expanded favorite item, not only one position for the top-level favorite entry.

After all dish, ingredient and quantity changes have been applied, nutritional information is recalculated once using the final intake state.

Legacy example

{
  "imageId": 1982196,
  "confirmedClass": [2284, 2270, 2299, 2267],
  "source": ["logmeal", "logmeal", "logmeal", "logmeal"],
  "food_item_position": [1, 2, 3, 4]
}

Unified recognition example

{
  "imageId": 1982196,
  "dishes": [
    {
      "type": "dish",
      "id": 123,
      "quantity": 250
    },
    {
      "type": "ingredient",
      "name": "Homemade salad",
      "ingredients": [
        {
          "type": "ingredient",
          "ingredientId": 140,
          "ingredientAmount": 120
        },
        {
          "type": "barcode_ingredient",
          "barcodeClassId": 9502,
          "ingredientAmount": 30
        }
      ]
    },
    {
      "type": "barcode_food_item",
      "id": 9501,
      "quantity": 100
    }
  ]
}

For barcode items, resolve the product first through POST /v2/barcode_scan/{barcode_id}.