Ways to Submit New Intakes

This guide summarizes all supported ways to create (submit) a new intake in LogMeal, with when to use each method, required tokens, key endpoints, and typical workflows.

Overview

There are five primary paths to register a new intake:

1. Image‑based recognition — Upload a meal photo, auto‑detect dishes, then confirm. You can take a photo with your camera or upload one from your photo gallery.
2. Image‑based with Quantity Estimation — Capture a short sequence (RGB or RGB+Depth) to estimate serving sizes automatically.
3. Barcode‑based intake (packaged foods) — Scan an EAN/UPC and create an intake from the mapped product/dish.
4. Manual intake (no image) — Provide existing dish IDs and/or, optionally, create food items from scratch using ingredient IDs and quantities. You may also provide serving sizes, levels, timestamp, and an optional intake name.
5. Favorites reuse — Re-submit previously saved dishes/ingredients/quantities to a new intake in one step.

Always validate your current LogMeal Plan before integrating a flow.

Note on Custom Recipes: Custom Recipes are curated, reusable dishes your organization manages and selects by ID. By contrast, when ingredient-only manual intakes are enabled for your account, you may also create a one-off food item directly from ingredient IDs without first creating a reusable Custom Recipe.

---

Method 1 — Image‑Based Recognition (Several Dishes Insertion)

When: You have a photo of the meal and want automatic dish segmentation and/or food types/groups recognition.

Plan: Analyse and above (see more info about LogMeal Plans)

More details about Image-Based Recognition feature.

Best for: Visual diaries, multi‑dish meals, mixed plates, restaurant photos.

Related use case: Image Recognition with Confirmation

---

Method 2 — Image‑Based with Quantity Detection

When: You need automatic serving size estimates without manual input.

Plan: Recommend and above (see more info about LogMeal Plans)

More details about Image-Based Quantity Estimation feature.

Best for: Accurate nutrition without weighing; research or wellness apps needing lower user friction.

Related use case: Food Quantity Detection

---

Method 3 — Barcode‑Based Intake (Packaged Foods)

When: The user is logging packaged products and prefers scanning over photos.

Plan: Monitor and above (see more info about LogMeal Plans)

More details about Barcode scanner feature.

Best for: Pantry items, snacks, packaged meals.

---

Method 4 — Manual Intakes (No Image)

When: The user didn’t take a photo; you need to record meals historically, log on behalf of users, or define a one-off food item directly from ingredients.

Plan: Monitor and above (see more info about LogMeal Plans)

More details about Manual intakes feature.

Best for: Clinical logging, dietitian tools, missed‑photo scenarios, backfilling histories, and custom ingredient-based entries.

Related use case: Create a Custom Dish from Scratch with a Manual Intake

---

Method 5 — Favorites (One‑Tap Reuse)

When: Users frequently repeat the same meals and want faster logging.

Plan: Monitor and above (see more info about LogMeal Plans)

More details about Favorite intakes feature.

Best for: Habitual breakfasts, go‑to lunches; increasing diary adherence.

---

Choosing the Right Method

---

Post‑Submission: Refinements & Analysis

After creating the intake (by any method), you can:

• Confirm or edit ingredients per dish.
• Confirm per‑item quantities.
• Retrieve ingredients and quantities (totals & per‑item).
• Retrieve nutrition (totals & per‑item) for reporting and goals.

---

Common Pitfalls

• Use the correct token type for each flow; some endpoints are restricted to 🔴 APIUser only.
• For each manual food item, provide either a valid dish id and/or, optionally/alternatively , a non-empty ingredients list with valid ingredientId values.
• Always store the returned imageId: it’s the handle for later confirmations, favorites, edits, and deletion.

---

Deleting an Intake (Any Method)

Use this when an intake was created by mistake, duplicated, or needs to be removed for privacy/compliance.

Endpoint: DELETE /v2/intake/{imageId}
Who can call: ⚫ APICompany, 🔵 APIUserManager, 🔴 APIUser (may be limited to own intakes)

Behavior

• Removes the intake and its derived artifacts (ingredients, nutrition results, confirmations).
• History and summaries will reflect the deletion on the next retrieval.
• Treat as idempotent from the client perspective: a second delete may return 404 Not Found if already deleted.

Request

• Path parameter: imageId — the identifier returned when the intake was created (for any method).

Tip: Keep a local tombstone (deleted flag) to avoid re-fetching a removed intake.