01
Profiles that persist
A profile is a stored record, not a request payload. Demographics, goal, allergens, diet type, dislikes and preferred cuisines stay put, so the tenth plan knows more than the first.
Platform
Nutrition infrastructure that sits behind your product.
ONE is a backend service. Your application keeps the user, the interface and the relationship; ONE answers the nutrition questions your product cannot answer on its own.
Architecture
Where ONE sits in your stack.
Your services call ONE over HTTPS with a tenant-scoped token. Nothing in the diagram below is exposed to your end users.
Your product
Mobile app
Web portal
Coach dashboard
Your backend
ONE — tenant boundary
Profiles & rules
Requirements, allergens, precedence
Planner
1–14 day plans, swap, lock, regenerate
Logging & analysis
Intake, deficiency, insights
Catalog & search
Recipes, custom foods, barcode
Bundled food catalog
Foods and recipes with per-portion nutrition
Your catalog
Custom foods and recipes, scoped to your tenant
Reference standards
EU NRV · UK RNI · US DV · your own table
Webhooks → your backendUsage meteringRequest IDs for support
Core principles
Four decisions that shape the platform.
These are the choices that separate a nutrition platform from a food lookup service, and they are worth checking against whatever else you are evaluating.
02
Safety separated from preference
Allergens and diet type are hard constraints that filter candidates outright. Dislikes and cuisines are scored, so a plan degrades gracefully instead of returning nothing.
03
One deployment, many customers
Each of your customers is a tenant with its own keys, catalog overrides, default rules, branding and nutrient reference standard.
04
Explainable by design
Rule resolution reports which layer set each value, so your support team can answer why a meal did or did not appear.
Lifecycle
From a new user to a better plan next month.
Adopt the full loop or only the stage you are missing. Each one stands alone.
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.
What stays yours
The boundary is deliberate.
ONE is priced and built as infrastructure. It has no consumer product, so it has no reason to compete with you for the customer relationship.
Your interface
End users never see ONE. There is no ONE-branded screen, login or app that your customers have to adopt.
Your configuration
Default rules, supported diets, allergen lists, catalog contents and reference standard are set per tenant by you.
Your operations
Webhooks push events to your backend, usage metering reports what you consumed, and request IDs tie a user complaint to a specific call.
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