How to add photo food logging to a health app.

What happens between the photo and the food log

Every photo logging feature runs the same steps, whichever service you use. Knowing them helps you decide where your app needs its own logic.

1. Capture: the user takes or picks a photo of the meal.
2. Recognition: the service identifies the dish and its likely ingredients.
3. Portion: it estimates how much is on the plate, or uses a size the user chose.
4. Nutrients: it looks up calories and nutrients for each ingredient, then adds them up.
5. Review: the user checks the result and corrects it.
6. Store: your app saves the confirmed entry and updates the day's totals.

The service handles recognition, portion and nutrients. Capture, review and storage are yours, and they shape the experience more than any model does.

Design the capture step

Most bad estimates start with a bad photo. A few prompts in the camera screen fix most of them:

• One plate per photo, with the whole plate in the frame.
• About 30 cm from the food: close enough for detail, far enough to keep the plate in view.
• Even light, without strong shadows across the food.
• A text or voice field next to the camera, so the user can add what the photo cannot show, such as cooking oil, butter, sauce or sugar in a drink.

Offer text and voice as full alternatives, not only as notes. People often eat away from the plate they could have photographed, or remember a snack hours later.

Make the review step part of the flow

A photo cannot show everything. Oil soaked into rice, butter in a sauce or sugar stirred into tea are invisible, and portion size is hard to judge from one angle. Treat every result as an estimate and put the review in front of the user before saving.

• Show the dish name, the ingredients and the portion together on one screen.
• Let the user remove or add an ingredient and change the weight in a tap or two.
• Save only after the user confirms, and record whether they edited anything.
• Avoid showing more precision than the estimate has. Rounding calories to the nearest 5 or 10 reads more honestly than 542.3.

Handle portion sizes

Portion is usually the largest source of error in a calorie estimate. Give users an easy way to override it.

• Offer simple sizes such as small, medium and large for people who will not weigh food.
• Accept a weight in grams when the user knows it, for example from a packet or a kitchen scale.
• For shared dishes, ask for the share the person ate, not the whole tray.

In the BiteRight API, the food log request takes a size of Small, Medium, Large or Custom, with a custom amount when the size is Custom.

curl --fail-with-body --request POST \
  --url "$BASE_URL/api/b2b/v1/food-log" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --form 'date=2026-09-07' \
  --form 'size=Medium' \
  --form 'images[]=@meal.jpg'

Store the estimate and the confirmed entry

Keep the service's estimate unchanged and save the user's confirmed values beside it. You will need both: the confirmed values for the user's totals, and the original estimate to see how often people correct it and where.

// Keep what the API estimated and what the user confirmed side by side.
type NutrientValue = { name: string; amount: string; unit: string };

interface MealEntry {
  loggedAt: string;            // when the user ate, not when you called the API
  source: "photo" | "voice" | "text";
  estimate: {                  // the API response, stored unchanged
    recognized_dish: string;
    total_weight: string;
    calories: NutrientValue;
    ingredients: string[];
  };
  confirmed: {                 // what the user saw and saved
    dish: string;
    grams: number;
    edited: boolean;
  };
}

// Amounts arrive as strings in the examples; parse them once, keep the unit.
const kcal = Number.parseFloat(entry.estimate.calories.amount);

Keep units with every value and record when the meal was eaten, not only when the request was made. Daily totals, weekly summaries and any limits your app checks depend on the meal time.

Handle errors and slow responses

Recognising a meal takes longer than a normal API call, so show progress and keep the photo on screen while the user waits. Plan for these cases:

• No food found, or a blurry photo: ask for another photo or switch to text.
• A dish the service is unsure about: show the result as editable, and make the text option obvious.
• A failed request: keep the photo and the user's notes so they can retry without starting again.

Check both the HTTP status and the body. In the BiteRight API, a 200 response can still contain an error field.

const result = await response.json();
// A 200 response can still carry an error, so check both.
if (!response.ok || result.error) {
  throw new Error(result.error || "Food log request failed");
}

Privacy and health context

Meal photos can show more than food: faces, homes, documents on a table. Meal records can also be health data, especially in a care setting.

• Tell users what is sent for analysis and how long it is kept.
• Collect only what the feature needs, and avoid sending names or identifiers with a photo.
• Check your provider's hosting region, encryption and data processing terms. BiteRight encrypts data in transit and at rest, can host regionally and offers a DPA to business customers.
• Present results as estimates. Do not use them to diagnose, set treatment targets or decide medication doses.
• Do not rely on food recognition to confirm a meal is free of an allergen.

If your app checks daily targets, such as a carbohydrate ceiling, that logic and its notifications live in your app. The BiteRight API returns food and nutrient estimates; it does not run rules or send alerts.

Launch checklist

• Camera prompts for one plate, about 30 cm, even light.
• Text and voice available as full alternatives.
• Review screen with dish, ingredients and portion, editable before saving.
• Portion override with simple sizes and grams.
• Original estimate and confirmed values stored separately, with units and meal time.
• Errors handled for no food, low confidence and failed requests, including errors inside a 200 response.
• Privacy notice, data processing terms and medical disclaimers in place.