Omron Partner API for US
Step 1 - Developing in Staging Environment
Step 2 - Implementing OAuth 2.0
Introduction
The Omron Wellness API is designed to enable partners to seamlessly share individual health and lifestyle activity data through secure server to server connections.
Partner applications gain access to user data collected by Omron devices and stored on the Omron Cloud. When our users upload device data to the Omron Cloud, you can schedule and pull readings for the users already authenticated with the Platform.
We currently offer following data through our API service: Blood Pressure Readings, Activity Metrics, Weight, Temperature (Europe), Oxygen (Europe)
The Omron Wellness API uses the OAuth 2.0 protocol for authorization. The use of these protocols allows our API to support the user logging into our service and authorizing your application to receive their data. You can connect to, and interact with our APIs using the programming language and platform of your choice, as long as it supports HTTPS based request / response scenarios.
Before You Begin
In order to use the Omron Wellness API, your application must be registered with Omron. Please review the Omron API for Developers site at https://omronhealthcare.com/api/ . Once registered, Omron will provide you with a unique Application ID and Secret Key that is unique to your application. This information will ensure your application has the correct level of access to the APIs and help secure communication between the 2 platforms. Your application will be assigned an Application ID and Secret Key for use in the Omron Wellness development environment for initial integration and testing. When approved for a production Go-Live, a separate Application ID and Secret Key for our production environment.
Please provide the following information as part of the API request process:
Application display name | Used to identify your application to the end user during consent and various other points. |
Application Info URI | [Optional] URI to additional information. |
Policy URI | [Optional] URI to the privacy policy document. |
ToS URI | [Optional] URI to the terms-of-service document. |
Application Logo URI | [Optional] URI of logo or image representing your application. The image will be scaled to 80px x 80px. |
Redirect URI's | Specifies the allowed URIs to return tokens or authorization codes to. |
Notification URI | The URI to which user update notifications will be sent. |
Requested Scopes | The API identifiers you wish to access. Either "blood-pressure", "activity", “weight”, “temperature”, “oxygen” |
Name of the company | Legal company name of the application owner |
Address of the company | Mailing address of the company. |
Company Logo URI | [Optional] URI of logo or image representing your company. The image will be scaled to 80px x 80px. |
Contact person name | The primary contacts name |
Contact person email | The primary contacts email |
Contact person phone | The primary contacts phone number |
Prerequisites
In order to get started, you will need the information that was assigned as part of the partner sign up request:
Client Id
Client Secret
Implemented Redirect URIs
As part of your sign up, you must provide a list of authorized URIs that you want our platform to redirect/post the results back to so you can store the tokens and the result of the connection.
For purposes of this document, we will use the following values in our examples:
Parameter | Value |
Client Id | aviato-api |
Client Secret | 4e435f8d3aac0b6398dfb9db10227ad6225f4b38e7f8b3015ca92b9b10b8f1b3 |
Redirect URI |
Step 1 - Developing in the Staging Environment
The Omron API and OAuth Servers provide access to data from the Omron Apps. However, accounts and data posted to the production site are not available to the API Services in the Staging environment. In order to integrate in this environment, please use the staging tools.
Partner developers can simulate uploading BP readings to the staging server for testing without the use of a physical BPM monitor using the tool located at https://tool.omronwellness.com/ . This web tool will allow you to download a sample Excel spreadsheet which may be modified for specific reading values and uploaded for a specific test user. Alternatively, you may generate random readings data which can also be uploaded for a specific test user. This synthetic upload will go through the same workflow as a real device with the mobile application. Detailed instructions are provided below.
Steps to utilize the tool: In order to get started, you will need the information that was assigned as part of the partner sign up request:
Create a test user account in the Staging by choosing "Signup" option in https://tool.omronwellness.com/ Use the account you just created to authenticate by signing in
Click Generate Readings in order to generate random readings and upload them for the user Alternatively, create custom readings by performing the following steps:
Click "Download Sample" to download an Excel Template for the Readings Edit/update the readings in the Excel Template
Upload the modified Readings Excel file by clicking the Upload File link. This will upload the readings in the spreadsheet
Step 2 - Implementing OAuth 2.0
Creating the Authorization Request
From your partner application, there will need to be a mechanism to redirect your user to a web page with a specific URL (called the Authorization Request) to initiate the authorization process. This web page will allow the Omron Wellness user to login to their account, view information about the connection with your application, and either approve or deny the connection.
In order to create this special URL, you will first need to know the host name of our OAuth server, which can be found below according to the environment you are targeting:
Environment | Hostname |
Staging (used for all testing during development and even post-production) | |
Production |
Generating the URL
This is a standard HTTP GET request your user will be following. The base URL looks like the following:
https://\[\[HOSTNAME\]\]/connect/authorize
To complete the URL, we must include several variables as query string parameters:
Parameter | Description |
client_id | The unique Client Id we assigned to your application during the sign up process. |
response_type | This must always be "code" |
scope | This must always be a space delimited list of the scopes your application is requesting. For now, the scopes you must request are: |
redirect_uri | The URL where you want the authorization code returned to in the user's browser or web viewer, this is performed as an HTTP GET to the URI you provide. The URI you provide must have been defined as an authorized redirect URI as part of your sign up process. |
state | (Optional) This parameter can be used by your application to store context information about the request or to protect against cross-site forgery attempts. Whatever value you include here will be included in the responding GET with the authorization results. |
Now we have all the pieces to put together the entire URL which should be properly escaped:
https://stg-oauth-website.ohiomron.com/connect/authorize?client_id=aviato-api&response_type=code&redirect_uri=https://example.aviato.com/oauth&scope=bloodpressure+activity+weight+temperature+oxygen+openid+offline_access
Understanding the Authorization Response
When the user is directed to the URL you created above, they will be presented with a web pages that allows them to authenticate and either authorize or deny your application access to their data. The responses you will receive are thoroughly documented in the OAuth specification, but we will highlight a couple of examples here. If you sent a "state" parameter with your request, it will be returned to you in all of the scenarios.
User Denies the Connection
If the Omron Wellness user denies the connection, the redirect URL will be presented back to the browser with a specific error code:
https://example.aviato.com/oauth?error=access_denied
User Authorizes the Connection
If the user authorizes your application, the redirect URL will receive your "authorization code" in a query parameter as shown below:
https://example.aviato.com/oauth?code=d32af9ff1e30e34a9b1434e2ad38b6dd
This authorization code is only valid for a short period of time (~ 10 minutes) and cannot be re-used once it has been validated for a token.
Using the Code in exchange for Tokens
Environment | Hostname |
Staging (used for all testing during development and even post-production) | |
Production |
This process of authorization from the user should be a one-time event each time you need to make a connection between your application and Omron Wellness. Your application should immediately use the authorization code you received above to receive a set of tokens your application can use to receive the user's data from the Omron Wellness Data API. Your application is responsible for storing and protecting the access token and refresh token, as well as tracking their expiration. As a best practice, you do not want the access token or refresh token to expire before you need to use them, otherwise you will have to perform the user authorization again.
The lifetime of your tokens is controlled by expiration limits defined during your sign up process and vary based on your application's needs.
Making the Access Token Request
This process is documented in the RFC 6749 Section 4.1.3 of the OAuth specification but this section will detail the information you need to supply in your request as an overview.
IMPORTANT
It is very important that this request, and any request using an access or refresh token, be made from your application servers to the Omron Wellness servers in a server-server scenario, NOT from a user's browser agent. Why? Because most of these requests require you to supply your "secret" as part of the request, and your "secret" should be protected and kept only on your servers
and not be distributed to any client machines.
The Access Token Request is made from your application as an HTTP POST to the following URL:
https://\[\[HOSTNAME\]\]/connect/token
You will need to include the following parameters with your POST using a content-type of "application/x-www-form-urlencoded":
Parameter | Description |
client_id | Your Client Id |
client_secret | The "secret" assigned to you during the sign up process, you will receive different secrets for each environment (staging will not be the same as production) |
grant_type | This will always be "authorization_code" |
scope | Same scope you used to receive the authorization code |
redirect_uri | MUST match the redirect URI you sent to receive the authorization code |
code | The authorization code you received from the user process |
Below is an example of an HTTP POST using the example information.
curl --location --request POST 'https://stg-oauth.ohiomron.com/stg/connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=aviato-api' \
--data-urlencode 'client_secret=4e435f8d3aac0b6398dfb9db10227ad6225f4b38e7f8b3015ca92b9b10b8f1b3' \
--data-urlencode 'code=d32af9ff1e30e34a9b1434e2ad38b6dd' \
--data-urlencode 'redirect_uri=https://example.aviato.com/oauth'
Understanding the Access Token Response
The Omron Wellness OAuth server will respond with an object containing your access_token, refresh token, and an id_token containing information about the user, primarily the user identifier you will need to supply to the Omron Wellness Data API.
Response
{
"success": true,
"access_token": "eyJraWQiOiJXbWFxXC9FdnJqQTI4dFpjNEJRYWFMWVVVdkljOUNpRExwOXkwT3lGRlE1Zz0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiI3MWUyMmFlNy1mYzY4LTRmZmItOWRiNS02NDA3ZWI1YjQyZmQiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tXC91cy13ZXN0LTJfbWtYUkluNXVRIiwiY29nbml0bzp1c2VybmFtZSI6IjcxZTIyYWU3LWZjNjgtNGZmYi05ZGI1LTY0MDdlYjViNDJmZCIsImN1c3RvbTp1c2VySWQiOiJjMDRmZWUwNWYwNTAwOGFhMDdlNzM3YzI0MTNhNTM0YmVhZjIxOTk2YTBlOGM2MjEwNTI1MDY5YjJjODY3MGY3Iiwib3JpZ2luX2p0aSI6IjY5ZjVmZGZkLTAxMjYtNDU1Ny1iOWVhLTk0Nzc2NmY0OWFhZiIsImF1ZCI6IjE0aGl2bnNnZnY5aTU2cGJkdWRydXVuaTN1IiwiZXZlbnRfaWQiOiJiZGQ4MmM4OC00NjgyLTQ1NmMtYjkzNS03MDAyNzkwYTZjOWQiLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTY0NDI1NTA2OCwiY3VzdG9tOmFwcE5hbWUiOiJPQ00iLCJleHAiOjE2NDQyNTg2NjgsImlhdCI6MTY0NDI1NTA2OCwianRpIjoiNTRmNzkzOWItMGYzOS00YTdkLWIzM2MtOTgxMmM2NTI4NDQ0IiwiZW1haWwiOiJzdGcub2MuYXVzMjNAeW9wbWFpbC5jb20ifQ.VK9Rv3LLUke62NCUq71cEDuzWXP09xCXdOllC4EE76MnBIefiPbXnIyXfFDAK9_S0ZwguY4ajX7CmrXSAoEKrJmRQTL8q51z2QnT19Juc5iK7W6rokTShkqZ8EbOTdyujAm0CZaoIGTYjZhkCpy6VQCSa22ikhrSmHGawxx7eMBGiWcigPSb902zvWRYPakUQqtHhPO7Tn-tKEk2BEdi7ltwenwo6j4bb1MwANzozC8-sejD3NBf-D1dxVOAnlaYiEp7PmqX3--c_n70CsxhLtVF47Bb2fysl8rYdDnr1l2_br5T1xIlQ1nsuU_lftYm5yJEs7022LFOOp3Jtl3aOQ",
"refresh_token": "eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.TjsJS7kqxCWcCnoAMOxrNaRCM6gCC17lVEBi0TLgRmPZxz7iD0QKCk0En0Mtd5JKXLL6omw5rR53u7RvCPLe_Z1w6lQ-qtKadx3tmoAAU-dCT51MxPtEo6hCgw4L1mreIHsLUGoP-riWTDpGdYH72JYcqFpb021ScdLrHYPF3oHGChNannGj2eEGQpCZXTzMZJ2AwDQnW2CClcXpotA2san_1-ybI3dNq0-UQABHXnPJyQi27PzzauHLxt0FHzWbsh5hOoCwfVCrhYST7avtoB3NnxIrsxi9TQcWgewSaa6uIrhEk4S3VakV5tCPGO5_so2Ml8OQ2M2ykkuBLlellA.0r4BlEvEIfCUv9Lj.2mcM5Wbj2OXU6M4fRLYCz4-l2caInODVoc3xbIbtG7e5WblQ63myZf2AzomZ2_15i7p03HlzSHHLxnvXEkMo3DGimajIA74yRh43kYmd39_vCMFXg5zSJpfuVbL-ogjGdtPF_TjKXMUAN2aY8-fHOfAuaiplTdvpI_e94V0TrRozY5rSEuvD0-9d0R_0lrOybiRy2X2lE0xbzewKwiPBb_H1TYyGPBfurE4rRQF15818cHH65vvqzD2ujzx7PJBhP8vVBgevUBeGNs3Xivxn3idRORsHehQM9okKi9iMe4NTztlU-GSoWRgrCuTa1ac3HSNW5fA3OEUqj4T7zc4YVMr1LHW7znH8FKG7fZ_F653pjQAqvPQnfjfXsOkQ3k3nyBYe0qjjNMKywTRO2hnnNt66T5UyhnYZih7bKmYCZsQn0DYz49CyOiEci3lI2Kgh49l40bxZ77WDjfEQbOu9HV-y0iqrW8RyUQ1Ynneq6QquU5sADfVYEEZ-Y2Fv7d9cXPipI2Efw6b8gEFf9ckyuHmU0iTdxZFfkm0nh6Fg4WUZ9plmtjF-uFE1mPFmAAOG7duIDe7X_5-Q51mPVhzgOugdKp-qgvGy6zRzF9ntDvV2ByXQs1rKF8Y5P1HU88w27ohbHPmH1ccaZ8WyOWrqJKMBiL1LBBeabdyBg_JnCsk5NXaIA_HHViagQPnAMb0e2HNLXUH-IU52lXN7iDstynYOTFGPM6NC8t1y1iNw9T_ZZ71MEU4cQC2ZlDE0gs-xzw9ESgdWHVjJO0VdCpBihMu7kv0i5cf0PhameDRohrd6mpb9HOFLT3NAMjT3iHMqGIbKtdM2V1AxJa9dhNPoCabGaU8V-_0kzSu4Ny_PsmgoLzno054oR2jZP-Pe9zx7d-lRdEBrTh5CuWZCUoR5Gui0YVrBLs--W0bp6ya9U1YqDN7FJSy5D7F9wLJBut8domMztD6i38QBB51p83pUU-Jo5k5d7y71ZzxscZKfyR_-ofcgKbfZRFovAjJeGZCmfQlARzrkrdyoGteE9wk62laGIpzwKNHv7sSGvjzau1DIhd3QyOxUoy-a9jyGg4SojJ-UPtT2kCgPKU1Ayk_C6XRsdbkzTprBKpZCZt8h2BP9RcTfqW79aKqkRP-K3UWRsI9oUoHWpMVpGXlDe_Bb5ryT4VHpkFxL2oEadOkjpO6fZQq4jYYCpvH_4uZ9pnoU_-1-WLJm6iYpfe_KQ_tG-PD-zMH38y8glFlCZ41zD7MvelW89EHGGERaFuYr4m9bxJwEAXi--QIav0aUJDz2RWALYHZxnbAy1xfkm-F6OuLWGAUXqLRS63MhEWo.qCGZrnXhBy9beK67nfx9VQ",
"expiresIn": 3600,
"tokenType": "Bearer"
}
Understanding the response:
Parameter | Description |
id_token | This a JWT (JSON Web Token) that contains information about the user who authorized your application. For information on how to decode the JWT you can refer to RFC 7519. During development it can be helpful to use a tool such as https://jwt.io/ to decode and examine the results that come back from the Omron Wellness OAuth server. Once you have decoded the "data" contained in the JWT, you can use "sub" represents a unique identifier for the Omron Wellness user. Token will also have email which provides the email address of the user |
access_token | You will need to store this token in order to present it as a credential along with your execution of the Omron Wellness Data API. |
expires_in | The number of seconds the access_token is valid. Your system should also store this in order to use the refresh token in advance of the expiration to receive a new access_token. |
token_type | Determines how you use the token during an API request, we will always use "Bearer" |
refresh_token | The token that can be used with the refresh token flow to get a new access_token when your existing one is ready to expire. |
Using your Refresh Token
In order to follow the best practice, monitor your population of access_tokens to identify tokens that are close to expiration. You can use your refresh_token assigned to the access_token to execute the OAuth refresh token flow defined in RFC 6749 Section 6 of the OAuth specification.
The Refresh Token Request is made from your application as an HTTP POST to the following URL:
https://\[\[HOSTNAME\]\]/connect/token
You will need to include the following parameters with your POST using a content-type of "application/x-www-form-urlencoded":
Parameter | Description |
client_id | Your Client Id |
client_secret | The "secret" assigned to you during the sign up process, you will receive different secrets for each environment (stage will not be the same as production) |
grant_type | This will always be "refresh_token" |
redirect_uri | MUST match the redirect URI you sent to receive the authorization code |
refresh_token | The refresh_token you received for the access_token you want to refresh |
Below is an example of an HTTP POST using the example information.
curl --location --request POST 'stg-oauth.ohiomron.com/stg/connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=aviato-api' \
--data-urlencode 'client_secret=4e435f8d3aac0b6398dfb9db10227ad6225f4b38e7f8b3015ca92b9b10b8f1b3' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'refresh_token={oauth_refresh}' \
--data-urlencode 'redirect_uri=https://example.aviato.com/oauth'
Understanding the RefreshToken Response
The Omron Wellness OAuth server will respond with an object containing your new access_token and a new refresh token that you should use in replace for the ones you had stored for the user.
Response
{
"success": true,
"access_token": <Access Token>,
"refresh_token": <Refresh Token>
"expiresIn": 3600,
"tokenType": "Bearer"
}
Understanding the response:
Parameter | Description |
access_token | You will need to store this token in order to present it as a credential along with your execution of our Data API. |
expires_in | The number of seconds the access_token is valid. Your system should also store this in order to use the refresh token in advance of the expiration to receive a new acces_token. |
token_type | Determines how you use the token during an API request, we will always use "Bearer" |
refresh_token | The token that can be used with the refresh token flow to get a new access_token when your existing one is ready to expire. |
Using the Omron Wellness Data API
Overview
You can use the access token acquired during the user authorization flow to securely access the Omron Wellness API. Typically, the token is presented to the web API in an HTTP request using the Bearer scheme, which is described in RFC 6750. This specification explains how to use bearer tokens in HTTP requests to access protected resources. The API executes in the context of a user by impersonating the user identity linked to your access token. The API only accepts the POST method.
API EndPoints - We host two environments, staging and production, where you can invoke our API. Depending on which environment you need, you will call our API at different locations:
Constructing the Request
Your request must contain an HTTP Header with a name of "Authorization" and a value containing the token and token type given to your application upon authorization:
Header | Value |
Authorization | Bearer <Access Token> |
In addition to the header, your request may include the following parameters.
Parameter | Description |
since | The start date from which measurements should be returned, or the API will return measurement data from the first upload to current time. |
limit | [Optional] The maximum number of measurements to return in the request. |
type | [Optional] You can specify a specific type of measurement as a filter, otherwise all measurement types the user authorized for your application will be returned. Values: bloodpressure, activity, weight, temperature, oxygen |
includeHourlyActivity | [Optional] If hourly activity data is available, it will be included with the daily aggregated values if this parameter is set to true. Values: true, false |
sortOrder | [Optional] Sets the sort order of the returned measurements. Default is descending ('desc'). When implementing paging, it is recommended to utilize an 'asc' sort order and the since value to request the new page. Values: 'desc', 'asc' |
bloodpressurePaginationKey | [Optional] If there is more bloodpressure data then on each page record, it will return bloodpressurePaginationKey, so that need to pass this key on next call to this API then it will return rest data. |
activityPaginationKey | [Optional] If there is more activity data then on each page record, it will return activityPaginationKey, so that need to pass this key on next call to this API then it will return rest data. |
weightPaginationKey | [Optional] If there is more activity data then on each page record, it will return weightPaginationKey, so that need to pass this key on next call to this API then it will return rest data. |
Example Request
The following example shows a POST request that passes an access token in the request header. The Authorization header indicates that it is a bearer token, which is valid for anyone who possesses the token.
Note - The measurement APIs are rate limited and should be called only when a notification is received from Omron. To implement notification, check section below - Implementing a Notification Endpoint
curl --location --request POST 'https://stg-oauth.ohiomron.com/stg/api/measurement' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Bearer eyJraWQiOiJUSE5mMEFHTnJ5Z3ExNmFjVDk5MUgrcGVpMDN3XC9UN0t4dmkySFZaY0lnMD0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiI3OWI3MjBmZC1hMWI2LTQ5NWEtYWE3Yy02ZmM4YmQ5YWQ2YzkiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLmV1LXdlc3QtMS5hbWF6b25hd3MuY29tXC9ldS13ZXN0LTFfcWhRWGR6TW5zIiwiY29nbml0bzp1c2VybmFtZSI6Ijc5YjcyMGZkLWExYjYtNDk1YS1hYTdjLTZmYzhiZDlhZDZjOSIsImN1c3RvbTp1c2VySWQiOiI1ZjlmMDc0MTkyMDBhNjE2YTYxZGU2ZGFiNTM0MjQ0Zjc0ZjdlMGVkOTk3OTM0N2FjZGFhNTE0NDU1OTlkMWY5Iiwib3JpZ2luX2p0aSI6ImE1MTJlOTQzLWFhMTAtNDcwOC1iMzA5LTMyN2MyZTIzY2U1YyIsImF1ZCI6IjdhOXZrN3FrZDh0ZXVoMnVoOGdzOWNzdm9uIiwiZXZlbnRfaWQiOiI4MjA1MmVhZS0wMjczLTQ0NDMtODMxZC01YmU0NTViMTU2MWUiLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTY0NDI1NDkwNiwiY3VzdG9tOmFwcE5hbWUiOiJPQyIsImV4cCI6MTY0NDI1OTQ0MywiaWF0IjoxNjQ0MjU1ODQzLCJqdGkiOiJlYWU2Yzg0NC01M2UxLTQ5MjQtYWQ0Zi1lNTJlM2NjZTA0ZjMiLCJlbWFpbCI6InN0Zy5vY2cuZGF0YTIyQHlvcG1haWwuY29tIn0.CXi0GyFOm3RQIUBzfFMil2GavH5m3AU621fkmqQydJ6BzRWtzTfOSLgG5IyBwE8EiF0C9c0V62Tgm8WZY_Maixf_VxbxO8_K-tFCjWykliGbq0Z8D-EFFlnxoI0EqOCl3VmYzwG_jEEJ8cThZVZ3kWZrxxOg_iNQrBnDV9a-2cOljo04HV1Q8fLtUWdUJmnVtk7G0xWmAgUTUzkHU_Dnv_CbwDtulkOj3BFUFcMdxD2FS_8nzcYFBQglZ2zybfK5cWWU57HZ6Fp6VK5zbduSn8GvWRiTLZRvKhzZwJVMzeKvXYlX6UjruM-xUFbbjRFQvwDEf8M0E5KalRw1mjJ9Vw' \
--data-urlencode 'type=bloodpressure' \
--data-urlencode 'since=2022-02-01' \
--data-urlencode 'limit=1'
Understanding the Response
The measurement API will respond with a standard structure in which different types of measurements will have unique formats.
Example Response - Blood Pressure
Response (When AFib Is Not Detected)
{
"status": 0,
"result": {
"bloodPressure": [
{
"id": 1644043106941,
"dateTime": "2022-02-03T16:44:13",
"dateTimeLocal": "2022-02-03T16:44:13",
"dateTimeUtcOffset": "+00:00",
"systolic": 92,
"diastolic": 71,
"bloodPressureUnits": "mmHg",
"pulse": 78,
"pulseUnits": "bpm",
"deviceType": "M700 Intelli IT"
}
],
"paginationKey": {
"bloodpressurePaginationKey": 1643906653000
},
"truncated": false,
"measurementCount": 1
}
}
Response (When AFib Is Detected)
{
"status": 0,
"result": {
"bloodPressure": [
{
"id": 1644043106941,
"dateTime": "2026-01-06T06:03:13",
"dateTimeLocal": "2026-01-06T06:03:13",
"dateTimeUtcOffset": "+00:00",
"systolic": 0, // AFib detected → systolic set to 0
"diastolic": 0, // AFib detected → diastolic set to 0
"bloodPressureUnits": "mmHg",
"pulse": 0, // AFib detected → pulse set to 0
"pulseUnits": "bpm",
"possibleAfib": true, // AFib detection flag
"deviceType": "7 Series Upper Arm"
}
],
"paginationKey": {
"bloodpressurePaginationKey": 1767593042000
},
"truncated": false,
"measurementCount": 1
}
}
Example Response - Hourly Activity Data
{
"status": 0,
"result": {
"activity": [
{
"id": 1639008000000,
"dateTime": "2021-12-09T00:00:00",
"dateTimeLocal": "2021-12-09T00:00:00",
"dateTimeUtcOffset": "+00:00",
"steps": 0,
"aerobicSteps": 0,
"calories": 0,
"caloriesUnits": "kcal",
"dailyDistance": "0",
"distanceUnits": "miles",
"deviceType": "HCR-6900T",
"hourlyActivityData": [
{
"hour": "00:00",
"distance": 0,
"aerobicSteps": 0,
"calories": 0,
"steps": 0
},
{
"hour": "01:00",
"distance": 0,
"aerobicSteps": 0,
"calories": 0,
"steps": 0
}
]
}
],
"paginationKey": {
"activityPaginationKey": 1639008000000
},
"truncated": false,
"measurementCount": 1
}
}
Example Response - Weight
{
"status": 0,
"result": {
"weight": [
{
"id": 1644225686000,
"idExt": 1644225686000,
"dateTime": "2022-02-07T09:21:26",
"dateTimeLocal": "2022-02-07T03:21:26",
"dateTimeUtcOffset": "-21600",
"weight": "71.6",
"restingMetabolism": "-1.0",
"visceralFatLevel": "-1.0",
"skeletalMusclePercentage": "-1.0",
"weightPref": "kg",
"bmiValue": "25.52",
"deviceType": "HN-300T2 Intelli IT",
"bodyFatPercentage": "-1.0"
}
],
"paginationKey": {
"weightPaginationKey": 1644225686000
},
"truncated": false,
"measurementCount": 1
}
}
Example Response - Temperature
{
"status": 0,
"result": {
"temperature": [
{
"id": 1643907217363,
"dateTime": "2022-02-03T16:53:03",
"dateTimeLocal": "2022-02-03T16:53:03",
"dateTimeUtcOffset": "+00:00",
"temperature": "33.8",
"temperaturePref": "°C",
"deviceType": "model_mc_280b_e"
}
],
"paginationKey": {
"temperaturePaginationKey": null
},
"truncated": false,
"measurementCount": 1
}
}
Example Response - Oxygen
{
"status": 0,
"result": {
"oxygen": [
{
"id": 1643907124466,
"dateTime": "2022-02-03T16:51:29",
"dateTimeLocal": "2022-02-03T16:51:29",
"dateTimeUtcOffset": "+00:00",
"oxygenLevel": "99",
"pulse": "73",
"deviceType": "blesmart_00060002b87c6f2aeac4"
}
],
"paginationKey": {
"oxygenPaginationKey": null
},
"truncated": false,
"measurementCount": 1
}
}
The Omron Wellness API will respond with a JSON object containing the following properties and objects:
Property | Description |
status | Code that indicates success or failure. A status of 0 always indicates a success. Failure codes are summarized in the Appendix Status Code List. |
result | Object containing the measurement entries and properties about the result. |
result.paginationKey | Return pagination key for each data type requested in the Get Measurement request Ex "paginationKey": { |
result.truncated | Only for Legacy users. Use paginationKey for new integrations. If the API reached the maximum number of results it could return, this will be "true" indicating that your application needs to ask for additional measurements using a "since" parameter of the last measurement date/time included in this result. |
result.bloodPressure | An array that will contain any blood pressure measurements available for the parameters you supplied. See the section below for the format of each measurement based on the measurement type. |
result.activity | An array that will contain any fitness/activity measurements available for the parameters you supplied. See the section below for the format of each measurement based on the measurement type. |
result.weight | An array that will contain any weight measurements available for the parameters you supplied. See the section below for the format of each measurement based on the measurement type. |
result.oxygen | An array that will contain any oxygen measurements available for the parameters you supplied. See the section below for the format of each measurement based on the measurement type. |
result.temperature | An array that will contain any temperature measurements available for the parameters you supplied. See the section below for the format of each measurement based on the measurement type. |
Each measurement type will have a certain standard set of properties that will be included with every measurement:
Property | Description |
id | A unique id internal to Omron which can be used in your own system to refer to the individual measurement. |
dateTime | Date Time of the measurement. This time is always provided in UTC. |
dateTimeLocal | Date Time of the measurement. This time is the user's local time. |