# Case study: photo and voice food logging inside a fitness marketplace

September 29, 2026 · For Developers · 9 min read · https://burnweek.fit/blog/case-study-fitness-marketplace-nutrition-sdk/

> A fitness marketplace wanted food logging in its own app, in Estonian, with closed days feeding its loyalty programme. How the embed, login and rewards fit.

**Key takeaways**

- A fitness marketplace embedded the nutrition SDK instead of building tracking: configured, not forked.
- Host theming and the Estonian locale made it feel native; data colours stayed fixed so calories and protein mean the same everywhere.
- Members sign in once through federated OIDC; existing accounts were linked and their food logs merged.
- Closed days reach the loyalty programme as neutral signed day_close events; the partner keeps every points rule.
- Lessons: agree fixed parts early, start from generic events, plan account linking, and treat the example host as documentation.

## The brief

A fitness marketplace sells gym memberships, classes and equipment, and runs a loyalty programme in which members earn points for healthy habits. Its members kept asking for food logging, and the product team had the same roadmap item most teams have: add calorie tracking. They did not want to become a nutrition company. They wanted their members to log meals inside the marketplace app, in Estonian, under the marketplace's own look, and they wanted a closed day of logging to count toward the loyalty programme.

The constraints were specific. The feature had to feel native to their app rather than like a link out to someone else's. Members would sign in once, with their existing marketplace account. The loyalty rules, how many points, how often, for what, had to stay entirely in the marketplace's hands, because they change with promotions. And the partner did not want its own engineers maintaining nutrition screens.

This post describes how that integration was put together, what worked, and what we would change. We do not name the partner, and there are no screenshots of their app.

## Embedding, not rebuilding

The marketplace's app embeds our [nutrition SDK](/blog/stop-building-your-own-calorie-counter): the same four packages our own tracker uses, installed at one pinned version and compiled by the host's bundler. The team configured it rather than forking it. The host configuration sets an identifier and display name, the Estonian locale, a theme, the visible entry points (Home, Plan, Library, History, Profile) and a content slot at the top of Home where the marketplace shows its own membership card.

Theming did most of the work of making it feel native. The host overrode the foundation palette and the semantic colours for the nutrition header and planned-meal segments, set its own corner radii, and used a system font family that covers both Latin and Cyrillic, so no font download was needed. The data colours, the ones that mean calories and protein, are fixed in every host, and that was the one discussion worth having early: brand teams instinctively want to recolour everything, and a colour that means "protein" in one app and something else in another is a real usability cost.

Localisation was the smoothest part. The SDK ships English, Estonian and Russian strings, and the host sets the locale. Copy that the marketplace placed in its own slot, the membership card, stayed its responsibility. The logging itself works in whatever language the member types or speaks: a member can describe lunch in Estonian and get a component breakdown back with calorie and protein ranges, the same shape our [ranges post](/blog/calorie-estimates-as-ranges-api) describes. Voice and photo mattered more than we expected for this audience: members log between classes and on the way home, and a sentence is faster than a search. That matches the adherence evidence, where the same programme delivered through a phone app was logged on far more days than on a website or paper diary ([Carter et al., 2013](https://pubmed.ncbi.nlm.nih.gov/23587561/)). Ranges mattered too, because members describe portions loosely and people misjudge portions by food type ([Almiron-Roig et al., 2013](https://pubmed.ncbi.nlm.nih.gov/23932948/)).

A working example host, with the partner's values neutralised, lives alongside the SDK and is rebuilt from the released tarballs on every release. That example did double duty: it was the integration guide, and it is the release gate that proves a host can build using only the published artifacts.

## One login across two products

The requirement was simple to state: a member signs in to the marketplace, opens nutrition, and is already signed in. The implementation is standard OpenID Connect. The marketplace acts as the identity provider for its members, our login federates to it, and the SDK client in the host app obtains tokens for our API with the member's own session. No shared API key ships inside the marketplace app.

Two details took more thought than expected. First, some members already had an account with our own tracker under the same email before the partnership existed. Linking the marketplace account to the existing one, and merging the food logs rather than starting a second empty history, avoided the worst possible first impression: "where did my meals go?". Second, account switching. A shared family tablet signed in as one member and then another must never show one person's meals to the other. The SDK partitions stored data per account and moves state and storage together on sign-in, sign-out and switch, so the host did not have to build that.

The attribution rule helped here too. Sign-in and onboarding show only the marketplace brand. Inside the calorie screens there is one quiet line crediting the tracker, and tapping it opens the marketplace's own page about how nutrition data is handled. Members were never interrupted by a vendor pitch.

## Rewarding closed days without coupling

The loyalty requirement is where it would have been easiest to do the wrong thing. The first contract drafts described a partner-specific webhook, a partner-specific reward description and an SDK callback that only existed for this one host. Each of those would have been a small convenience and a long-term liability: every future partner would need its own code path, and loyalty concepts would leak into a tracker that should not know what a point is.

What shipped instead is generic. When a member closes their day, the tracker emits a neutral `day_close` event carrying an issuer, the member's subject identifier, the date, an event id and a timestamp. The marketplace is one entry in a configured list of event subscribers. It receives a signed HTTP delivery (HMAC over the payload with a timestamp header), verifies it, deduplicates on the event id because delivery is at-least-once, and applies its own rules: whether this date is eligible, whether a reward was already paid for it, how many points to award, and what animation to show in its own UI.

The tracker's close-the-day behaviour is identical with or without subscribers, and closing a day is driven by the member rather than by how many calories they ate. That matters for the behaviour being rewarded. Self-monitoring is associated with better weight outcomes across most of the studies in the literature, though adherence falls over time ([Burke et al., 2011](https://pubmed.ncbi.nlm.nih.gov/21185970/)). Rewarding the act of completing a log, rather than a number, rewards the habit that the evidence points at, and the [accuracy piece](/blog/how-accurate-is-calorie-counting) explains why a calorie target would be a noisy thing to pay out on anyway.

## What we'd do differently

**Agree the fixed parts on day one.** The data colours and the attribution line are not negotiable in any host. We now state that in the first call rather than after a theme has been designed around a different protein colour.

**Start from the generic event contract.** We wrote a partner-shaped draft first and then generalised it. Starting from neutral events would have saved a round of rework for both sides, and it is now simply how every integration starts.

**Plan for existing accounts.** Account linking and log merging were added once we noticed members who used both products. Any partner with an overlapping audience should expect the same, and it belongs in the initial scope.

**Treat the example host as the documentation.** Written guides drift. A host that must build from the released artifacts on every release cannot drift without failing loudly, and it answered most of the partner team's questions before they asked them.

**Budget for native releases.** Voice and camera logging need native modules in the host app, and mobile members only receive SDK updates when the host ships a new binary. That is normal for mobile, but a web team new to it should plan release trains accordingly.

## FAQ

### Did the partner need to change its backend?

Only to receive and verify the signed events it subscribes to, and to act as the identity provider for its members. The nutrition data and estimation stay on our side.

### Can members use the same food log elsewhere?

Yes. The log belongs to the member's account, so the same history is available in our own app and assistants that connect to it, such as our [ChatGPT app](/blog/chatgpt-app-launch).

### Who decides how many loyalty points a closed day earns?

The partner. The tracker only reports that a day was closed; caps, eligibility windows and point amounts live in the partner's system.

## Sources

- [Burke LE, Wang J, Sevick MA. Self-monitoring in weight loss: a systematic review of the literature. J Am Diet Assoc. 2011.](https://pubmed.ncbi.nlm.nih.gov/21185970/)
- [Carter MC, Burley VJ, Nykjaer C, Cade JE. Adherence to a smartphone application for weight loss compared to website and paper diary: pilot randomized controlled trial. J Med Internet Res. 2013.](https://pubmed.ncbi.nlm.nih.gov/23587561/)
- [Almiron-Roig E, Solis-Trapala I, Dodd J, Jebb SA. Estimating food portions. Influence of unit number, meal type and energy density. Appetite. 2013.](https://pubmed.ncbi.nlm.nih.gov/23932948/)

Source: BurnWeek — "Case study: photo and voice food logging inside a fitness marketplace", https://burnweek.fit/blog/case-study-fitness-marketplace-nutrition-sdk/. Licensed CC BY 4.0: free to quote or reuse with a link to this page.