Skip to content

Overview

Overview

The Oura API allows Oura users and partner applications to improve their user experience with Oura data. This document describes the Oura API Version 2 (V2), which is the only available integration point for Oura data. The previous V1 API has been sunset.

Data Access

In order to access data, a registered API Application is required. API Applications are limited to 10 users before requiring approval from Oura. There is no limit once an application is approved. Additionally, Oura users must provide consent to share each data type an API Application has access to. All data access requests through the Oura API require Authentication. Additionally, we recommend that Oura users keep their mobile app updated to support API access for the latest data types.

Authentication

The Oura Cloud API supports authentication through the industry-standard OAuth2 protocol. For more information, see our Authentication instructions. Access tokens must be included in the request header as follows:

GET /v2/usercollection/personal_info HTTP/1.1
Host: api.ouraring.com
Authorization: Bearer <token>

Please note that personal access tokens were deprecated in December 2025 and are no longer available for use.

Oura HTTP Response Codes

Response Code Description
200 OK Successful Response
400 Query Parameter Validation Error The request contains query parameters that are invalid or incorrectly formatted.
401 Unauthorized Invalid or expired authentication token.
403 Forbidden The requested resource requires additional permissions or the user’s Oura subscription has expired.
429 Too Many Requests Rate limit exceeded. See response headers for retry guidance.

Rate Limits

The API enforces rate limits at two layers to ensure fair access across all applications:

  • a per-access-token limit, which throttles single-token floods, and
  • a per-application limit, which caps the aggregate traffic across all of an application’s end-user tokens so one fan-out app can’t dominate shared capacity.

A request that trips either layer receives a 429 Too Many Requests. The X-RateLimit-Tier response header identifies which layer fired.

If your application regularly approaches rate limits, webhooks are strongly recommended — most applications that implement webhooks correctly do not encounter rate limit issues.

Contact us if you expect your usage to require higher limits.

Rate Limit Response Headers

When a 429 Too Many Requests response is returned, five headers are included to guide retries. Prefer these over fixed-interval backoff:

  • Retry-After — integer seconds to wait before retrying. RFC 7231-compliant; safe to feed directly into your client’s backoff logic.
  • X-RateLimit-Limit — the request ceiling for the current window.
  • X-RateLimit-Window — the rolling window length in seconds that the ceiling applies to.
  • X-RateLimit-Reset — Unix epoch (seconds) at which the window resets and quota is fully restored.
  • X-RateLimit-Tier — identifies which limit was exceeded, useful when contacting support.

Security scheme type: http

Security scheme type: oauth2

Flow type: authorizationCode

Authorization URL: https://cloud.ouraring.com/oauth/authorize

Token URL: https://api.ouraring.com/oauth/token

Scopes:

  • email - Email address of the user
  • personal - Personal information (gender, age, height, weight)
  • daily - Daily summaries of sleep, activity and readiness
  • heartrate - Time series heart rate for Gen 3 users
  • workout - Summaries for auto-detected and user entered workouts
  • tag - User entered tags
  • session - Guided and unguided sessions in the Oura app
  • spo2Daily - SpO2 Average recorded during sleep

Client ID for webhook subscription endpoints. Must be used together with x-client-secret header.

Security scheme type: apiKey

Header parameter name: x-client-id

Client Secret for webhook subscription endpoints. Must be used together with x-client-id header.

Security scheme type: apiKey

Header parameter name: x-client-secret