A food API gives you
- –Food search
- –Nutrient tables per 100 g
- –Recipe records
- –Barcode lookup
ONEBY OSCA
Personalised nutrition engine.
Personalised nutrition infrastructure for the products you are building.
ONE turns a person’s energy needs, macro targets, allergens, diet type and nutrient priorities into meal plans, food logging, deficiency analysis and substitutions — delivered as a multi-tenant REST API that runs behind your product.
Your users stay in your app. Your brand stays on the experience.
Engineering teams: Explore the API · View SDKs
- 1–14
- Days of meals per plan request
- 4
- Meal slots: breakfast, lunch, dinner, snack
- 3
- Reference standards: EU NRV, UK RNI, US DV
- 4
- Server SDKs: Node, Python, PHP, .NET
Not a food API
A food API returns data. ONE makes the decision.
Food databases answer questions about food. The hard part of personalised nutrition is deciding what this specific person should eat next, given everything you already know about them.
ONE resolves
- ▸Which foods this person must never be offered
- ▸What their energy and macro targets are today
- ▸Which nutrients they have been short of this week
- ▸What to serve instead when they reject a meal
The lifecycle
Profile → Plan → Track → Analyse → Adapt → Optimise
Each stage is a set of endpoints your product calls when it needs them. You can adopt the whole loop or only the part you are missing.
01
Profile
Store demographics, goal, diet type, allergens, dislikes and preferred cuisines per user. Energy and macro targets are derived with Mifflin–St Jeor, or set explicitly when your product already knows them.
02
Plan
Generate 1–14 days of breakfast, lunch, dinner and snacks against those targets. Swap, lock or regenerate a single slot without rebuilding the plan.
03
Track
Log meals as confirmed, partial, replaced or manual entries, including barcode lookups for packaged food.
04
Analyse
Compare daily and historical intake against macro targets and micronutrient reference values, with deficiency risk graded from adequate to high.
05
Adapt
Preference events feed per-user affinity scores that decay over time, so recent behaviour counts for more than last quarter's.
06
Optimise
Apply a micronutrient focus — iron, folate, bone health, immune support and others — and regenerate future plans with that priority.
Capabilities
What you get on day one.
These are engine behaviours, not a roadmap. Each one is reachable from the API the moment your tenant is provisioned.
01
Requirement modelling
Mifflin–St Jeor energy needs against activity level and goal, macro splits per goal type, and micronutrient targets from EU NRV, UK RNI, US DV or a reference table you supply.
02
Constraint-aware planning
Allergens and diet type are hard constraints. Macro bands and micronutrient floors are scored, so the planner returns the best feasible plan rather than failing.
03
Rule precedence
Rules resolve request over profile over tenant default over platform default, in flexible, balanced or strict mode — and the API returns which layer decided each rule.
04
Food logging
Confirm a planned meal, log a partial portion, replace it with something else, or record a manual entry. Barcode lookup resolves packaged foods.
05
Deficiency analysis
Intake as a percentage of the reference value per nutrient, graded adequate, low, moderate or high risk, and routable straight into a micronutrient focus.
06
Substitutions
Suggest alternatives that hold calories and protein roughly constant, drawn from substitution templates, your own substitution graph and food-group siblings.
07
Preference learning
Affinity scores from 0 to 100 per user, built from accept, reject and swap events with time decay, and used to rank candidates during planning.
08
Shopping lists
Aggregate a plan into a consolidated list with quantities, delivered as JSON, CSV or a PDF carrying your branding.
09
Your catalog
Author custom foods and recipes with a draft, publish and archive lifecycle, and override entries in the bundled catalog for your tenants.
Product examples
What this looks like once it is in your product.
Example tenant UI. The nutrition logic is ONE; the interface, brand and tone are entirely yours.
Select a profile. Every card below is generated from that one person.
01
Profile
Who is this person?
02
Targets
What are they trying to achieve?
03
Requirements
What must be avoided?
04
Plan
What should they eat?
05
Track
What have they eaten?
06
Adapt
What should happen next?
ONE starts with the person, understands their goals and requirements, applies safety rules and preferences, and turns that context into personalised food decisions.
Example · Personal nutrition profile
DietVegetarian
AllergiesPeanuts
GoalIncrease iron intake
ActivityModerately active
Daily targets
Calories2,100 kcal
Protein100 g
Carbohydrates240 g
Fat70 g
Micronutrient focus
↑ Iron
Example · Personalised meal plan
Monday
Breakfast
Iron-rich overnight oats
Lunch
Lentil and spinach bowl
Dinner
Tofu stir-fry
✓ Vegetarian✓ Peanut-free↑ Iron priority
Example · Daily nutrition
Today's nutrition
Iron14.2 / 18 mg
Protein82 / 100 g
Next plan
Prioritise iron-rich foods based on recent intake.
Example · Safety first
DietVegetarian
AllergyPeanuts
GoalIncrease iron intake
Preferred foodPeanut satay
Plan filters
- ✓ Vegetarian
- ✓ Peanut-free
- ✓ Iron target
Peanut satay
Excluded · Allergy rule
Preferences never override safety requirements.
Example · Requirements + preferences
Must avoid
PeanutsShellfish
Prefer
SpinachLentilsFortified cereals
GoalIncrease iron intake
ONE first removes what is incompatible, then optimises the remaining choices around goals and preferences.
Example · Food substitution
Recommended
Beef chilli
⚠ Vegetarian profile
↓
Alternative
Lentil and spinach chilli
✓ Vegetarian✓ Iron-compatible✓ Fits the meal
Example · Nutrient focus
Micronutrient focus
Iron-richFolate focusBone healthImmune supportB vitaminsFull micronutrients
Iron-rich
Daily target18 mg
Current intake14.2 mg
Remaining3.8 mg
Next plan prioritises iron-rich foods within existing diet and allergy rules.
Example · Adaptive planning
Recent history
MonLentil bowl
TueTofu stir-fry
WedChickpea curry
Next plan
- ✓ Avoid repeating recent meals
- ✓ Maintain nutritional targets
- ✓ Prioritise current nutrient focus
ONE supports ongoing nutrition experiences — not only one-off meal plans.
Why this matters for your product
Your product can decide how much of this experience to expose.
ONE provides the underlying nutrition engine. Your product decides whether users see a simple meal recommendation, a full meal plan, nutrient tracking, dietary preferences, goal setting, food logging or coach-facing analytics.
You choose the experience. ONE provides the nutrition logic underneath.
Build versus integrate
The expensive part is not the recipe database.
Teams usually discover the real cost after the first prototype, when a single plan has to satisfy an allergen list, a calorie target, a protein floor and two weeks of variety at the same time.
01
A planner that stays feasible
Greedy selection breaks down once allergens, macro bands, micronutrient floors and variety all apply at once. Real plans need search that can backtrack.
02
Allergen data you can trust
Allergens have to be canonicalised across every catalog you ingest, then enforced on every candidate. This is the part that must never be wrong.
03
Reference values per market
EU, UK and US publish different reference intakes. Selling into several markets means maintaining several tables and knowing which applies.
04
A catalog with real nutrition
Recipes need per-portion nutrition, ingredient groups, diet tags and portion maths before a planner can use them at all.
05
Variety over a long horizon
Optimising each day independently produces the same three dinners all fortnight. Uniqueness has to be solved across the whole horizon.
06
The multi-tenant layer
Isolation, key rotation, per-tenant catalogs and defaults, webhooks, usage metering and residency — before you write any nutrition logic.
ONE provides the nutrition infrastructure. Your team spends its time on the experience your customers actually use.
Who builds with ONE
Product teams that need nutrition to be right, not novel.
The buyer is a product or engineering team with a nutrition requirement inside a product they already own — not a consumer looking for another meal-planning app.
01
Health and digital care platforms
Add nutrition to an existing care or wellness journey without standing up a food catalog and planner.
02
Fitness and coaching
Pair training load with meal plans that respect the athlete's goal, allergens and preferences.
03
Weight management
Energy targets from the person's own demographics and goal rate, with logging and progress against them.
04
Nutrition and food products
Bring your own recipe catalog and use ONE for the personalisation layer on top of it.
05
Corporate wellness
Run many client organisations as separate tenants, each with its own defaults and branding.
06
Grocery and meal delivery
Turn a plan into a consolidated shopping list, then into a basket in your own commerce flow.
Optional integration
ONE runs standalone.
If you also want activity, sleep and recovery context feeding the nutrition profile, our sister platform WearSightful supplies it — and we integrate other aggregators on request. Neither product requires the other.
Next step
Two ways to evaluate ONE.
Product teams usually start with a demo against a profile that looks like their own users. Engineering teams usually start with the API reference and a sandbox tenant.
FAQ
Frequently asked questions
Clear answers for product and engineering teams evaluating personalised nutrition infrastructure.
What is ONE by OSCA?
ONE by OSCA is personalised nutrition infrastructure for companies building health, fitness, coaching and wellness products. It stores a nutrition profile per user, derives energy and macro targets, generates 1–14 day meal plans that respect allergens and diet type, logs intake, analyses nutrient gaps and suggests substitutions — all through a multi-tenant REST API under your own brand.
What does ONE stand for?
ONE stands for Optimised Nutrition Engine. The product brand is ONE by OSCA; the descriptor is Personalised Nutrition Engine.
Who is ONE for?
Product and engineering teams that need personalised nutrition inside a product they already own — health and digital care platforms, fitness and coaching, weight management, nutrition and food products, corporate wellness, and grocery or meal delivery.
Is ONE just a food or recipe API?
No. A food API answers questions about food: search, nutrient tables, recipe records, barcode lookup. ONE answers questions about a person: what they must never be offered, what their targets are today, which nutrients they are short of, and what to serve instead when they reject a meal. It keeps a persistent profile rather than treating each request as isolated.
How does ONE decide what to put in a plan?
Allergens and diet type are hard constraints that filter the candidate set before scoring. Macro bands, micronutrient floors, cuisine affinity and recent history are then scored, and days are solved together so a fortnight of plans does not repeat itself. Energy and macro targets come from Mifflin–St Jeor unless your product supplies them directly.
Which nutrient reference values does ONE use?
EU NRV, UK RNI and US DV are included, selected per tenant according to market. If you sell into a market we do not ship, you can supply your own reference table and the engine will target that instead.
How does ONE integrate with our product?
As a REST API called from your backend, with OAuth2 client credentials for authentication. Your application stays the user experience; end users never see ONE. Server SDKs for Node, Python, PHP and .NET are available, along with OpenAPI-generated clients covering the full surface.
Can ONE use our own food and recipe data?
Yes. You can author custom foods and recipes through a draft, publish and archive lifecycle, and override entries in the bundled catalog for your own tenants. Catalog contents are scoped per tenant.
How is our customers' data kept separate?
Each of your customers is a separate tenant with its own credentials, catalog and users. Tenant isolation is checked on the request path — a credential scoped to one tenant is rejected when it targets another, rather than having results filtered afterwards. Tenants are pinned to a deployment region.
Does ONE require WearSightful?
No. ONE and WearSightful are independent platforms and neither requires the other. Everything the nutrition engine does works from a profile your product already holds. WearSightful is optional when you also want activity, sleep and recovery context, and we can map an aggregator you already use instead.
Is ONE a consumer app or a medical device?
Neither. It is infrastructure for your product — there is no ONE-branded app your users must adopt. It is not a medical device and does not diagnose conditions, prescribe treatment or provide clinical advice.
Build personalised nutrition into your product.
Talk to the ONE by OSCA team about how personalised nutrition can fit your product roadmap — and how optional wearable data context can extend it when needed.
Product teams book a demo · Engineering teams explore the API and SDKs