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 four primary paths to register a new intake:

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.
Image‑based with Quantity Estimation — Capture a short sequence (RGB or RGB+Depth) to estimate serving sizes automatically.
Barcode‑based intake (packaged foods) — Scan an EAN/UPC and create an intake from the mapped product/dish.
Manual intake (no image) — Provide dish IDs (and optionally ingredients, serving sizes, levels, timestamp).
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. They are selected within Manual Intakes or any other dish confirmation method — they are not an additional submission method.

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 or log on behalf of users.

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.

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

Scenario	Recommended Path	Pros	Considerations
Photo of a meal	Image‑based recognition	Fast, auto‑labels dishes	Requires user confirmation for best accuracy
Need precise food quantity estimation	Quantity Estimation	Auto‑labels dishes & auto‑estimates grams/ml	Requires sequence capture via LogMeal Depth SDK
Packaged product	Barcode intake	Fast, no photo	Product coverage may vary regionally
No photo / historical entry	Manual intake	Full control; bulk options	Requires dish IDs
Repeating a known meal	Favorites intake	One‑tap logging	Must first create favorites from confirmed meals

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 manual intakes, ensure you pass dish IDs.
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.