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.

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. This URL will be your prefix for all your Tenovi API calls to make requests. It looks something like this:

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

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

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

This usually points to misconfiguration of your Api-Key placed in your API calls header. Tenovi Api-Keys require that you pass them in your authorization header. Please note ‘Api-Key’ in the header is case-sensitive. Also, if you are making use of development and production Tenovi logins, ensure you are using the correct Api-Key for your relevant environment.

This could also be caused by not having a trailing slash on the end of the URL for the endpoint, causing the request to redirect and drop the authorization headers.

Below is an example of a successful authorization setup using cURL…

curl –location –request GET ‘https://api2.tenovi.com/clients/test-client/hwi/hwi-devices/’ \
–header ‘Authorization: Api-Key xxxxxxxxxxxxx’ \
–data-raw ”

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.

You can create as many webhooks for measurements and fulfillments 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.

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.

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.

Webhook payloads are delivered nearly instantly from Tenovi’s servers. In some cases they can take up to 2min to fully resolve. Please note, fulfillment webhooks only send responses when a fulfillment order is updated (i.e. when shipment tracking information is added by Tenovi fulfillment).

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:

https://api2.tenovi.com/hwi-redoc/

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.

https://api2.tenovi.com/hwi-redoc/#operation/hwi-devices_create

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.

• 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 (see discussion of the “estimated_timestamp” field in Question 11 for possible exceptions).

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.

As described in Question 10, 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. Please refer to our detailed API documentation for more information.

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.