Access and tenancy
POST /v1/oauth/token
Exchange client credentials for a bearer token scoped to one tenant.
GET /v1/tenants/me
Resolve the calling tenant's context: branding, region, market and active catalog.
API
A REST API your backend can integrate in an afternoon.
ONE is delivered as an HTTP API with OpenAPI contracts, bearer authentication and predictable retry semantics. Everything the engine does is reachable from it — there is no hidden console where the real work happens.
Getting a plan
Authenticate, describe the person, ask for a plan.
A first integration is three calls. Exchange credentials for a token, upsert the profile you already hold, then request a plan.
# 1. Token, scoped to your tenant
POST /v1/oauth/token
{ "grant_type": "client_credentials",
"client_id": "…", "client_secret": "…" }
# 2. The person you already know about
PUT /v1/admin/tenants/{tenantId}/profiles/{oneUserId}
{
"dietType": "vegetarian",
"allergens": ["peanut"],
"demographics": {
"sex": "female", "age": 34,
"heightCm": 168, "weightKg": 63,
"activityLevel": "moderate"
},
"goal": { "type": "maintain" }
}# 3. Seven days of meals
POST /v1/plans
Authorization: Bearer <token>
X-ONE-Client-Type: partner_s2s
Idempotency-Key: plan-user-42-2026-07-25
{
"oneUserId": "…",
"horizonDays": 7,
"mealTypes": ["breakfast", "lunch", "dinner"],
"microFocus": "iron_rich"
}Plan generation is synchronous. Server-to-server callers must send an Idempotency-Key, so a transport retry replays the original plan instead of quietly generating a second one. Every response carries an X-Request-Id to quote in support.
Surface
The endpoints partners actually integrate against.
An abridged map of the surface. The full OpenAPI document is shared during technical evaluation.
Profiles and rules
PUT /v1/admin/tenants/{tenantId}/profiles/{oneUserId}
Upsert a profile. Energy and macro targets are derived from demographics and goal unless you set them explicitly.
POST /v1/admin/tenants/{tenantId}/rules/resolve
Resolve effective rules for a user and see which layer — request, profile, tenant or platform — decided each one.
GET /v1/reference-standards
List the nutrient reference tables available: EU NRV, UK RNI, US DV and any you have supplied.
GET /v1/micro-focus/presets
Micronutrient focus presets such as iron, folate, bone health and immune support.
Meal planning
POST /v1/plans
Generate 1–14 days of meals for a profile. Requires an idempotency key for server-to-server callers.
POST /v1/plans/{planId}/manipulate
Swap, lock, unlock or regenerate individual slots without rebuilding the whole plan.
GET /v1/plans/{planId}/shopping-list
Aggregate the plan into a consolidated shopping list as JSON, CSV or branded PDF.
Logging and analysis
POST /v1/food-logs
Record intake as a confirmed, partial, replaced or manual entry.
GET /v1/nutrition/daily
Intake for a date against that day's macro and micronutrient targets.
GET /v1/nutrition/deficiency
Per-nutrient intake as a percentage of the reference value, graded adequate to high risk.
GET /v1/analytics/cohorts
Population and cohort rollups across your tenant, exportable as CSV or PDF.
Adaptation
POST /v1/preference-events
Report an accept, reject or swap so affinity scores update for future plans.
POST /v1/substitutions/suggest
Suggest alternatives for an item while holding calories and protein roughly constant.
POST /v1/allergen-intelligence/analyze
Check an ingredient list against a profile's allergens before you show it to anyone.
Catalog
GET /v1/foods/barcode/{barcode}
Resolve a packaged product to a food record with nutrition per portion.
POST /v1/admin/tenants/{tenantId}/recipes
Author tenant recipes through a draft, publish and archive lifecycle.
GET /v1/admin/tenants/{tenantId}/recipes/search
Search the catalog with diet, allergen and preference filters already applied.
Developer experience
Evaluate before you commit.
An interactive playground is available during technical evaluation so your team can validate authentication, planning and catalog flows against a sandbox tenant before writing integration code.
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