Oura’s API provides access to sleep, readiness, activity and other wearable data. For teams building AI health applications, that creates an immediate product question: which parts of the application can use those records?
Oura’s agreement, effective June 8, 2026, explicitly restricts AI processing, downstream access and monetization. A working API connection does not establish permission to feed the resulting data into a model. Oura’s current agreement
The provisions most relevant to AI applications are:
| Intended use | What Oura’s public terms say |
|---|---|
| Sending API data into an AI assistant | Section 4(d) prohibits using API data to prompt, evaluate or otherwise supply AI models or platforms. |
| Training models or creating embeddings | Section 4(a) lists training, fine-tuning, evaluation datasets and embeddings among uses requiring prior written consent. |
| Charging users for connected functionality | Section 4(a)(xiii) requires prior written consent for charging users for functionality related to the API or Oura platform. |
| Receiving data through an aggregator | Section 3(e) requires prior approval and separate API registrations or credentials for each end customer. |
| Forwarding aggregated data to AI systems | Section 2(c) prohibits aggregators from supplying Oura data, including derived data, to AI systems. |
User consent does not override prohibited uses. Separate written agreements can establish additional aggregator permissions. Oura agreement, sections 2–4
These distinctions matter when describing a product. “Personalized coaching” could mean displaying recorded measurements, producing a model-generated explanation, or training a prediction model across users. A useful integration brief should describe the actual processing: the inputs, where they go, what gets retained and how the feature is sold.
For example, a proposed sleep assistant could specify that it sends seven nights of sleep measurements to a hosted model, generates a morning explanation and includes that feature in a monthly subscription. That description gives everyone evaluating the integration something concrete to assess.
The technical access process starts with OAuth2. Oura API V2 supports categories including sleep, readiness, activity, heart rate and workouts, with users authorizing access to specific data types. Applications are limited to ten users before requiring Oura approval. Personal access tokens were deprecated in December 2025 and are no longer available for use. Oura API documentation
Oura now directs new applications to its developer portal, while its previous portal remains available for editing existing applications. Gen3 and newer users need an active Oura Membership for API access, including access through partner integrations. Oura’s access requirements
Oura’s technical documentation describes API access as free for personal and commercial applications. That pricing statement should be read alongside the commercial-use restrictions above. The agreement also reserves the possibility of future API fees with notice. API documentation, agreement, section 3(h)
Terra provides the infrastructure for connecting Oura accounts, handling authentication and delivering standardized data to your application. Its Oura integration uses the backend Health & Fitness API and is listed as event-driven. Terra’s supported integrations, integration overview
Once the permissions for your project are established, the connection process is straightforward:
- Enable Oura in Terra. Open Connections → Add New, select Oura and activate it. Configure the destination where your application will receive data. Source setup
- Create an authentication session. From your backend, call
POST https://api.tryterra.co/v2/auth/generateWidgetSessionwith your Terra credentials. Setprovidersto"OURA"and usereference_idfor your application’s internal user identifier. Endpoint reference - Let the user connect their account. Open the returned widget URL. The user signs in to Oura and completes authorization. Your API credentials remain on your backend. Widget implementation
- Receive and inspect the data. Terra manages token refreshes and sends available updates to your configured destination. Historical requests can populate earlier records where available. Inspect delivered events in Terra Dashboard → Payload History. Receiving data updates
Data freshness also deserves attention in an AI product. Oura’s sleep and readiness data depend on the user opening the app and syncing their ring. An assistant answering a morning question should check the measurement dates and handle missing records explicitly. Oura’s synchronization guidance
Start with one connected account and one clearly defined feature. Verify the connection, inspect the available fields and timestamps, and test how the application behaves when a night’s data is missing. That gives the product team a concrete integration to evaluate before expanding its scope.
