Cookidoo has no public API and their ToS prohibits scraping, so a direct integration would be both legally fragile and maintenance-heavy (the scraper breaks on every UI change Vorwerk pushes). The indirect path that works today: Mealie is a self-hosted recipe manager that imports Cookidoo URLs as one of its many recipe sources, and NutriTrace has Mealie integration built in (Settings → Mealie). Your wife adds recipes from Cookidoo into Mealie once, and they show up as searchable foods in NutriTrace with full nutrition.

Also worth mentioning: I’ve got a sister app called CookTrace (may not be final name) in development as a purpose-built self-hosted recipe manager that pairs natively with NutriTrace (same UI patterns, same AI assistant, federation already wired between them). It has a schema.org Recipe scraper for URL imports, though Cookidoo itself is gated content so it’d still need either a Mealie middle layer or manual entry. Currently private; aiming for a public release in the next month or so.

That is correct, and it is called out in the README under Apps → iOS and in the Support section at the bottom. iOS needs a Mac, an iPhone, and a paid Apple Developer account, none of which I currently have. The Support section is where I mention that donations go toward exactly that. Apple Health sync specifically needs a native iOS wrapper since the data isn’t exposed to PWAs, so it has to wait on the same blocker. I hope to someday get this out to the community.

Nice work, exactly the kind of bridge that makes leaving MFP a lot less painful for self-hosters. Would you be OK with me linking the gist from the NutriTrace README (under Foods & Meals) and from inside the Bulk Food Import modal? Happy to credit it as your script with a link back to the gist.

Either way, thanks for putting it together.

Let me know your issues and post server/browser console/app logs, and ill do my best to assist. You can also create an issue if you feel that this is a bug in the repo. Outside of this i do want to mention, im working on a suite of “Trace” apps. One of which is a Recipe app. I love Mealie, but wanted a bit more for myself, and have created something that i think will be special. It also allows for direct api integration to and from NutriTrace. Will hopefully have a beta that will be publicly available in the next month or so if interested.

Thank you so much! I appreciate it!

Yes! Settings → Backup → Nutrition Import. Built-in adapters for MyFitnessPal, Cronometer, LoseIt, and a generic CSV shape. Export your diary from MFP (it’s a CSV in their account settings), upload it, preview, commit. Skip / Merge / Replace per-date semantics, so you can re-import safely without overwriting.

Open Food Facts (OFF) for barcodes. Free, open license, community-edited. Their API: https://world.openfoodfacts.org/api/v2/product/<barcode>.json

Yes, Health Connect is supported on the Android app. As long as Samsung Health is set to write to Health Connect (Samsung Health → Settings → Connections → Health Connect), NutriTrace can read steps, sleep, heart rate, weight, and exercise from it.

Honestly though, this path hasn’t had many testers yet, so if you give it a shot I’d really appreciate a heads-up on what works and what doesn’t. Feedback (positive or bug reports) is welcome on GitHub.

Hey, thanks for trying it out!

For things you don’t measure by weight (eggs being the classic example), the easiest path is to make a local entry once and then reuse it. A few ways to go about it.

The nutrition label on your egg carton is your friend here. It’ll show you the serving size, usually 1 large egg at around 50g, plus the full breakdown (calories, protein, fat, carbs). Tap the + on the Foods page, type those numbers in, set Serving size to 50 and Unit to “grams”. From then on, logging eggs is just typing “Quantity: 2” in the diary and the math takes care of itself.

For irregularly-sized stuff like apples or bananas, a kitchen scale is honestly the easiest path. A medium apple can swing anywhere from 130g to 220g, so weighing it once and typing the gram count gets you accurate numbers without needing a separate per-piece entry for every size.

One thing worth knowing about OFF and USDA results: the “100g” you see is just the per-100g nutrition density. That’s how those databases store everything, it’s a baseline reference, not a forced serving size. So you can either weigh your food and type the grams directly, or edit the entry to change the portion and unit (say to “1 piece” or “1 cup”) and the totals rescale.

Once you’ve dialed in a handful of items you eat regularly, day-to-day logging gets a lot faster. The new Favorites and Most Used sort in rc.19 will float your top items to the top of the Foods page automatically.

Thank you! Enjoy the app!

Great glad that fixed it!

Thanks for catching this. The Cronometer adapter was treating the parsed gram count as a serving multiplier, so a 750g entry got its calories multiplied by 750. The “NaNg” had the same root cause: the portion was stored as the raw string “750.00 g”, which JS coerces to NaN when the diary tries to multiply it for display.

The layout overlap on the duplicate-day dialog is should now be fixed too (added a divider so the buttons have proper visual separation from the radio options).

Both are hopefully now fixed and pushed in rc.14. Grab the latest package, delete the affected day from your diary, and re-import. Items should hopefully now come in with the right values.

Thanks again for the detailed report.

Thanks for implementing it that fast! Unfortunately I wasn’t able to test it.

I found the new section in the readme. So I followed it. I created an admin account (which confused me a bit - my user already had admin permissions. So why is it necessary to create another admin user?). Then I wanted to logout and login with the admin again. But I wasn’t able to figure out how to log out. So I just deleted the cookies and local storage.

After that I was greeted by the login page. So I logged in as admin, entered the User Management - and found an interface to manage users. Ok, sounds logic to find a user management tool in the “user management” menu entry. But the readme said, that there should be oidc settings. Maybe they got lost in a merge conflict or something like that. I was testing on rc12.

Anyways I would prefer an env variable to configure oidc. I like to separate the technical configuration (like credentials, etc) from the user space configuration.

This comment may sound super negative, but I’m actually very grateful you addressed this feature. Thanks!

Thanks for the detailed walkthrough. A few of the rough edges you ran into are fixed in the latest release:

The admin-account confusion makes sense in hindsight. If you were already running NutriTrace single-user, you genuinely didn’t need an admin account, that step exists because OIDC requires user management to be on. The README now spells that out as a prerequisite up front so it doesn’t feel like surprise paperwork.

Logout has a real home now. Profile lives at the very top of Settings as a card showing your name and photo, and Log Out is right there inside it. No more digging through the cookie jar.

The “where are the OIDC settings” question was on me. They were buried inside User Management. They’re now their own top-level section called Authentication, sitting right under User Management, with presets for Authentik, Keycloak, Authelia, Pocket ID, Auth0, Google, and a generic OIDC option for anything else.

And on your env-var preference, that’s in too. You can configure providers entirely from .env or docker-compose.yml. Single-provider shorthand:

OIDC_ISSUER=https://auth.example.com/ OIDC_CLIENT_ID=nutritrace OIDC_CLIENT_SECRET=… OIDC_DISPLAY_NAME=Authentik OIDC_REDIRECT_URIS=https://nutritrace.example.com/api/auth/oidc/callback/1

Multi-provider works with OIDC_PROVIDER_2_, OIDC_PROVIDER_3_, etc. Anything you define this way shows up in the Settings UI with a lock badge and is read-only there, so it’s clear where the source of truth lives. Full doc in .env.example and the README.

Pull the latest and give it another shot when you have a minute. Please confirm the env-var path actually works for your IdP when you have a chance.

Thanks again.

I gave this a shot, but when I press the “preview” button I just get a little popup that says “Invalid CSRF token”.

Hmm… i think i see the issue. The preview / commit upload was missing the CSRF token, so the server was rejecting it before it even read the file. Just pushed a fix. Once you pull it down, hard-refresh the page (Ctrl+Shift+R / Cmd+Shift+R) to grab the new bundle and try again.

OIDC feature has been added to app in latest build (1.0.0-rc9). Please test and let me know how it works for you. I successfully tested with Authentik.

Import feature has been added to app as experimental in latest build (1.0.0-rc9). Please test and let me know how it works for you.

OIDC has been planned, but since now i have had multiple requests, i have started working on it. Will be implemented most likely in next RC release. Keep an eye out!

The JSON-massage route may work. Diary items are self-contained snapshots, IDs in your file are ignored on import, and the only real catch is that re-importing a date overwrites the existing entry. Happy to drop the field-by-field shape if you want to go that route.

That said, native CSV importers for the popular apps (MFP, LoseIt, Cronometer, etc) are now on the near-term roadmap (thanks to your suggestion) as the proper path for this. If you can hold off a bit (and use one of the above), that’ll be much easier.

Thanks for the offers to help with translations. Wanted to share the plan.

I’m wiring up the translation infrastructure now: svelte-i18n with one JSON file per locale in the repo. The workflow once it’s ready is straightforward. There’ll be a single English source file at src/i18n/en.json, contributors copy it to their locale (fr.json, nl.json, de.json, etc.), translate the values, and open a pull request. Keys stay untouched, only values change.

Nothing to do right now. I’ll open a GitHub tracking issue once the source file is stable enough to translate against. A short contributor guide will land with it covering workflow and conventions.

One thing worth flagging early: for nutrition labels specifically, please plan to use the regulatory terms that appear on food packaging in your country rather than the literal English equivalents. So Glucides / Lipides / Protéines for French, Koolhydraten / Vetten / Eiwitten for Dutch, Eiweiß rather than Protein for German, and so on.

More soon.

Quick update on this. Translation infrastructure is live as of v1.0.0-rc.6 (released today). The source file is src/i18n/en.json — about 210 keys covering navigation, page titles, the full auth flow, the onboarding wizard, primary actions in Diary / Foods / Goals / Profile, the AI assistant FAB, and common toasts. Server-side strings (email subjects, push notification bodies) are out of scope for now.

Full workflow is documented in CONTRIBUTING.md → Translations.

About 30% of the client-side surface is extracted in this batch — the screens every user touches every session. Wellness sync messages, deep Settings sub-section labels, and Statistics chart internals are the main gaps. If you hit a screen you use heavily that’s still English while translating, open an issue listing the screen and I’ll pull it forward in the next extraction batch.

Tag me on the PR when you’re ready.

Thanks for the offers to help with translations. Wanted to share the plan.

I’m wiring up the translation infrastructure now: svelte-i18n with one JSON file per locale in the repo. The workflow once it’s ready is straightforward. There’ll be a single English source file at src/i18n/en.json, contributors copy it to their locale (fr.json, nl.json, de.json, etc.), translate the values, and open a pull request. Keys stay untouched, only values change.

Nothing to do right now. I’ll open a GitHub tracking issue once the source file is stable enough to translate against. A short contributor guide will land with it covering workflow and conventions.

One thing worth flagging early: for nutrition labels specifically, please plan to use the regulatory terms that appear on food packaging in your country rather than the literal English equivalents. So Glucides / Lipides / Protéines for French, Koolhydraten / Vetten / Eiwitten for Dutch, Eiweiß rather than Protein for German, and so on.

More soon.