Recipe and Dish Recommendation

Learn more about the user data that can influence recommendations in Nutritional Plans, Daily Nutritional Goal, Remaining Daily Intake, and Food Restrictions and Preferences.

Plan & Token Requirements

Feature available in the following LogMeal Plans:

Accessible by the following User Types:

What It Does

LogMeal exposes two related recommendation levels:

• Dish recommendation returns LogMeal dish IDs that fit the APIUser's current context.
• Recipe recommendation returns cooking recipes associated with suitable dishes and applies an additional recipe-level filter using the APIUser's diet and health labels.

Dish recommendation keeps the existing food-group and Variety Score logic as the first candidate-generation stage. The resulting candidates are then personalized using the information currently available for the APIUser, including:

• configured hard food restrictions, which can exclude a dish when a conflict can be determined with high confidence;
• soft diet and health-label preferences;
• consumed intake versus the user's remaining daily nutritional targets;
• the active nutritional plan, when available;
• recently consumed dishes, to reduce repeated recommendations.

When no custom nutritional goal exists for a tracked nutrient, the user's calculated recommended daily intake can be used as the target. When a particular personalization signal cannot be resolved, the other available signals still participate and the food-group/Variety Score stage remains the baseline.

When to Use It / Outcomes

• Recommend dishes that complement what an APIUser has already consumed.
• Prioritize dishes that better fit remaining daily nutritional needs and an active nutritional plan.
• Respect configured restrictions and preferences before presenting meal suggestions.
• Generate cooking recipes from automatically recommended dishes or from dish IDs selected by your own application.
• Build meal-planning or nutrition-coaching experiences without changing the existing dish-recommendation response contract.

Feature-Specific Details

Dish Recommendations

Call GET /recommend/dish.

The request can optionally narrow the candidate-generation context using:

• date_from — start of the intake-history lookback period. If omitted, the API uses the previous 7 days.
• occasion — meal occasion used to select suitable food groups.
• food_groups — an explicit bracketed list of food-group IDs, such as [6, 4].
• score_type — the Variety Score candidate-generation score. The current accepted value and default is nutri_score.

The response contains up to 8 GeneralClass IDs in recommended_dishes. Use GET /dataset/dishes when you need the corresponding dish information.

Recipe Recommendations

Call GET /recommend/recipe.

There are two ways to select the dishes for which recipes are returned:

1. Omit food_class_ids. The API first runs the same personalized dish-selection logic used by GET /recommend/dish.
2. Provide food_class_ids. The automatic dish-selection stage is bypassed and recipes are retrieved for the supplied dish IDs.

After recipes are collected, recipe-level filtering uses the APIUser's configured diet and health/restriction labels. Keep these values updated through POST /profile/modifyUserProfileInfo.

num_of_recipes defaults to 5. Values greater than 10 are capped at 10.

Related Endpoints

• GET /recommend/dish → 🔴 Get personalized dish recommendations.
• GET /recommend/recipe → 🔴 Get personalized recipe recommendations from automatic or explicitly supplied dish IDs.
• POST /profile/modifyUserProfileInfo → 🔴 Keep diet preferences, restrictions, and profile information up to date.
• GET /daily_nutritional_goal → 🔴 Retrieve custom daily nutritional goals, when configured.
• GET /nutrition/getRecommendedDailyIntake → 🔴 Retrieve calculated recommended daily intake values used when custom targets are not available.
• GET /nutritional_plan/{user_id} → 🔴 Retrieve the APIUser's nutritional plan when the feature is in use.

Remember to check applicable request limitations inside each endpoint.

Typical Workflow

1. Maintain the APIUser context: keep restrictions/preferences and, when applicable, daily nutritional goals and nutritional plan information up to date.
2. Record intakes: recommendations use recent intake history to estimate what the user has consumed and to reduce repetition.
3. Request dish candidates: call GET /recommend/dish, optionally specifying occasion, date_from, or food_groups.
4. Resolve dish information: retrieve names and other dish metadata from GET /dataset/dishes.
5. Optionally request recipes: call GET /recommend/recipe without food_class_ids to reuse automatic dish selection, or provide explicit dish IDs when your application has already selected them.