The Edamam B2B API is accessed by sending HTTPS requests on specific URLs as described below. The base URL is https://api.edamam.com, and you obtain the full URL by appending request’s path to the base URL, for example, https://api.edamam.com/api/nutrition-details.

This API covers all key use cases related to recipe and food text natural language processing and nutrition analysis. The API employs NLP (Natural Language Processing) which allows for extraction of food entities from unstructured text.

Covered Use Cases

• Full analysis of food recipes in real time – entity extraction, measure and quantity extraction with computation of the applicable nutrition for the recipe, applicable health and diet labels, and recipe classification for cuisine, meal, and dishtypes. Finally, it adjusts quantity for certain ingredients to account for the cooking process. For example, it calculates oil absorption for fried recipes, excludes solids from stock and broth recipes, calculates marinate absorption for marinates and much more.
• Extraction of food entities with measures and quantities from unstructured text.
• Usage in chatbots transcribing natural speech to text.

The above OpenAPI specification for our API can be found here.
More information on OpenAPI can be found at: https://swagger.io/.

Food Logging

As stated in the specification, the food logging feature can be enabled by changing the “nutrition-type” parameter in the Nutrition Data GET request to “logging.” If you use the food logging context feature it will modify the NLP response in the following ways:
- You can submit items without quantity. We will try to match them and assign quantity to them based on expected serving size
- Only foods ready for direct consumption will be matched – no raw meats, raw dry goods or vegetables which need cooking for example
- Edamam can handle single items and two part compound items only – i.e. “chicken” or “rice AND chicken”. Make sure the URL is encoded properly

Nutrient Guide

The list of all of the nutrients that may be contained as part of a recipe’s nutritional information under the totalNutrients and the totalDaily section of the response. totalNutrients is the absolute nutrient amount, while totalDaily is the percent of daily recommended nutrient intake.

Nutrient Structure

The structure of the Nutrients based on what is under the totalNutrients and totalDaily sections of the response.

Response Guide

Ingredient Structure

The structure of the Ingredients based on what is under the ingredients section of the response.

Please note that some plans may not include all of the fields for the ingredient object.

Diet Labels

The list of all possible Diet Labels generated from the nutrient information on the recipes. These labels describe commonly used nutrient level aspects of the recipe.

Health Labels

The list of all possible Health Labels generated from the ingredient information on the recipes. These labels describe commonly used ingredient level aspects of the recipe.

Recipe Classification (beta)

As part of the Nutrition Analysis of recipes, the responses include the inferred cuisines (Italian, French, etc.), meals (Breakfast, Dinner, Snack, etc.), and dish type (Breads, Desserts, Omelet, Soup, etc.) of the recipes you submit to the Nutrition Analysis API. The full lists of cuisine, meal, and dish types are listed below.

As this is a beta feature, in order for the reponse to include the inferred recipe classification types, the “beta” parameter must be set to “true” in the request to the API. This “beta” parameter can be used in the OpenAPI documentation at the top of this page.

This feature is currently only enabled on Developer Plans. If you are on an Enterprise Core or Enterprise Unlimited Plan, contact us if interested.

Meal Types

List of all possible Meal Types. The meal types refer to the meals in a day the recipe is commonly consumed in.

Dish Types

List of all possible Dish Types. The dish types refer to the category of food the recipe would fall under.

Cuisine Types

The list of all possible Cuisine Types. The cuisine types refer to the cuisine that the recipe would fall under.

New recipes, resubmission and licensing count

Once you submit a recipe via the API you start paying Edamam a monthly licensing fee for each new analyzed recipe. Sometimes however, you may need to refresh the nutrition data for an already submitted recipe, in case you have lost the nutrition data for example. Submitting a recipe directly will count as analyzing a new recipe, and you will be charged again licensing fee for the nutrition information. To avoid that we’ve implemented a system based on HTTP’s ETag mechanism.

First, each successfully processed recipe will also return a tag in the ETag response header. This value must be preserved together with the recipe. Then, when resubmitting the recipe, you should include the value in the If-None-Match request header.

There three possible outcomes:

1. You are already using the most up to date version of the Edamam data. That is, you already have the newest version of the nutritional info. In this case, the system will return HTTP status code 304 – Not Modified. Note, that you can force the reevaluation in this case (for example if you lost your data) by passing the force parameter. Edamam will know that you are already paying license for the nutrition information for this recipe, and you will not be charged twice.
2. We have updated our database, the recipe is processed again. In this case you’ll receive the possibly updated nutrition data as well as the updated ETag header. You should store that new value and use it for further resubmissions.
3. The recipe you submitted has been changed by you. As the ETag hash contains a “signature” for the recipe content the system will respond with HTTP status code 409 – Conflict. In case you have used the wrong ETag you can use correct the code, or if the recipe has changed you can resubmit the recipe as a new one (that is, without sending the If-None-Match header).

Licensing count example. You have analyzed 100 recipes in the first month, 50 the second month and 1 the third month. The first month you will pay a licensing fee for the nutrition of 100 recipes, the second month for 150 and the third for 151. If you don’t analyze any more recipes after the third month you will pay licensing fee for the nutrition for the total of 151 recipes every month thereafter.

Unique food text/ingredient line, resubmission and licensing count

Once you submit an ingredient line via the API you start paying Edamam a monthly licensing fee for each new analyzed ingredient line. Sometimes however, you may need to refresh the nutrition data for an already submitted ingredient line, in case you have lost the nutrition data for example. Submitting an ingredient line directly will count as analyzing a new ingredient line, and you will be charged again licensing fee for the nutrition information. To avoid that we’ve implemented a system based on HTTP’s ETag mechanism.

First, each successfully processed ingredient line will also return a tag in the ETag response header. This value must be preserved together with the ingredient line. Then, when resubmitting the ingredient line, you should include the value in the If-None-Match request header.