> ## Documentation Index > Fetch the complete documentation index at: https://developers.soxai.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Fetch intra-day detail data for a whole organization or company (v2) > Fetch intra-day detail records (`SX_Detail_Prod`) with standardized field names for every reachable member of an organization or a company. **Parameters** - `company_id` / `org_id` (query) - the scope to answer for. At least one is required; which of them a caller may name depends on its role, described below. - `start_day` / `end_day` (query, optional) - `YYYY-MM-DD`, both inclusive. An ISO 8601 value with an explicit time is also accepted; a time-valued `end_day` remains the exclusive end instant. The range must not exceed 31 days. - `uid_list` (query, optional) - restrict the answer to these members, at most 100. They must all be inside the resolved scope. - `page` (query, optional, default `0`) - 0-indexed page of 100 members, used when `uid_list` is not given. - `format` (query, optional) - `json` (default) or `csv`. **Response** - `200` with `format=json` returns an array of intra-day records across the users the request resolves to. - `200` with `format=csv` returns the same rows as a file download. - A request that resolves to no rows is still a `200`, carrying `msg: No data found`. **Errors** | Status | Condition | | --- | --- | | 400 | `start_day` or `end_day` is neither `YYYY-MM-DD` nor an ISO 8601 datetime, `end_day` is earlier than `start_day`, the range is longer than the number of users allows, or none of `company_id`, `org_id` and `uid_list` was given | | 404 | The `company_id` or `org_id` names nothing that exists | **Authorization** - Scheme: `Authorization: Bearer ` or `soxai-api-key: `. - `Admin`, `PartnerAdmin` or `OrgAdmin`. Which scope applies is decided by the arguments, so this endpoint resolves a set of readable uids rather than answering a single yes or no. - `Admin` must name a `company_id` or an `org_id` and reaches either. `PartnerAdmin` reaches its own company, and an `org_id` it names only narrows that company. `OrgAdmin` reaches only its own organization and is refused a `company_id`. - A caller holding both `PartnerAdmin` and `OrgAdmin` is confined to the intersection of the two. - Existence is checked **after** authorization, so a scoped caller is told "not yours" before it can learn whether a company or organization exists. **Response fields** **SX_Detail_Prod (v2 output)** | Field | Unit | Description | | --- | --- | --- | | `_time` | datetime | Time: Data timestamp | | `uid` | string | User ID: User identifier | | `API_ver` | string | API Version: API version in effect at the time of the record | | `fw_ver` | string | Firmware Version: Raw FW_version aligned onto the detail time series | | `activity_zcm` | | Activity - Zero Crossing Count: Raw zc field. Unit and value details are not documented in the schema list | | `activity_pim` | | Activity - Activity Amount: Raw acti field. Unit and value details are not documented in the schema list | | `activity_jerk` | | Activity - Jerk: Listed as an output column, but nothing in the repository writes it, so it does not appear in the response | | `activity_mets` | METs | Activity - METs: Physical activity intensity in multiples of the resting metabolic rate | | `activity_sleep_awake` | | Activity - Sleep or Awake: Raw sleep_f field. Unit and value details are not documented in the schema list | | `activity_calorie` | kcal | Activity - Calories Burned: Calories burned | | `activity_steps` | count | Activity - Steps: Number of steps | | `activity_confirm` | flag | Activity - Confirmation Flag: Data confirmation flag (1: confirmed, 0: unconfirmed) | | `activity_type` | category | Activity - Type: Activity type (0: resting, 1: walking, 2: running, 3: other, 9: unknown) | | `activity_strength` | ratio | Activity - Intensity: Index of activity intensity | | `activity_act_mlc` | category | Activity - Edge Processing Data: Edge processing data (act_mlc) | | `health_T` | °C | Health - Skin Temperature: Skin temperature | | `health_cbt` | °C | Health - Core Body Temperature: Always null. Core body temperature is not yet stored in the database | | `health_hr` | bpm | Health - Heart Rate: Average heart rate | | `health_hrv` | ms | Health - Heart Rate Variability: Heart rate variability (RMSSD) | | `health_lf` | | Health - LF: Raw LF field, the low frequency component of heart rate variability. Unit and value details are not documented in the schema list | | `health_hf` | | Health - HF: health_lf divided by the raw lf_hf ratio; null where lf_hf is 0. Unit and value details are not documented in the schema list | | `health_spo2` | % | Health - Blood Oxygen Saturation: Blood oxygen saturation | | `health_stress` | pt | Health - Stress Level: Stress level | | `health_hr_dB` | | Health - Heart Rate Signal Level: Raw HR_dB field. Unit and value details are not documented in the schema list | | `sleep_hr` | bpm | Sleep - Heart Rate: Heart rate during sleep | | `sleep_hrv` | ms | Sleep - Heart Rate Variability: Heart rate variability during sleep (RMSSD) | | `sleep_spo2` | % | Sleep - SpO2: health_spo2 restricted to epochs that are asleep and not awake; null on every other row | | `sleep_stage` | category | Sleep - Stage (4 Categories): Sleep stage (0: deep sleep, 1: light sleep, 2: REM, 3: awake or undetermined) | | `sleep_stage_1min` | category | Sleep - 1-Minute Stage (4 Categories): Sleep stage for each minute, one digit per minute joined into an integer (0: deep sleep, 1: light sleep, 2: REM, 3: awake or undetermined) | | `sleep_odi` | index | Sleep - ODI: 3% oxygen desaturation index (ODI) | | `sleep_respiration` | breath/min | Sleep - Respiratory Rate: Respiratory rate | | `utc_offset_mins` | mins | UTC Offset: Time difference from UTC in minutes | ## OpenAPI ````yaml /openapi-sandbox.json get /api/v2/DailyDetailDataForOrg openapi: 3.1.0 info: title: SOXAI API description: > ## SOXAI API helps you get data stored in SOXAI database. Every endpoint below documents its own parameters, responses and authorization rule. ## How to use 1. All data-related endpoints need you to sign in first. Use the account you registered in the SOXAI app. 2. You can get a Bearer token and localID like this: ``` { "kind": "identitytoolkit#VerifyPasswordResponse", "registered": true, "localId": "[YOUR UID]", "email": "[YOUR EMAIL]", "idToken": "[YOUR BEARER TOKEN]", "refreshToken": [YOUR Refresh TOKEN]" } ``` use this `idToken` to fill it into the value field after you click **Authorize** button, or attach it to header in your request. For more info, search for "Bearer token". (ps. the difference between idToken and refreshToken: idToken will expire in 1 hour, refreshToken will expire in one month, you can use refreshToken to get new idToken when idToken expired.) 3. All users can access to his/her personal data with `localId` as user's uid. 4. If you are an organization admin, contact SOXAI first to create an organization. 5. After the organization is created, you can invite other users to join it. They receive an email to accept the invitation. 6. As an organization user, you can read your own data, plus the roster and profiles of your organization. Other members' measurement data is not yours to read - that is what an organization admin does. See "Who can read whose data" below. ## Quick start note for personal user 1. (Only once) Access `/api/login` to get your uid and OAuthToken by api, please memo OAuthToken, you can use it to access api without login again. 2. Access `/api/v2/DailyInfoData/{query_uid}` for day-level scores, or `/api/v2/DailyDetailData/{query_uid}` for the finer series. Both take a date range and return JSON, or a csv download when `format` is `csv`. 3. The v1 forms `/api/RawData/{query_uid}`, `/api/DailyInfoData/{query_uid}` and `/api/DailyDetailData/{query_uid}` return the same measurements under the raw database field names. Prefer the `/api/v2/` endpoints for a new integration. ## Quick start note for organization user 1. You will receive an email to accept the invitation from your organization admin. After you accept it, your data is shared with that admin. 2. If you want to query your own data, you can refer to the note for personal user. 3. You can query other orguser's info(email, uid, etc) after obtain your org_id from `/api/myOrg` and access `/api/orgs/{org_id}/orgUsers` ## Quick start note for organization admin 1. Contact SOXAI (info@soxai.co.jp) to create an organization for you. 2. Access `/api/login` to get your uid and OAuthToken by api. 3. Access `/api/myOrg` to get your organization id. 4. Access `/api/orgs/{org_id}/orgUsers` to create, read, update and delete organization users. When you post a new user, they receive an email to accept the invitation. 5. Access `/api/v2/DailyInfoDataForOrg` or `/api/v2/DailyDetailDataForOrg` to read your organization's members in one request. **You reach the SOXAI app data of the users who have agreed to share it**, and the endpoint narrows the answer to that set for you. ## Authentication and errors common to every endpoint Unless an endpoint says otherwise, it requires `Authorization: Bearer ` and answers: | Status | Condition | | --- | --- | | 401 | The `Authorization` header is missing, or the token is invalid or expired | | 403 | The caller is authenticated but not allowed to make this request. Each endpoint's **Authorization** block lists the bodies it uses | | 422 | The request did not match the schema. An **authorized** caller sees this instead of a 403; an unauthorized caller is refused before its body is read | | 429 | The rate limit was exceeded. Wait for `Retry-After` seconds before retrying | | 500 | Unexpected server-side failure | Each endpoint documents only the statuses that are specific to it. The **Authorization** block is the last section of every endpoint's description. For the endpoints that declare their rule on the route it is generated from that declaration, so it cannot disagree with what is enforced. ### The second credential `soxai-api-key: ` is accepted wherever `Authorization: Bearer ` is. The difference is lifetime and who issues it: an ID token expires in an hour and you mint it yourself from `POST /api/login`, while an API key is long-lived and read back from `GET /api-key/secret`. A request carries one or the other, not both. Server-to-server integrations should hold the key; anything acting on behalf of a signed-in person should hold the token, so that revoking the person's access is enough to stop it. ### Who can read whose data Which role you hold decides how far past your own uid you can read. A role is a claim on your credential, not something you pass as a parameter. | Role | Reaches | | --- | --- | | (none) | Only your own uid. Every user has this much | | `OrgUser` | Your own uid, plus your organization's roster and member profiles (email, uid, profile) - not other members' measurement data | | `OrgAdmin` | Every member of your own organization, including their measurement data | | `PartnerAdmin` | Every organization owned by your own company, and every member of those organizations | | `Admin` | Every user, with no company or organization scoping. Held by SOXAI only | One consequence catches integrators out: the roster an admin reaches is the whole roster, not only its active part. A membership's `status` records where a member stands in the invitation lifecycle; it does not by itself narrow what an admin can read. Do not infer a member's data scope from their `status` - read the endpoint's **Authorization** block, which states the rule that is actually enforced. ### v1 and v2 The data endpoints come in two generations. `/api/v2/...` returns standardized field names and is the interface to build against. The v1 endpoints (`/api/RawData`, `/api/DailyInfoData`, `/api/DailyDetailData`) return the raw database field names, which change when the database does. They are not deprecated and they are not going away without notice, but they will not gain fields that v2 has; a new integration should use v2. contact: name: SOXAI url: https://www.soxai.co.jp/contact email: info@soxai.co.jp version: 1.0.0 servers: - url: https://web-api.dev.soxai.site description: Sandbox security: [] tags: - name: Authentication description: >- Obtain and hold the credential every other endpoint asks for. `POST /api/login` returns the `idToken` you send as `Authorization: Bearer ` and the `refreshToken` that renews it; the password reset pair is here because a caller who has lost their password cannot hold a token either. `/app/me` reports what the credential you are holding actually carries, which is the first thing to check when an endpoint answers 403. The long-lived alternative to an ID token is under `API Keys`. - name: API Keys description: >- Issue and read back the caller's own long-lived API key, which is accepted as `soxai-api-key: ` wherever an ID token is. A caller holds one key at a time and reads it back rather than being shown it once. Hold a key for a server-to-server integration, where there is no signed-in person whose session could expire; hold an ID token from `Authentication` for anything acting on a person's behalf, so that revoking the person's access is enough to stop it. - name: Data (v2) description: >- Read measurement data with standardized field names. One endpoint per data shape for a single user (`DailyInfoData`, `DailyDetailData`, `DailyTrendData`) and the bulk forms for a whole organization or company (`...ForOrg`). This is the interface to build against. - name: Data (v1) description: >- Read measurement data with the raw database field names, one user at a time, as CSV or JSON. These endpoints are not deprecated and will not disappear without notice, but the names they return are the ones the database uses and change when it does, and they will not gain the fields `Data (v2)` has. **A new integration should use `Data (v2)`.** - name: Sync Status description: >- Whether a user's ring data arrived, rather than what it says. `ProcessLog/{query_uid}` returns one user's sync history and `LastProcessLog` the most recent entry. Read these before concluding that a missing day is missing rather than not yet uploaded - the data endpoints answer with what was received and cannot tell the two apart. - name: Organizations description: >- Create and manage organizations. An organization owns a member roster and is the unit every org-scoped endpoint addresses. A `PartnerAdmin` sees only the organizations its own company owns. - name: Organization Members description: >- Manage an organization's member roster: enrol members, invite them, edit their teams and admin flag, and remove them. A member reaches these endpoints only for the organization their own token names. `AcceptEmailVerification` is the other end of that flow - the link in the invitation email, which the invited user opens without being signed in. - name: Family Groups description: >- Small self-service groups where members choose, per metric, what they share with each other. Authority here comes from the caller's membership record and its `admin` / `member` role **inside the group** - a SOXAI `Admin`, `PartnerAdmin` or `OrgAdmin` claim grants nothing. `GroupView` is the single endpoint that returns members' health data. - name: Partner Companies description: >- Partner companies register and sign in **their own** users with certificates rather than through the SOXAI app. These are the endpoints the partner's own backend calls, authenticating with a signed certificate instead of a SOXAI token. The certificate itself is issued and revoked by SOXAI rather than through this API; contact SOXAI to obtain one. - name: Deep Links description: >- Deep links that carry a one-time token into the SOXAI app: group invitations, and sign-up links that prefill an email address. The token is the credential, so the endpoints that exchange one need no signed-in caller. - name: OAuth2 description: >- Sign a SOXAI user in to your own application with the OAuth2 authorization code flow. Your code reaches four of these: the discovery document your OIDC library reads, the URL you send the user's browser to, the token endpoint your backend calls with the authorization code, and the record of what the user consented to. The screens in between - the login form, the consent page and the two-factor prompts - are SOXAI's own pages, posted to by the browser, and your application never calls them. The remaining endpoint sets whether two-factor is required for a list of users, which an `OrgAdmin` or `PartnerAdmin` does for its own members. - name: Users description: >- Endpoints keyed on a user rather than on an organization: ring serial number lookup, and the caller's own ring sync history. - name: System description: >- Liveness and health checks for monitoring. `ping` answers from the process alone; `health` probes Firestore and both InfluxDB clients and answers `500` when one of them is unreachable; `health_check` reports the same dependencies one by one inside a `200`. None of these require authentication, and none of them read or write a user's data. paths: /api/v2/DailyDetailDataForOrg: get: tags: - Data (v2) summary: Fetch intra-day detail data for a whole organization or company (v2) description: >- Fetch intra-day detail records (`SX_Detail_Prod`) with standardized field names for every reachable member of an organization or a company. **Parameters** - `company_id` / `org_id` (query) - the scope to answer for. At least one is required; which of them a caller may name depends on its role, described below. - `start_day` / `end_day` (query, optional) - `YYYY-MM-DD`, both inclusive. An ISO 8601 value with an explicit time is also accepted; a time-valued `end_day` remains the exclusive end instant. The range must not exceed 31 days. - `uid_list` (query, optional) - restrict the answer to these members, at most 100. They must all be inside the resolved scope. - `page` (query, optional, default `0`) - 0-indexed page of 100 members, used when `uid_list` is not given. - `format` (query, optional) - `json` (default) or `csv`. **Response** - `200` with `format=json` returns an array of intra-day records across the users the request resolves to. - `200` with `format=csv` returns the same rows as a file download. - A request that resolves to no rows is still a `200`, carrying `msg: No data found`. **Errors** | Status | Condition | | --- | --- | | 400 | `start_day` or `end_day` is neither `YYYY-MM-DD` nor an ISO 8601 datetime, `end_day` is earlier than `start_day`, the range is longer than the number of users allows, or none of `company_id`, `org_id` and `uid_list` was given | | 404 | The `company_id` or `org_id` names nothing that exists | **Authorization** - Scheme: `Authorization: Bearer ` or `soxai-api-key: `. - `Admin`, `PartnerAdmin` or `OrgAdmin`. Which scope applies is decided by the arguments, so this endpoint resolves a set of readable uids rather than answering a single yes or no. - `Admin` must name a `company_id` or an `org_id` and reaches either. `PartnerAdmin` reaches its own company, and an `org_id` it names only narrows that company. `OrgAdmin` reaches only its own organization and is refused a `company_id`. - A caller holding both `PartnerAdmin` and `OrgAdmin` is confined to the intersection of the two. - Existence is checked **after** authorization, so a scoped caller is told "not yours" before it can learn whether a company or organization exists. **Response fields** **SX_Detail_Prod (v2 output)** | Field | Unit | Description | | --- | --- | --- | | `_time` | datetime | Time: Data timestamp | | `uid` | string | User ID: User identifier | | `API_ver` | string | API Version: API version in effect at the time of the record | | `fw_ver` | string | Firmware Version: Raw FW_version aligned onto the detail time series | | `activity_zcm` | | Activity - Zero Crossing Count: Raw zc field. Unit and value details are not documented in the schema list | | `activity_pim` | | Activity - Activity Amount: Raw acti field. Unit and value details are not documented in the schema list | | `activity_jerk` | | Activity - Jerk: Listed as an output column, but nothing in the repository writes it, so it does not appear in the response | | `activity_mets` | METs | Activity - METs: Physical activity intensity in multiples of the resting metabolic rate | | `activity_sleep_awake` | | Activity - Sleep or Awake: Raw sleep_f field. Unit and value details are not documented in the schema list | | `activity_calorie` | kcal | Activity - Calories Burned: Calories burned | | `activity_steps` | count | Activity - Steps: Number of steps | | `activity_confirm` | flag | Activity - Confirmation Flag: Data confirmation flag (1: confirmed, 0: unconfirmed) | | `activity_type` | category | Activity - Type: Activity type (0: resting, 1: walking, 2: running, 3: other, 9: unknown) | | `activity_strength` | ratio | Activity - Intensity: Index of activity intensity | | `activity_act_mlc` | category | Activity - Edge Processing Data: Edge processing data (act_mlc) | | `health_T` | °C | Health - Skin Temperature: Skin temperature | | `health_cbt` | °C | Health - Core Body Temperature: Always null. Core body temperature is not yet stored in the database | | `health_hr` | bpm | Health - Heart Rate: Average heart rate | | `health_hrv` | ms | Health - Heart Rate Variability: Heart rate variability (RMSSD) | | `health_lf` | | Health - LF: Raw LF field, the low frequency component of heart rate variability. Unit and value details are not documented in the schema list | | `health_hf` | | Health - HF: health_lf divided by the raw lf_hf ratio; null where lf_hf is 0. Unit and value details are not documented in the schema list | | `health_spo2` | % | Health - Blood Oxygen Saturation: Blood oxygen saturation | | `health_stress` | pt | Health - Stress Level: Stress level | | `health_hr_dB` | | Health - Heart Rate Signal Level: Raw HR_dB field. Unit and value details are not documented in the schema list | | `sleep_hr` | bpm | Sleep - Heart Rate: Heart rate during sleep | | `sleep_hrv` | ms | Sleep - Heart Rate Variability: Heart rate variability during sleep (RMSSD) | | `sleep_spo2` | % | Sleep - SpO2: health_spo2 restricted to epochs that are asleep and not awake; null on every other row | | `sleep_stage` | category | Sleep - Stage (4 Categories): Sleep stage (0: deep sleep, 1: light sleep, 2: REM, 3: awake or undetermined) | | `sleep_stage_1min` | category | Sleep - 1-Minute Stage (4 Categories): Sleep stage for each minute, one digit per minute joined into an integer (0: deep sleep, 1: light sleep, 2: REM, 3: awake or undetermined) | | `sleep_odi` | index | Sleep - ODI: 3% oxygen desaturation index (ODI) | | `sleep_respiration` | breath/min | Sleep - Respiratory Rate: Respiratory rate | | `utc_offset_mins` | mins | UTC Offset: Time difference from UTC in minutes | operationId: get_daily_detail_data_by_org_or_company_v2 parameters: - description: >- Company ID to filter data. Accepted from an admin, and from a PartnerAdmin naming its own company. An OrgAdmin is refused with 403. required: false schema: type: string title: Company Id description: >- Company ID to filter data. Accepted from an admin, and from a PartnerAdmin naming its own company. An OrgAdmin is refused with 403. examples: - company123 name: company_id in: query - description: >- Org ID to filter data. Accepted from an admin, from a PartnerAdmin naming an org its company owns, and from an OrgAdmin naming its own org. required: false schema: type: string title: Org Id description: >- Org ID to filter data. Accepted from an admin, from a PartnerAdmin naming an org its company owns, and from an OrgAdmin naming its own org. examples: - org123 name: org_id in: query - description: >- Start date in YYYY-MM-DD format (e.g., 2025-01-01T00:00:00+09:00). Range of start_day and end_day should not exceed 31 days. required: false schema: type: string title: Start Day description: >- Start date in YYYY-MM-DD format (e.g., 2025-01-01T00:00:00+09:00). Range of start_day and end_day should not exceed 31 days. examples: - '2025-01-01T00:00:00+09:00' name: start_day in: query - description: >- End date in YYYY-MM-DD format (inclusive), or a datetime that is the exclusive end instant (e.g., 2025-02-01T00:00:00+09:00 to read through 2025-01-31 JST). Range of start_day and end_day should not exceed 31 days. required: false schema: type: string title: End Day description: >- End date in YYYY-MM-DD format (inclusive), or a datetime that is the exclusive end instant (e.g., 2025-02-01T00:00:00+09:00 to read through 2025-01-31 JST). Range of start_day and end_day should not exceed 31 days. examples: - '2025-02-01T00:00:00+09:00' name: end_day in: query - description: >- `json` (default) returns the records inline; `csv` returns a file download. required: false schema: type: string enum: - csv - json title: Format description: >- `json` (default) returns the records inline; `csv` returns a file download. default: json examples: - json name: format in: query - description: >- Optional list of user IDs to filter. Must all belong to the org. Max 100 UIDs. required: false schema: items: type: string type: array title: Uid List description: >- Optional list of user IDs to filter. Must all belong to the org. Max 100 UIDs. examples: - - user123 - user456 name: uid_list in: query - description: >- 0-indexed page number when org has more than 100 users and uid_list is not provided. required: false schema: type: integer minimum: 0 title: Page description: >- 0-indexed page number when org has more than 100 users and uid_list is not provided. default: 0 examples: - 0 name: page in: query responses: '200': description: >- Daily detail data fetched successfully with renamed fields. A json request answers with an array, wrapped in pagination / data keys when the org needs more than one page; when nothing matches, the body is the No data found message. format=csv answers with a file download. Pagination counts eligible users, not measurement records. `pagination` contains `total_users`, `total_pages`, `current_page` (zero-based), and `page_size` (100 users). For example, with 105 eligible users in total, `page=1` selects the second page (the remaining 5 users) and produces metadata `{"total_users":105,"total_pages":2,"current_page":1,"page_size":100}`. Request another page while `current_page + 1 < total_pages`, regardless of record count. A non-empty `uid_list` disables pagination. A page without measurements can return `{"msg":"No data found"}` without metadata, even if more pages exist. Use a previously obtained total_pages or explicit uid_list batches; this message alone cannot determine the final page. An out-of-range page returns metadata and `data: []`. headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: {} example: - _time: '2025-02-21T08:00:00+00:00' uid: user123 API_ver: 2.0.0 fw_ver: 1022 health_hr: 72 health_hrv: 45 health_spo2: 98 health_stress: 25 health_T: 33.5 health_lf: 120.5 health_hf: 250.3 sleep_hr: 58 sleep_hrv: 52 sleep_spo2: 97 sleep_stage: 1 sleep_odi: 2 sleep_respiration: 14 activity_steps: 150 activity_calorie: 12 activity_zcm: 128 activity_pim: 256 activity_sleep_awake: 5 application/octet-stream: schema: type: string format: binary '400': description: >- Bad Request - start_day / end_day cannot be parsed, the range is inverted, or it is longer than the endpoint allows headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: bad-request error_msg: The range of start_day and end_day should not exceed 31 days. '401': description: Unauthorized - the credentials are missing, expired or invalid headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: http-error error_msg: Invalid authentication credentials. '403': description: Forbidden - Not enough permission headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: forbidden error_msg: Not enough permission '404': description: Not Found - the org or the company named does not exist headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: not-found error_msg: Org '' not found '422': description: >- Unprocessable Entity - a request field does not meet the endpoint's validation rules content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: unprocessable-entity error_msg: 'body.: ' '429': description: Too Many Requests - the rate limit was exceeded headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 Retry-After: description: >- Whole seconds to wait until both applicable buckets can accept one request. Returned only with a 429 response. schema: type: integer minimum: 1 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: rate-limited error_msg: Rate limit exceeded. Retry after seconds. '500': description: Internal Server Error - Failed to fetch data headers: X-RateLimit-Limit: description: Maximum capacity of the continuously refilled minute bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining: description: Whole tokens remaining in the minute bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset: description: >- Unix timestamp in seconds when the minute bucket is expected to be full. This is not a calendar reset time. schema: type: integer minimum: 0 format: int64 X-RateLimit-Limit-Day: description: Maximum capacity of the continuously refilled daily bucket. schema: type: integer minimum: 0 X-RateLimit-Remaining-Day: description: Whole tokens remaining in the daily bucket after this request. schema: type: integer minimum: 0 X-RateLimit-Reset-Day: description: >- Unix timestamp in seconds when the daily bucket is expected to be full. The bucket refills continuously and does not reset at midnight. schema: type: integer minimum: 0 format: int64 content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: internal-server-error error_msg: 'Failed to fetch data: ' security: - HTTPBearer: [] - SoxaiApiKey: [] components: schemas: ErrorResponse: properties: error: type: string title: Error description: Machine-readable error category. examples: - bad-request error_msg: type: string title: Error Msg description: Human-readable explanation of the error; clients must not parse it. examples: - 'Invalid input: start_time must use YYYY-MM-DD.' type: object required: - error - error_msg title: ErrorResponse description: >- The body of every error answer: a machine-readable type and a human-readable message. securitySchemes: HTTPBearer: type: http scheme: bearer SoxaiApiKey: type: apiKey description: >- API key issued by `POST /api-key/secret`, sent in the `soxai-api-key` header. It is an alternative to the Bearer token, not an addition to it: when both are sent the Bearer token is used. The key carries the same roles as the user it was issued to, and expires after the number of days it was issued for. in: header name: soxai-api-key ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.