On Oura's app and API

[Mar 2025]

This post will largely go over the heads of people not familiar with the Oura ring and app.

TLDR: The Oura ring is a genuinely impressive piece of hardware, with a solid general-purpose app, but there is a significant number of current (and potential future) Oura users looking for additional functionality. Oura’s API should be far more expressive to allow an ecosystem of third-party apps to develop to meet user needs/wants.

Intro: Currently Oura’s business model is to charge customers up front for the ring (~350USD) and charge monthly for the official Oura app (~$7)1. Importantly, the monthly charge also covers access to the API. This means users can’t opt out of the membership fee and build their own dashboards. I think this is totally fair and a good idea, as - in theory - it means that Oura has no need to fear niche apps building on top of user Oura data, as they will still be receiving the monthly fee even if the user stops using the official Oura app.

However, the API today limits the scope of any apps building on top of Oura data. At a high-level, the API only allows the reading of daily values and heart rate timeseries data2. It is not possible for 3rd party apps to:

The restrictions noted above make a lot of cool features impossible via the API.

What cool feautures?

Experimentation: The current experiment feature in the Oura app only hosts a single caffeine experiment, where users can test how adjusting their caffeine intake timing affects sleep. I presume they will eventually roll out other experiments but to me this is not the right UX approach. An experiment should simply be the setup and notification workflow for the given variable(s), with a statistical analysis of the important metrics after the fact. The user simply sets their variable(s) and length of experiment, and at the end of each day they are notified to input the relevant tag(s). After a reasonable sample size, the Oura app reviews their sleep/readiness/performance against the measured variable(s). Note that this would require custom tags to be analysable, as currently all custom tags simply enter a blackhole.

Performance: The Oura app currently takes sleep/readiness scores as ends in themselves, making no attempt to retrieve performance surveys from users. Estimating performance via end of day survey questions would allow performance-based experiments, for example seeing if late in the day caffeine leads to more productive workdays. Estimating performance would also open up the possibility of tailoring sleep/readiness scores to an individual, giving users more relevant feedback on when a sleep score like last nights is bad enough to affect performance, for example.

Data delay: Many users self-report being psyched out by poor sleep/readiness numbers, and an obvious feature is to delay seeing last nights values until end of day or later. This of course could be tested as an experiment in the app, with users reporting perceived readiness and performance with the feature turned on and off.

Custom algos: There are several possible user segments that would get value out of different sleep/readiness algos. The simplest user segment is those where the latency estimation fails. Latency stands out as the sleep contributor most prone to error7, and it makes sense to ignore this contributor for many. Another random example is for athletes that care about maximising deep and total sleep and tracking their performance impact. As mentioned, if you commit to tracking performance it makes sense to tune sleep/readiness to performance.

Sleep cycle morning alarm: Use the live sleep cycle data to wake users after a full sleep cycle and not when they are in deep/REM sleep.

Cognitive engagement tracking: The world probably doesn’t need any more productivity apps, but, I think people would use a cognitive engagement or ‘deep work’ tool that tracks Oura’s daytime stress estimate and calls out when a user moves out of the ‘engaged’ zone. This feature could quickly be created by adding a ‘cognitive work’ session and could be an entry into surveying cognitive performance via an end of session survey.

Time to REM: Time to REM8, pre-sleep RHR, and sleep debt are obvious examples. Sleep debt is a concept that Oura have deprioritised as it’s a measurement that can enforce poor sleep hygiene, and it’s a good example of a feature that has real demand that Oura is unwilling to meet.

Why would Oura be hesitant to add these features? Because they put off the average user. A lot of the features listed above require pushing the user with notifications, so its only a “power user” subset that will opt in, and developing features for various subsets of Oura ring owners leads to feature bloat and requires developer time for features that are only desired by a subset of all Oura ring owners. Another reason is that a lot of the suggested features are more opiniated on what “good” is, and understandably Oura tries to stick closely to what the evidence suggests for a mass population. However - by definition - this cookie cutter approach means the overall UX lacks specificity and personalisation.

The solution is for Oura to welcome niche third-party apps and empower them by expanding the API’s functionality. This has the effect of outsourcing feature development to the free market, as Oura can simply adopt any features they like, and regardless, all Oura ecosystem apps still have users buying the ring and paying for the API access9.

Footnotes:

1 Technically you can still use the app without the monthly membership, but it is not full featured.

2 API docs here.

3 A tag is just a string with a datetime, that can be retrieved later for analysis.

4 Daytime stress is one of the most misunderstood metrics, if the Oura reddit is anything to go by. It requires you to be stationary to discern HR and temp increases from exercise/movement, and in general Oura users are unaware that is an estimation rather than an accurate reading.

5 A session is simply a period started and ended by the user that tracks HR and HRV. This means allowing 3rd party apps to create sessions allows HRV data to be gettable.

6 I’m uncertain about this. Its possible that the data required to recreate the restfulness score is available, but the algo is not obvious, see this for my attempt to work out the Oura sleep algo.

7 My take on Oura metric reliability order: HR > HRV > Temp > Sleep zones > Movement binary > Daily stress > VO2max > Steps > Sleep latency > Movement type detection > Calorie burn estimation.

8 doi: 10.1002/alz.14495

9 What about the compute cost? All these ongoing API calls from third-party apps will cost Oura a lot, no? Yes, but simply charge them for it. What about liability? What if some dodgy app creates a ridiculous sleep score recommending <2hr of sleep a night? The existing API agreement covers this and is standard stuff. Third-party use is the responsibility of the third party, not Oura.