Skip to content

HWI Developer FAQs

Accounts, Users, Logins

I haven’t received my activation email to log into the Tenovi web app.

In some cases, this email is held up in spam/quarantine mail filters. For quicker access, you can make use of the ‘forgot my password’ feature on the Tenovi login page to send a password reset email. If this second email doesn’t arrive in your inbox (should arrive very quickly), contact us and we can see what the issue could be.

Reseting your password from the login screen of the Tenovi web app

API Calls

The docs reference a client domain, where can I find the client domain for my account?

You can find your client domain on your Client Homepage when logged into the Tenovi web app in the card that is used to create API keys.

Your client domain is on the Client Home screen of the Tenovi web app

This URL will be your prefix for all your Tenovi API calls to make requests. It looks something like this:

Terminal window
https://api2.tenovi.com/clients/test-client/

An example of making an API call to list all your client devices looks something like this:

Terminal window
https://api2.tenovi.com/clients/test-client/hwi/hwi-devices/

More on the client domain can be found in our API URL Configuration documentation.

I don’t have my API Key after I generated it. Can you send it to me?

All our API keys are hashed and encrypted for security purposes. Once you generate an API key you will be shown the full API key once. After the modal is closed, the API key will only be displayed by its prefix within the Tenovi web app. If you do not have your API key on file after this creation, you will need to create a new API key.

Generating API keys on the Client Home screen of the Tenovi web app

Webhooks

How many Measurement and/or Fulfillment Webhooks can I setup for my account? How many API Keys?

You can create as many webhooks for measurements and fulfillment updates as needed for your setup. We recommend trying to keep this list smaller rather than larger for maintainability but you can send data to multiple endpoints in your own infrastructure. Likewise, you can generate many API keys in a single account.

How quickly can I expect webhook notifications?

Webhook payloads are delivered nearly instantly from Tenovi’s servers. In some cases they can take up to 2min to fully resolve.

I didn’t receive my webhook notifications for fulfillment or measurements, how can I debug/verify my setup?

First, ensure you have the correct URL endpoints pointing to your infrastructure on your client home within the Tenovi web app. In addition, ensure these endpoints have any applicable authorization headers configured correctly to authenticate with your infrastructure.

If your URL endpoints look to be configured correctly, ensure error handling is setup within your infrastructure and the appropriate JSON schemas are in use. Refer to our online documentation for detailed information on these schemas.

You can quickly test fulfillment webhook responses by including the ‘client_will_fulfill’ flag in your initial fulfillment API request. This flag is in the device > fulfillment object sent in the initial API request.

This enables you to update the fulfillment request within the Tenovi web app (ie. updating shipping information) that will force a fulfillment payload to be sent to your infrastructure.

How can we track device kits (collections of devices) for a specific patient?

In some cases, you will want to be able to track which devices a patient has within your system. Tenovi webhook payloads don’t include this information in a single field but some fields can be concatenated and saved within your system to save/read this information.

You can make use of the hardware_uuid and the sensor codes to create a string that contains this information. This can be useful if your organization needs to keep track of which devices a patient uses in a single field.

What does the “Post as Array” option in the HWI Webhook configuration do?

For devices that measure multiple metrics simultaneously (e.g. BPMs that measure both blood_pressure and pulse metrics in a single physical reading), the HWI Webhooks can be configured to either send two separate POST requests for each metric, or a single POST request with the measurement data for each metric included in an array.

Post as array settings can be configured for each webhook on the client home screen of the Tenovi web app.

Combining multiple measurement webhooks into a single payload using Post as Array

Default Measurement JSON Payloads

For example, here is how data would be received from a single physical measurement from a BPM if post_as_array == False:

POST Request #1:

{
"metric": "blood_pressure",
"device_name": "Tenovi BPM – L",
"hwi_device_id": "12345678-abcd-1234-abcd-1234567890ab",
"patient_id": "12345678-1234-12345678",
"hardware_uuid": "fed091a643ff",
"sensor_code": "10",
"value_1": 120.00,
"value_2": 80.00,
"created": "2021-01-15T12:15:20.123597Z",
"timestamp": "2021-01-15T12:14:49.000000Z",
"timezone_offset": -7,
"estimated_timestamp": false,
"filter_params": {
"measurement_index": 15
}
}

POST Request #2:

{
"metric": "pulse",
"device_name": "Tenovi BPM – L",
"hwi_device_id": "12345678-abcd-1234-abcd-1234567890ab",
"patient_id": "12345678-1234-12345678",
"hardware_uuid": "fed091a643ff",
"sensor_code": "10",
"value_1": 88.00,
"value_2": 0.00,
"created": "2021-01-15T12:15:45.123597Z",
"timestamp": "2021-01-15T12:14:49.000000Z",
"timezone_offset": -7,
"estimated_timestamp": false,
"filter_params": {
"measurement_index": 15
}
}

Post as Array Measurement JSON Payloads

Here is how that same data would be received from a single physical measurement from a BPM if post_as_array == True:

POST Request #1:

[
{
"metric": "blood_pressure",
"device_name": "Tenovi BPM – L",
"hwi_device_id": "12345678-abcd-1234-abcd-1234567890ab",
"patient_id": "12345678-1234-12345678",
"hardware_uuid": "fed091a643ff",
"sensor_code": "10",
"value_1": 120.00,
"value_2": 80.00,
"created": "2021-01-15T12:15:20.123597Z",
"timestamp": "2021-01-15T12:14:49.000000Z",
"timezone_offset": -7,
"estimated_timestamp": false,
"filter_params": {
"measurement_index": 15
}
},
{
"metric": "pulse",
"device_name": "Tenovi BPM – L",
"hwi_device_id": "12345678-abcd-1234-abcd-1234567890ab",
"patient_id": "12345678-1234-12345678",
"hardware_uuid": "fed091a643ff",
"sensor_code": "10",
"value_1": 88.00,
"value_2": 0.00,
"created": "2021-01-15T12:15:45.123597Z",
"timestamp": "2021-01-15T12:14:49.000000Z",
"timezone_offset": -7,
"estimated_timestamp": false,
"filter_params": {
"measurement_index": 15
}
}
]

Devices & Gateways

How can I map a patient to a specific device/gateway?

When you are making a fulfillment request, you can pass an optional patient_id parameter in your JSON payload. This ID will be included in all webhook responses and will enable Tenovi and your system to map devices/gateway to a specific patient.

What if there are multiple Gateways in one area? How do I associate them with specific devices?

If there are multiple gateways in the area, they must be placed in a Whitelist Mode to ensure they only transmit readings from the specified devices. You can view the Whitelist status of a Gateway using the hwi-gateway-info endpoint.

If Tenovi is dropshipping devices, our Fulfillment Team will automatically place them in Whitelist Mode at shipping time. If you bulk ordered Gateways, you can place them in Whitelist Mode manually by following these step:

  1. Unplug all gateways except for the one you would like to put into Whitelist mode.
  2. Press and hold the button on the gateway until you see a pulsing white light.
  3. Place the devices that you want to whitelist within 1 foot of the gateway (as close as possible) and take a measurement.
  4. The pulsing light should go away. Take another measurement. Confirm the LED light turns green.
  5. Repeat these steps for any other gateway in the area. All Tenovi gateways in the area must be in whitelist mode to operate correctly.

Date & Timestamps

The measurement webhooks include both a created datetime field and a timestamp field. What is the difference?

The created field indicates when a Measurement was received by our system (i.e., when the record was created in our database).

The timestamp field indicates when a Measurement was taken (see below for more details).

Some of our devices can store measurements on-device if readings are taken when they are outside of our Gateway’s range (see devices with “On-Device Measurement Storage” on our Device Overview page). When this happens, these devices save the time the measurements were taken in the timestamp field and transmit the measurements with this timestamp the next time our Gateway is in range. Our Gateway sets the time on these devices every time they connect, so usually, these timestamps are very accurate.

Our system uses two datetime fields (timestamp and created) to distinguish between when the measurement was taken and stored on the device (timestamp), and when the measurement was received by our servers (created).

If a user often takes readings out of range of the Gateway, it is not uncommon for there to be a several days difference between these two datetime fields. Often, you will see devices with different timestamp values and very similar created values, indicating times when the Gateway uploaded a batch of historical readings all at once.

What is an estimated timestamp?

Our system tracks both the date and time when a measurement is taken and when it is received by our servers. For devices with On-Device Measurement Storage (see our Device Overview for a full list), our Gateway sets the time on these devices every time they connect, so usually, these timestamps are very accurate.

However, sometimes the time on a device is not correct (for example, if measurements are taken right out of the box or after the user replaces the batteries, before a device has had a chance to connect to our Gateway). Our system detects this by looking for measurements in an invalid time range. When this happens, our system will replace the invalid timestamp with an estimated timestamp based on the last valid timestamp received, when the device was delivered, and other factors.

If multiple invalid timestamps are received, our estimation algorithm will preserve the time between subsequent measurements to ensure billing is not affected (as some billing codes depend on the collection of measurements across a specific number of days).

Our system uses a flag in our API to indicate which timestamps are estimates. We also always include the time at which the measurement was received by our system (the created field) in case you would prefer to use this value instead.