One of the most common use cases developers bring to the Chomp API is recipe nutrition calculation — giving users a way to log ingredients, build recipes, and see the full nutritional breakdown of what they're cooking. It sounds straightforward, but there are a few nuances worth understanding before you start building. This guide walks through the recommended approach, the gotchas, and the strategies that work best for real-world recipe apps.

The Challenge: Users Type Ingredients Like Humans

The first thing to understand is that your users will type ingredient names the way a home cook thinks about them: "salt", "butter", "a cup of flour". The Chomp API, like any food database, structures data the way nutritionists and food scientists think about it — which means a search for "salt" might return "Plum, rock salt, dried" before it returns anything useful.

This isn't a bug. It's a consequence of how commercial data is organized, and it's solvable. The strategies below are specifically designed to bridge the gap between how users think and how the data is structured.

The Two Endpoints You'll Use

1. Ingredient Search — /food/ingredient/search.php

This endpoint searches the USDA ingredient database and is the right tool for generic, unbranded foods: raw vegetables, pantry staples, proteins, grains. It returns detailed nutritional data per 100g including macros, micros, vitamins, and minerals.

Example call:

GET /food/ingredient/search.php?api_key=YOUR_KEY&find=table salt

Tips:

• Be specific with search terms. "Table salt" returns better results than "salt". "Unsalted butter" is more reliable than "butter".
• Use comma-separated lists to look up multiple ingredients in one call (up to 10 per request): &find=table salt,unsalted butter,white flour
• Check the score field in the response — higher scores indicate a closer match to your search term. If the top result has a low score, consider it a weak match and fall back to another strategy.

2. Branded Food Name Search — /food/branded/name.php

This endpoint searches the branded food database — products you'd find on grocery store shelves. For common cooking ingredients, searching for a well-known brand often returns cleaner, more complete nutrition data than a generic lookup.

Example call:

GET /food/branded/name.php?api_key=YOUR_KEY&name=Morton Salt

Tips:

• Use this as a fallback when the ingredient endpoint returns poor results.
• For pantry staples, branded searches for products like "Morton Salt", "Land O Lakes Butter", or "King Arthur All-Purpose Flour" return reliable, well-populated nutrition records.

The Recommended Architecture: A Fallback Chain

For apps where users enter free-form ingredient names, build a two-step lookup:

Step 1: Query the ingredient endpoint with a normalized version of the user's input.

Step 2: If the top result's score is below your threshold (experiment to find what works for your data), or if the nutrients array is sparse, fall back to the branded name endpoint with the same search term or a mapped equivalent.

This approach handles the majority of common cooking ingredients reliably without requiring your users to be precise.

User types "salt"
  → Normalize to "table salt"
  → Query ingredient endpoint
  → Score acceptable? Use it.
  → Score too low? Query branded endpoint for "Morton Salt"
  → Return nutrition data

The Ingredient Mapping Table

The single most effective thing you can do to improve result quality for a home cook app is build a small lookup table that maps common user-entered terms to search terms that reliably return good results. This doesn't need to be exhaustive — around 100-150 entries covers the vast majority of home cooking.

Here's a starter set of mappings that work well with the Chomp API:

Apply this table before hitting the API. If the user's input matches a key in your table, substitute the mapped value as the search term.

Handling Units and Serving Sizes

The Chomp API returns nutrient values per 100g. Your app will need to convert these based on the amount the user is using in their recipe.

The ingredient endpoint returns a portions array that includes common measurement units and their gram equivalents. For example, "1 cup" of flour might be listed as 125g. Use these to convert user-entered quantities to grams before calculating nutrition.

Basic calculation:

nutrient_amount = (per_100g_value / 100) * ingredient_weight_in_grams

For a recipe serving multiple people, divide the total by the number of servings.

Handling the user_id Parameter

Premium subscribers must include a user_id parameter with every API call. This is used for Monthly Active User billing — it tells Chomp how many unique users your platform has accessed the API each month.

For recipe apps, your user_id should be the identifier of the user performing the lookup — not a fixed string. If you pass the same string for all users, your MAU count will appear as 1 regardless of actual usage, which misrepresents your usage and could cause billing issues.

Pass a hashed version of your internal user ID for privacy:

&user_id=hashed_user_id_here

If your app does lookups server-side without a logged-in user (for example, pre-calculating nutrition for a published recipe), pass a consistent identifier for that operation like &user_id=system-recipe-calc.

A Complete Example: Calculating Nutrition for Pasta Carbonara

Let's walk through a full example. The recipe has: pasta, eggs, bacon, parmesan cheese, black pepper, salt.

Step 1: Normalize and map ingredients

Step 2: Batch lookup

Split into groups of up to 10 and call the ingredient endpoint:

GET /food/ingredient/search.php?api_key=KEY&find=large egg,bacon cooked,parmesan cheese,black pepper,table salt&user_id=USER_ID

Step 3: Evaluate scores

Check each result's score. If any ingredient returns a low score or sparse nutrients, run a fallback branded search for that ingredient.

Step 4: Apply gram weights

Convert user quantities to grams using the portions data, then calculate per-nutrient totals across all ingredients.

Step 5: Divide by servings

Divide totals by the number of servings the recipe makes to get per-serving nutrition facts.

Common Pitfalls

Searching with units included. Don't pass "2 cups of flour" to the API — strip units and quantities before searching. Only pass the ingredient name.

Ignoring the score field. A result with a score of 10 is a weak match. A score of 70+ is reliable. Build your logic around this signal.

Not handling empty nutrients arrays. Some products in the database have incomplete nutrient data. Always check that the nutrients array is populated before calculating. If it's empty, try a different search term or flag the ingredient for manual review.

Passing the same user_id for all users. See the user_id section above.

Searching for compound ingredients. "Tomato sauce" or "chicken broth" will return inconsistent results because these are prepared foods with many variations. Either map them to a specific branded product or break them down into components where possible.

Summary

Building a reliable recipe nutrition app with the Chomp API comes down to three things: normalizing user input before it hits the API, using the ingredient and branded endpoints together with a fallback strategy, and building a small ingredient mapping table for common staples. None of this is complex to implement, and the result is a much more reliable experience for your users.

If you have questions about specific ingredients or use cases, the Chomp Support team is available to help identify the best search terms for your application. Contact Support →