Meal Plan Management
Calling any one of the Meal Planner API endpoints will first check whether the user has a meal plan assigned to them. If they do not, the meal plan will be automatically created for them. This means that the developer is not required to actively create a meal plan for the user.
Our API spec clearly shows that each endpoint has two versions - one with meal_plan_id and one without.
meal_plan_id section is optional - the endpoint will return the same result whether it is provided or not.
This is because Whisk supports a single meal plan for each user at this time. Multiple meal plans will be supported in future versions. Therefore, the
meal_plan_id will be directly derived from the user’s ID. The user ID is extracted using the OAuth token provided with each endpoint header, as described above.
This endpoint gets a list of meals for a specified time period. For more information, follow this link:https://api.whisk.com/spec/#/MealPlanAPI/GetMealSchedule2.
on_conflict field allows meals to either replace or be inserted into daily meal slots when using the Add Meal or Update Meal endpoints. This helps the meal planner avoid any conflicting actions in case of adding or updating a meal into a daily slot which already is populated with a pre-existing meal.
Here are the following options for the
DAY_SLOT_CONFLICT_ACTION_REPLACE- the new meal will replace the existing one. This is the default option.
DAY_SLOT_CONFLICT_ACTION_INSERT- the new meal will be inserted before the existing one, pushing it, along with all following meals, forward one daily slot. However, if you exceed the maximum number of daily meals (7), a 400 error response will be returned.
DAY_SLOT_CONFLICT_ACTION_FAIL- the new meal will not be inserted into the daily slot, and a 400 error will be returned.
To get the recipes for the meal plan just use the recipe search endpoint:
More info here: https://api.whisk.com/spec/#/RecipeAPI/SearchRecipes