How to Integrate the Nutritionix API (2026)

The Nutritionix API gives you nutrition data for foods — calories and macros for natural-language meals, autocomplete search across common and branded foods, and lookup by item ID or UPC barcode. Its auth model is about as simple as REST APIs get: no OAuth, no token exchange, no callback URLs. You create an application, get an App ID and App Key pair, and send both as static headers on every request.

That simplicity is the reason a lot of nutrition apps reach for it first. If you have integrated an OAuth wearable API before, this will feel trivial by comparison — there is no refresh flow to manage and nothing expires mid-session. This guide walks the account setup, the two required headers, and the four endpoints you will actually use, with a real request for each. For where Nutritionix fits against alternatives, see the best nutrition APIs roundup; for the wider product build, see how to build a nutrition tracking app.

What you'll need

• A Nutritionix developer account (sign up at developer.nutritionix.com).
• An application created in that account — the App ID and App Key are issued per application, not per account.
• The two credential values, ready to inject as headers:
  • x-app-id — your application's App ID.
  • x-app-key — your application's App Key.
• An HTTP client. Everything below is plain REST, so curl, fetch, or any language's HTTP library works.

The base URL for all v2 calls is https://trackapi.nutritionix.com/v2/.

Heads up on an older host. The archived GitHub doc nutritionix/api-documentation still shows a legacy beta host (apibeta.nutritionix.com) with Content-Type: text/plain and header casing like X-APP-ID. The current production host is trackapi.nutritionix.com/v2/, requests use a JSON body, and header names are case-insensitive. If you copy a snippet off an old blog post and it fails, check the host first. Verify the current host and casing against the live docs before you ship.

Step 1: Create an application and get your key pair

Sign up at developer.nutritionix.com, then create an application inside your account dashboard. Nutritionix issues an App ID and App Key tied to that application. Treat the App Key like a secret — keep it on your server, not in a shipped mobile or web client, so it cannot be scraped and used against your quota.

Store the pair as environment variables:

export NUTRITIONIX_APP_ID="YOUR_APP_ID"
export NUTRITIONIX_APP_KEY="YOUR_APP_KEY"

Step 2: Get nutrients from free-text food (the primary endpoint)

The endpoint most apps are here for is POST /natural/nutrients. You send a plain-English description of a meal and get back itemized nutrition for each food. This is what powers "type what you ate" logging.

Send the two auth headers plus a JSON body with a query string:

curl -X POST 'https://trackapi.nutritionix.com/v2/natural/nutrients' \
  -H "x-app-id: $NUTRITIONIX_APP_ID" \
  -H "x-app-key: $NUTRITIONIX_APP_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "for breakfast i ate 2 eggs, bacon, and french toast"
  }'

The response is JSON with a foods array. Each entry typically includes food_name, serving_qty, serving_unit, serving_weight_grams, nf_calories, nf_total_fat, nf_protein, and nf_total_carbohydrate, plus a full_nutrients array mapping nutrient IDs to values. Optional documented body params include timezone, aggregate, and use_raw_foods. Confirm the exact field list and parameters against the current docs, since response shapes evolve.

In JavaScript the same call looks like this:

const res = await fetch("https://trackapi.nutritionix.com/v2/natural/nutrients", {
  method: "POST",
  headers: {
    "x-app-id": process.env.NUTRITIONIX_APP_ID,
    "x-app-key": process.env.NUTRITIONIX_APP_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ query: "1 cup cooked quinoa and 4 oz grilled chicken" }),
});
const data = await res.json();
for (const food of data.foods) {
  console.log(food.food_name, food.nf_calories, "kcal", food.nf_protein, "g protein");
}

Step 3: Add autocomplete with instant search

For a search-as-you-type UI, use GET /search/instant. It takes a query parameter and returns two arrays: common (generic foods) and branded (packaged products). Branded results carry a nix_item_id you can use for a precise follow-up lookup.

curl -G 'https://trackapi.nutritionix.com/v2/search/instant' \
  -H "x-app-id: $NUTRITIONIX_APP_ID" \
  -H "x-app-key: $NUTRITIONIX_APP_KEY" \
  --data-urlencode 'query=hamburger'

Typical flow: show the user instant-search suggestions, and when they pick a common food, resolve it through POST /natural/nutrients; when they pick a branded food, resolve it through the item lookup in the next step.

Step 4: Look up a specific item by ID or barcode

GET /search/item fetches one branded item. Pass nix_item_id for an item you already identified (for example, from instant search), or pass upc to resolve a scanned barcode — the path your barcode scanner should hit.

By item ID:

curl -G 'https://trackapi.nutritionix.com/v2/search/item' \
  -H "x-app-id: $NUTRITIONIX_APP_ID" \
  -H "x-app-key: $NUTRITIONIX_APP_KEY" \
  --data-urlencode 'nix_item_id=YOUR_NIX_ITEM_ID'

By UPC / barcode:

curl -G 'https://trackapi.nutritionix.com/v2/search/item' \
  -H "x-app-id: $NUTRITIONIX_APP_ID" \
  -H "x-app-key: $NUTRITIONIX_APP_KEY" \
  --data-urlencode 'upc=49000000450'

Between these four endpoints you have the full logging loop: free-text entry, autocomplete, ID lookup, and barcode resolution.

Endpoint reference

All paths are relative to https://trackapi.nutritionix.com/v2/, and every call carries the x-app-id and x-app-key headers.

Gotchas and production notes

• Keep the App Key server-side. Because auth is just two static header values with no per-user token, anyone who extracts the pair from a client bundle can spend your quota. Proxy Nutritionix calls through your backend rather than calling it directly from a mobile or browser client.
• Free-tier limits are ambiguous — verify them. Nutritionix has offered a free developer tier that was historically rate-limited (the docs have listed caps such as a per-day limit on the natural endpoints). The exact current tier name, request quotas, and per-endpoint limits change; confirm them against the current docs and your account dashboard before you build volume assumptions on them.
• Handle rate-limit and error responses. Check for non-200 status codes and back off on 429s rather than retrying in a tight loop.
• Field shapes can change. The nutrient field list and optional body params above reflect documented behavior at the time of writing; treat them as a starting point and validate against a live response.
• Pair it with an exercise source if you need both sides of the ledger. Nutrition in, activity out — if you also need workout data, see how to integrate ExerciseDB.

Nutritionix is one of the lowest-friction integrations in the fitness and nutrition space: create an app, grab two keys, send two headers. The engineering effort goes almost entirely into the logging UX on top, not into the auth plumbing.