(S) Limited amount of calls per second.

Searches and normalizes the food sources supported by the unified mixed-intake contract.

The endpoint can search:

• dish: regular LogMeal dishes;
• ingredient: regular LogMeal ingredients;
• favorite: favorites owned by the target APIUser;
• custom_recipe: custom recipes belonging to the target APIUser's APICompany;
• barcode_food_item: previously resolved barcode products.

The available values and the types that require search text can also be retrieved through GET /v2/food/types.

The returned type and id must always be interpreted together.
Different food namespaces may contain the same numeric ID.

In particular:

• dish IDs identify regular GeneralClass dishes;
• ingredient IDs identify LogMeal ingredients;
• favorite IDs identify the saved favorite image;
• custom_recipe IDs identify custom-recipe GeneralClasses;
• barcode_food_item IDs identify BarcodeClass GeneralClasses.

Query and types

types is a comma-separated list.

If it is omitted, all supported food types are selected.

Duplicate types are ignored. Unsupported values return a validation error.

A non-empty query is required whenever at least one of these types is selected:

• dish
• ingredient
• barcode_food_item

Therefore, because omitting types selects all types, a request without either types or query is not valid.

favorite and custom_recipe can be requested without query. This allows all available favorites or custom recipes to be browsed directly.

A query may still be provided when searching those types in order to filter their results.

Barcode products can be searched by their stored product name or by their barcode value.

Search text comparison is case-insensitive and ignores surrounding whitespace.

Target APIUser and private resources

APIUsers search using their own context and do not need to provide user_id.

APIUserManagers must provide user_id, and the target APIUser must be accessible by that manager.

The target APIUser determines the private resources included in the results:

• only that APIUser's favorites are searched;
• custom recipes are restricted to that APIUser's APICompany.

Public dish, ingredient and stored barcode sources are searched together with those private resources when their corresponding types are requested.

Language

Names are returned using the requested language where translations are available.

If language is omitted, the standard API language resolution is used.

Ranking and pagination

Results from all requested types compete in one shared ranking.

Text matches are ranked in this order:

1. exact match;
2. prefix match;
3. partial match.

Within the same match tier, favorites and custom recipes receive a small priority boost over the other food types.
A stronger text match always ranks before a weaker one, regardless of food type.

The order in which values are provided in types does not define the response order.

After candidates from all requested sources have been merged and ranked, offset and limit are applied to the combined result set.
Pagination is therefore global, not performed independently for every food type.

total contains the number of matching items across all requested sources before global pagination.

Cooking measures

When cooking_measures=true, returned items additionally contain cooking_measures with their available cooking-measure IDs.

Favorites can contain several food items and therefore do not expose one aggregate cooking measure. Their cooking_measures value is an empty list.

Barcode food items currently use their stored OpenFoodFacts serving/weight and also return an empty cooking_measures list.

If cooking_measures is false or omitted, the field is not included in the returned food items.

Result metadata

All result types contain:

• type
• id
• name
• image_url

image_url can be null when no representative image is available.

Dishes, ingredients, custom recipes and barcode food items may additionally provide default_quantity and unit.

Barcode food items also include their barcode.