Vitalli

Record a food rule for the user ('Bananen soll ich laut Bericht meiden'), e.g. when transferring a list from a report or from a doctor. Stores the user's statement; Joiva adds no foods and establishes no tolerances on its own. An existing rule for the same food is replaced (one rule per food).

Add something the user put away at home. Nutrient values are not accepted here: Joiva resolves them from its own reference sources and refines them in the background. The record is as precise as its identity: name, brand, barcode. Nutrients written into note are not evaluated. A printed nutrition table counts as evidence only when photographed in the Joiva app (Vorrat → Einkauf fotografieren), not as typed numbers. Quantity may be grams, millilitres or pieces; unitWeightG is the known weight per piece, not an estimate.

Put a food item on the user's Joiva shopping list ('setz Hafermilch auf den Zettel'). An identical open entry is returned instead of creating a duplicate. Staples are not kept on the list. The list holds food only: supplements and health products, including the borderline cases protein powder, collagen, MCT oil and electrolyte powder, are kept on Stackwell's list with the supplement plan.

Answer one open recipe question with the option index the user chose, or ignore=true when the user does not want to answer (the standard then stays, visibly). The answer becomes the user's personal recipe for that dish, the user's entries of the dish are recomputed, and Joiva does not ask about that dish again.

Confirm a planned Joiva meal (by its entryId) as actually eaten. It is logged with the time of confirmation (not the planned time) and now counts towards the day's totals. grams corrects the portion.

Deduct a quantity from a pantry item (after cooking, or when something was thrown away). Joiva never deducts on its own: logging a meal does not silently change the stock, because a portion eaten is rarely the whole package.

Delete a Joiva log entry.

Get the signed-in user's Joiva food log for one day. Defaults to today. The default answer is compact: each entry carries id, foodItemId, food, brand, grams, meal, loggedAt, kcal and macros (fields without a value are left out; naehrwertStatus appears only when the nutrient values are not complete yet). The day totals are complete, including micronutrients; coverage gives target, percent and status per nutrient; meals groups the entry ids per meal; plannedEntries are listed the same way, and plannedTotals, forecastTotals (= totals + planned) and forecastCoverage appear when something is planned. detail: 'full' returns the full breakdown per entry: micronutrients, microsOrigin (per nutrient: eigen = from the label/product source, uebernommen = inherited from the generic food, scaled where it depends on fat/carbs/protein, zubereitung = adjusted for the preparation, geschaetzt = estimated), garung, behandlung, notiz as eaten, produktGarung as bought, recipe and portions. entryIds returns only those entries with their full breakdown. Every food carries brand and certifications (bio, demeter, bioland, naturland, fairtrade; left out = none known), which tell products of different makers apart.

The signed-in user's macro philosophy and targets (protein floor, carb cap) plus available presets. The resolved per-day gram targets (incl. fat as the rest of the calorie budget) are not part of this answer; the day view carries them as macros.

Meal-planning briefing for the signed-in user in one call: allergies and intolerances, active conditions and medications, the 14-day Bristol stool-form trend with pre-written food suggestions, latest biomarkers with their dates, active symptoms (Vora); the current fasting window (Still); the supplements logged today (Stackwell); the day's macros and micronutrient intake gaps, the pantry incl. staples, the shopping list and frequently logged foods (Joiva); body data and energy need (Vitalli). Each source is read only if the user enabled that app for AI access. Every source carries available and fetchedAt, and an error when it is unavailable (not enabled, or not reachable); an unavailable source means unknown, not empty. The guidance field holds fixed notes on reading the data (allergies and a running fast as constraints, intake gaps versus measured values). Personal food rules are not included.

Joiva's rule-based comparison of the logged dietary intake of all nutrients with reference values over 1, 7 and 30 days, one rule set: minimum (70 % of the DGE reference), upper limits (EFSA/NIH), 'at most' limits (saturated fat, added sugar, sodium, omega-6 as % of energy) and ratios (omega-6:omega-3, sodium:potassium molar, calcium:magnesium, zinc:copper). Each finding: limit with source link, per window the value, data coverage and status (auffaellig | ok | zu_wenig_daten | keine_eintraege), the top contributing foods, the origin of the values (label, database, inherited, estimated), a suggestion and a 30-day history. 'zu_wenig_daten' means NO statement, neither a warning nor an all-clear. 'nicht_angewendet' = the rule does not apply to the user's diet (reason given). At most one finding has alarm=true. onlyFired=true returns only rules with status 'auffaellig'. The findings describe logged intake, not nutrient levels in the body.

Per-day macro totals and entry counts for a date range (max 92 days) from the signed-in user's Joiva log.

The signed-in user's personal food rules: what they want to avoid, be careful with, or consider explicitly fine, each with reason and their own note. These are the user's own notes, not a medical finding.

The signed-in user's most frequently logged foods with per-100g nutrients, per-nutrient provenance (microsOrigin) and product traits (garung/behandlung as bought, sorte, herkunft, weidehaltung). Logging with these names/subTypes reuses the existing items. Every food carries brand and certifications (bio, demeter, bioland, naturland, fairtrade; null = none known), which tell products of different makers apart.

The signed-in user's saved meals (reusable recipes): name, components with grams, per-portion macros, times logged.

Open follow-up questions about assumptions in the user's dishes. A named dish without an ingredient list (e.g. 'Bullet Proof Coffee', 'warmer Linsensalat') is computed in Joiva from a standard recipe; where a common variant changes the nutrients noticeably (oil in the dressing, milk or almond drink), Joiva asks once. Sorted: first what a warning of the nutrient assessment depends on, then what its data coverage depends on, then the size of the effect. Each question has optionen, the preselected standard index (the entry is already computed with it, nothing is blocked) and wirkungText (what the answer changes). Each question has an id.

What the signed-in user currently has at home, per storage location, with quantity and (where the food is resolved) its nutrients. expiringWithinDays filters for items close to or past their best-before date. Every food carries brand and certifications (bio, demeter, bioland, naturland, fairtrade; null = none known), which tell products of different makers apart.

List the signed-in user's planned (not yet eaten) Joiva meals with scheduled time, grams, macros, per-nutrient provenance (microsOrigin) and preparation (garung, behandlung, notiz). Without date it returns all open plans from the last 30 days onwards; plans never expire on their own. Each plan carries its entryId.

The signed-in user's active Joiva share links (neither expired nor revoked) with kind, day, expiry and view count. The URLs themselves are not included; only a hash of them is stored. Each link carries its id.

The signed-in user's food shopping list: open entries in list order plus recently bought ones. sentToBringAt shows whether an entry already went to the user's Bring! app. Supplements are not part of this list; they are kept in Stackwell.

Log a meal the signed-in user described in their own words, e.g. 'ca. 350 g Hähnchen-Kokos-Curry (Hähnchen, Kokosmilch, Möhre; ohne Zwiebeln) und 250 g Brokkoli mit Olivenöl'. Joiva splits the text into its parts and breaks every dish, and every food with additions (oil, butter, sauce, spices), into ingredients with its own recipe decomposition: named ingredients are kept, excluded ones left out, cooking fat counted, missing amounts estimated, nutrient values from Joiva's reference sources (BLS first). It writes one log entry per ingredient, all in one meal; a plain single food becomes one entry. Nothing is written unless every part resolves. Takes 20 to 60 seconds. Time: loggedAt, or date with meal (placed at the meal's usual hour) or with time; without any of these it is now. A past day without meal and time is refused, since Joiva does not invent a clock time. The reply lists every entry (entryId, food, grams, kcal) per part, the assumptions made for what the description left open, and the meal's totals.

Log a drink the signed-in user had from Joiva's drink templates: coffee, tea, milk, cocoa, orange juice, apple spritzer, cola, cola zero, beer or white wine; coffee and tea optionally with milk, oat drink, coffee cream, sugar or butter. Writes food-log entries (the drink plus one row per addition, linked as one drink) with caffeine and alcohol from a cited source, energy and nutrients. Drinks are listed in ml under 'Getrunken', never as a meal. Drinks and additions over 50 kcal end a fast like any food (fasting automation, 50 kcal rule). Its water counts towards the day's hydration target. Plain and sparkling water are not logged here; a drink without a template here is logged like food. Time defaults to now.

Log ONE food the signed-in user ate in Joiva, as one entry. Takes the food name in the user's own language; Joiva resolves the nutrient values itself against its reference sources and reports their provenance in the nutrients field of the response. Reuses an existing food by barcode or (food, subType, brand), otherwise creates it. brand and barcode decide which product is meant. Several foods of one meal are several entries with the same meal. A dish or a food with additions (oil, butter, sauce) in one entry, or ingredients and nutrient values in notiz, are refused with an explanation, and nothing is written. Time defaults to now.

Log a saved Joiva meal in one call: every component becomes a log entry sharing one meal, labeled with the meal's name. The meal is found by mealName (case-insensitive, e.g. 'Power-Bowl') or by savedMealId. factor scales the portion (0.5 = half, 2 = double). Time defaults to now. With plannedDate the meal is scheduled for a day that has not happened yet ('plane meine Power-Bowl für morgen'): the entries are written as planned, not eaten, and stay out of that day's balance until confirmed.

Log plain water, sparkling water or salt water the signed-in user drank, in millilitres. Water lives in its own ledger: no macros, never breaks a fast. Drinks with content (coffee, tea, milk, cocoa, juice, spritzer, cola, beer, wine, broth) are not water: they belong in the food log with caffeine, alcohol and energy, and their water still counts towards the hydration target. For backwards compatibility kind: 'coffee' is logged as a plain coffee in the food log. The daily hydration target and its breakdown are part of the day view under water. kind: 'salt_water' records the salted water of an extended fast with its sodium, which the fasting safety rule depends on. Time defaults to now.

Plan a meal the signed-in user intends to eat later ('plan my dinner at 19:00', 'breakfast tomorrow'). Creates a planned entry in Joiva. It does not count towards the day's totals until it is confirmed as eaten. Food matching and nutrient resolution work as for a logged food: the food name in the user's own language, brand/barcode identify branded products.

Remove a food rule by its ruleId. The food is then unremarkable again.

Remove a pantry item entirely (wrong entry, or gone).

Delete an entry from the Joiva shopping list, for an entry that does not belong there. Something actually bought is ticked off (status 'done') rather than deleted.

Report that a food in Joiva's shared catalog is wrong: wrong nutrient values, wrong name, a duplicate, or not a real product. For values the user says are off (e.g. 'fat can't be right, it was porridge with water') or that are clearly implausible. Same path as the report button in the Joiva app: stored with a snapshot, checked at once against Joiva's reference sources (BLS, Open Food Facts), corrected only when a source backs it, escalated to a human moderator from the second report. It never deletes a food and never writes submitted numbers: suggestedPer100g and evidence are recorded and compared with the source. The food is identified by its catalog id (foodItemId). The user's own log entry is not changed by a report.

Revoke a Joiva share link by its id. From then on every visit sees the same page as an unknown link. Immediate and final: a new link is a new URL.

Save foods as a named, reusable meal (recipe) in Joiva ('merk dir das als Power-Bowl'). Input: entryIds of logged entries; duplicates of one food are summed. Alternatively it takes components as (foodItemId, grams) pairs. The saved meal can then be logged again as a whole.

Saves a recipe as a reusable dish ('Gericht') in Joiva from ingredient names with grams, without logging anything ('Grüner Smoothie: 120 g Banane, 40 g Babyspinat, 200 ml Haferdrink'). Joiva binds every ingredient to its catalog like a recipe photo (German food database first, then USDA, never estimated). If no source knows an ingredient, nothing is saved and the reply names the unknown ingredient; a more precise name or a catalog foodItemId resolves it. A dish with the same name gets its ingredients replaced (same id; an existing recipe link shows the new version). The reply lists the catalog row each ingredient was bound to.

Search the signed-in user's own and the shared Joiva food catalog by name. Hits carry per-100g nutrients, per-nutrient provenance (microsOrigin) and product traits (garung/behandlung as bought, sorte, herkunft, weidehaltung). Every food carries brand and certifications (bio, demeter, bioland, naturland, fairtrade; null = none known), which tell products of different makers apart.

Send the open Joiva shopping entries to the user's connected Bring! app. Requires the user to have linked a Bring account and picked a list in Joiva; otherwise the call returns an error saying to set that up in the app. Success is verified by reading back the Bring list: confirmed really arrived, missing did not (stays unmarked and goes out again next time).

Set the signed-in user's macro philosophy and targets. Semantics differ per macro: protein is a floor (at least X g), carbsMaxG a cap (at most; null = no cap), fat fills the remaining calorie budget automatically. clear=true removes the configuration.

Creates an anonymous link to a collection of several saved dishes under one title, e.g. a weekly plan ('Fünf grüne Smoothies für die Woche') or a group's recipes. The page shows every recipe with nutrients per portion plus the combined shopping list; visitors copy all dishes with one tap, optionally putting the ingredients on their own shopping list. The collection can be extended later while the link stays the same. cardUrl is a square card (1080×1080 PNG).

Create an anonymous, time-limited link to one day of the signed-in user's Joiva food log. Anyone holding the link sees the eaten entries and the day's totals without an account; planned (not yet eaten) meals stay private. A day link always shows the current state: anything logged later appears too. The returned URL appears only in this reply and cannot be retrieved again.

Create an anonymous, time-limited link to one meal. entryIds are log entry ids of one meal (the day view groups them per meal in meals). Unlike a day link, the set of entries is frozen: nothing logged afterwards shows up in it. The returned URL appears only in this reply and cannot be retrieved again.

Creates an anonymous link to one saved dish as a recipe to cook: name, ingredients with grams and nutrients per portion, no day, no daily totals. Whoever opens it copies the dish into their own Joiva dishes with one tap; without an account the button leads through sign-up and back, then Joiva copies it by itself. The dish is chosen by savedMealId or mealName. cardUrl is the square nutrition card (1080×1080 PNG) for posting. The URL is returned only once and cannot be looked up again.

Declare a meal slot (Frühstück/Mittagessen/Abendbrot/Snack: the time slot, not a saved dish) as skipped for one day: 'Mittagessen fällt heute aus'. The slot then counts as zero when the day is evaluated, instead of being an open gap. If planned entries exist in that slot, the call reports their count instead of writing; discardPlanned=true drops them. Eating into the slot later removes the skip automatically. This is not fasting: fasting windows are kept in Still.

Undo a skipped meal slot: the slot becomes an open question again for that day.

Extends or edits a collection link by its shareId: appends dishes (add / addNames), removes dishes, renames it, or sets a new validity from now. The URL stays the same and shows the new state at once; someone who already copied the collection only gets the new dishes on the next tap.

Change an existing food rule by its ruleId: stance, reason, note, aliases.

Change grams, time, preparation (garung, behandlung) or preparation note of an existing Joiva log entry. Changing the preparation re-derives that entry's nutrient values (measured BLS variant first, else documented USDA retention factors); the catalog product stays untouched.

Correct a pantry item: new absolute quantity, storage location, best-before or note. quantity: 0 marks it as used up.

Change an entry on the Joiva shopping list: tick it off (status 'done' = bought), reopen it ('open'), or correct name or detail. A reopened entry is sent to Bring! again on the next send.

Make a plan the active one (deactivates the current active plan).

Add a supplement to a plan's schedule at a time slot.

Add a supplement or health product to the Stackwell shopping list. Groceries and food are not kept on this list; they belong on Joiva's shopping list. Borderline items that belong here because they sit in the supplement plan: protein powder, collagen, MCT oil, electrolyte powder.

Archive (or unarchive) a supplement: removes it from the active stack without deleting history.

Create a new intake plan (optionally as a new version of an existing plan) with schedule entries. The new plan is not activated.

Add a supplement product to the signed-in user's Stackwell stack with its ingredients per dose.

Delete an intake log entry.

Remove an item from the shopping list (e.g. a duplicate or obsolete entry).

Get the signed-in user's active Stackwell intake plan with its schedule (supplements, dosages, time slots).

Daily supplement adherence (taken vs planned) for a date range.

Journal detail for one day: intake logs, planned entries and plan activations.

The signed-in user's Stackwell health context: goals, conditions, diet, fasting protocol, lifestyle, biometrics, restrictions.

Total daily nutrient intake across the active stack, compared against the user's followed reference profiles (upper limits, RDAs).

Get one intake plan with its schedule entries.

Get the signed-in user's Stackwell shopping list: supplements and health products only (running low / empty plus manual items). Groceries are not part of this list; they are kept in Joiva.

Get the signed-in user's Stackwell supplement stack (all supplements with ingredients, inventory and pause state).

Get the signed-in user's Stackwell supplement intake logs for today.

List all of the signed-in user's intake plans (active, drafts, history).

List planned intake pauses (optionally for one supplement).

Log that the signed-in user took a supplement. Defaults to now; takenAt records a dose taken earlier in the same step.

Mark a supplement as used up; it goes onto the shopping list.

Pause (or resume) a supplement, e.g. during a fast or a wash-out phase.

Remove a schedule entry from a plan.

Delete a planned intake pause.

Replace the ingredient list of a supplement.

Create a planned, time-boxed intake pause (e.g. stop biotin 48h before a blood draw). Covered days leave the adherence denominator and show as planned_pause in the history.

Record that the signed-in user skipped a planned supplement intake (with a reason). Defaults to now; takenAt records a dose skipped earlier.

Update the health context (only the given fields change). Arrays replace the stored list.

Correct an intake log (dosage, unit, time).

Change a schedule entry (slot, dosage, meal relation, time, notes).

Edit a shopping-list item's name, brand or notes (only the given fields change; null clears brand/notes).

Set a shopping-list item's status to 'ordered' or 'delivered'. Delivered restocks the linked supplement.

Update a supplement's details (only the given fields change).

Record a glucose and/or ketone reading in Still (linked to the running fast, GKI derived, mirrored to Vora). At least one of glucose or ketone is required.

End the signed-in user's current fast now (or at the given time) by recording an eating event in Still.

Recent fasting sessions (newest first) with start, end and duration in minutes.

Get the signed-in user's current Still fasting state: whether fasting, since when, elapsed time, active template and target end time, plus the enabled templates.

Aggregated fasting stats for the signed-in user: current fast, day streak, longest / average fast, total fasts, fasts in the last 7 and 30 days.

List fasting templates available to the signed-in user (global presets and their own) with fasting/eating hours; marks the selected and enabled ones.

Switch the signed-in user's active Still fasting template (by template id, e.g. 16:8 → 19:5).

Start a fast for the signed-in user now (or at the given time). Fails if a fast is already running.

Diagnostics for this connection: gateway build (commit, build time), server time, the apps the user has enabled for AI access, and the complete list of tool names the gateway serves for this account right now. An MCP client fetches the tool list once when connecting, so this list can contain tools that a long-running client does not show yet. Also returns reportHeader, a one-line statement (German) of the gateway build and query time that a test note or bug report can be dated with.

Add a person to the signed-in user's care network (e.g. a doctor). Near-duplicates (name match ≥ 0.85) return the existing record with deduped=true unless force=true.

Add an organization to the care network. The address is geocoded automatically. Near-duplicates return the existing record with deduped=true unless force=true.

Remove a contact from the care network (soft delete).

Remove an organization from the care network (soft delete).

Get one contact by id, including its organization roles.

Get the signed-in user's daily wearable values from the Vitalli hub, one entry per day, newest first: sleep score, total sleep, efficiency, deep, REM and light sleep, awake time, sleep latency, time in bed and bed times; readiness score, resting heart rate, average night heart rate, HRV, respiratory rate, SpO2 and skin temperature deviation; steps, active calories and activity score. Each day names its primary device (Oura, Polar, Garmin, Apple Health or Withings, preferred in that order; provider apple_health is the Apple Watch and other apps writing to Apple Health), lists fields that came from another device in fieldSources, and carries syncedAt. hrvMethod says what hrvMs is: rmssd (Oura, Polar, Garmin) or sdnn (Apple Health); the two are not comparable. latestNight is the newest day in the range with sleep data, devices lists the connected devices with their last sync. Fields a device does not measure are null; Apple Health has no sleep score, so sleepScore is null there. Sleep stages and bed times exist for Oura, Garmin and Apple Health. Days are calendar days in Europe/Berlin, a night counts for the morning it ended. Values are device measurements and the providers' own scores, not a medical assessment.

Get the signed-in user's Vitalli hub health profile: date of birth, biological sex, weight, height, blood type.

Get the signed-in user's cross-app longevity overview as computed by Vitalli: a composite score; PhenoAge and its difference to chronological age, calculated with the published PhenoAge formula from Vora lab values, with notes on factors that can distort a reading; fasting adherence from Still; a supplement stack score from Stackwell; and, with a connected wearable, a fitness component. Statistical estimates from the user's own data, not a medical assessment.

Get one organization by id.

Step-by-step procedures for common tasks with the Vitalli tools, one topic per answer: 'food' (Essen eintragen (Joiva)), 'time' (Vortag, Uhrzeit, Mahlzeit), 'meals' (Mahlzeit bündeln, Gericht merken), 'corrections' (Korrigieren), 'planning' (Mahlzeiten planen), 'supplements' (Supplemente (Stackwell)), 'fasting' (Fasten (Still)), 'labs' (Laborwerte und Beobachtungen (Vora)). Each answer names the tools, the order and the fields for that task, for example how a described dish with an ingredient list is logged for yesterday evening. Without a topic it lists the topics. Also returns the apps this account has enabled.

Attach a contact to an organization with a role (e.g. Dr. X works at practice Y).

List the signed-in user's care-network contacts (doctors, therapists, trainers, family, …). Optionally filtered by organization id.

List the signed-in user's care-network organizations (practices, hospitals, labs, pharmacies, gyms, insurers, …).

Update fields of a contact (only the given fields change).

Update the signed-in user's Vitalli hub health profile (only the given fields change).

Update fields of an organization (only the given fields change). Address changes are re-geocoded.

Add an allergy to the signed-in user's Vora record.

Record a biomarker / lab value for the signed-in user with unit conversion, fasting-aware plausibility check and GKI derivation (e.g. glucose 95 mg/dL, ketone 1.2 mmol/L, weight 82 kg, CRP 0.4 mg/dL). A reply of created: false, deduped: true means success: the same reading was already stored (typically entered in the app shortly before) and this one was merged into that row, whose id is returned. This path never deletes anything.

Record a Bristol stool entry (type 1-7) with optional flags for the signed-in user.

Add a medical condition / diagnosis to the signed-in user's Vora record. Dates are YYYY-MM-DD.

Add a family medical history entry to the signed-in user's Vora record.

Add a medication (e.g. an antibiotic course with start/stop dates) to the signed-in user's Vora record. Dates are YYYY-MM-DD.

Record the signed-in user's mood: score -2 (very bad) .. 2 (very good), daily or momentary, with optional drivers from Vora's mood driver catalog and a note.

Record a generic measured value / tracked metric (free-form biomarker name, string value) at a point in time for the signed-in user. The value is stored as given, without unit conversion. A reply of created: false, deduped: true means success: an equivalent reading already existed and this one was merged into it (its id is returned).

Record a symptom with a severity score (1-10) on a given date for the signed-in user. Date is YYYY-MM-DD.

Delete one biomarker observation from the signed-in user's Vora record (by id). Values that came from a document extraction or a CSV import are protected and return an error unless force=true; the regular way to remove those is deleting the document or rolling back the import in Vora.

Delete a condition from the signed-in user's Vora record (by id).

Delete a mood entry (by id).

Delete one observation by id. Rows that came from a document extraction or a CSV import are protected unless force=true; the regular way to remove those is deleting the document or rolling back the import in Vora.

Delete a symptom snapshot (by id).

Removes the signed-in user's traffic-light levels for one biomarker. The levels are gone afterwards.

Get the signed-in user's full Vora health profile: demographics, conditions, medications, allergies, family history, latest biomarkers (last 50), and AI insights. Read-only.

Latest value per PhenoAge-relevant biomarker (albumin, creatinine, glucose, CRP, lymphocytes, MCV, RDW, ALP, WBC) plus the current fasting context.

The signed-in user's own traffic-light levels per biomarker (e.g. GKI: green below 1, yellow 1 to below 2, …), as set by the user; Vora suggests none. Each level has color, from/upTo (upTo is exclusive: a value exactly on a limit belongs to the next level), optional label and the date it was set. Without slug: every biomarker that has levels.

List the signed-in user's biomarker observations (lab values, glucose, ketones, weight, …), newest first, up to 200, filterable by biomarker name and/or date range.

List the signed-in user's Bristol stool entries (type 1-7 plus flags).

List the signed-in user's conditions / diagnoses.

List the signed-in user's uploaded medical documents (lab reports, findings) with type, date, provider and extraction status. Metadata only.

List the signed-in user's mood entries (score -2..2 with drivers) for a date range.

Catalog of the mood driver categories and values that a mood entry accepts.

List the signed-in user's recorded observations (biomarker values) with their ids, filterable by biomarker name, date range or source.

List the signed-in user's tracked symptoms (severity 1-10 snapshots). By default active ones only.

Mark a tracked symptom as resolved / no longer active (by id).

Sets the signed-in user's own traffic-light levels for one numeric biomarker and replaces existing ones. The limits are the user's own; Vora suggests and rates nothing. 2 to 5 levels: n-1 limits in ascending order for n levels, plus the direction. Colors follow from count and direction (lower_better: green, yellow, orange, red, violet from low to high values; higher_better: reversed). Scale values such as the Bristol chart have no levels.