Gateway Connectivity Report

This recipe builds a connectivity health report across all Gateways on your account. It combines the hwi-gateways endpoint for a paginated list with the gateway-info endpoint to pull signal strength, last check in time, firmware version, and whitelisted devices per Gateway. Use this for proactive monitoring, identifying Gateways that have gone silent, or validating a deployment before go live.

The process for getting a Gateway connectivity report involves:

1. Page through GET /hwi-gateways/ to collect all Gateway UUIDs on your account.
2. For each Gateway you want to inspect further, call GET /gateway-info/{gateway_uuid}/ to retrieve detailed connectivity data.

The result is a ranked list of Gateways grouped by signal health.

Download AI Prompt for this Recipe

Rather than a code sample you would need to adapt, the prompt below gives an AI coding assistant everything it needs to generate a working script in the language of your choice, scoped to the data points that matter to your program. Copy it and paste it into your assistant of choice. It will ask you a few questions before it writes anything.

Never paste a live API key into an AI assistant. The prompt leaves the key as a placeholder and instructs the assistant to read it from an environment variable or your existing secret store at runtime.

Download AI Prompt for Gateway Connectivity Report

Before you start

You will need an active API key and your Client Domain. All requests are made against https://api2.tenovi.com/clients/{CLIENT_DOMAIN}/hwi/ over HTTPS. See API URL Config and Client Domain for details.

Each API key is limited to 1 request per second. This matters for this recipe. See Scoping Step 2 below.

Two endpoints, two different questions

The list endpoint and the detail endpoint do not return the same connectivity field, and the difference is the point of this report.

Field	hwi-gateways (list)	gateway-info (detail)
gateway_uuid	✅	✅
last_signal_strength	✅	✅
last_measurement	✅	❌
last_checkin_time	❌	✅
assigned_on	✅	✅
shipped_on	✅	✅
firmware_version	❌	✅
bootloader_version	❌	✅
provisioned	❌	✅
whitelisted_devices	❌	✅

Timestamps

All timestamps returned by the HWI API are UTC in ISO 8601 format. Compute staleness thresholds in UTC so that daily reports do not drift by a day.

last_measurement tells you whether the patient is taking readings. last_checkin_time tells you whether the Gateway is reaching the Tenovi network at all. A Gateway that has never checked in is a hardware, power, or cellular coverage issue.

Step 1: Fetch All Gateways

Page through hwi-gateways to collect every Gateway UUID associated with your account. Set page_size to a value that works for your account size. The maximum page size is 1000. Larger pages mean fewer round trips but slower individual responses, so for accounts under a few thousand Gateways a page size of 100 is a reasonable starting point.

GET /clients/{CLIENT_DOMAIN}/hwi/hwi-gateways/?ordering=-last_measurement&page_size=100

The result from this endpoint is paginated, with next and previous links in the root of the JSON response. See Pagination for how to walk the full result set.

{
  "count": 1,
  "next": "https://api2.tenovi.com/clients/{CLIENT_DOMAIN}/hwi/hwi-gateways/?page=2",
  "previous": null,
  "results": [
    {
      "gateway_uuid": "AABBCC001122",
      "last_signal_strength": 28,
      "last_measurement": "2026-07-30T14:15:22Z",
      "shipped_on": "2026-06-01T00:00:00Z",
      "assigned_on": "2026-05-15T00:00:00Z"
    }
  ]
}

Useful Query Parameters

Parameter	Description
ordering	Sort by assigned_on, shipped_on, or last_measurement. Prefix with - for descending.
last_measurement__isnull=true	Filter to Gateways that have never sent a measurement.
shipped_on__isnull=false	Filter to Gateways that have been dropshipped.

Signal strength and last measurement are both returned here. If you only need a signal and measurement report, Step 1 is sufficient on its own and no further calls are required.

Step 2: Get Detailed Gateway Info

For each gateway_uuid, call the gateway-info endpoint.

GET /clients/{CLIENT_DOMAIN}/hwi/gateway-info/{gateway_uuid}/

UUID format

The Gateway UUID must be passed with no hyphens. AABBCC001122 will resolve. AABB-CC00-1122 will not.

Example response:

{
  "gateway_uuid": "AABBCC001122",
  "firmware_version": "2.170.38",
  "bootloader_version": "1.0.4",
  "provisioned": true,
  "last_signal_strength": 28,
  "last_checkin_time": "2026-07-30T14:15:22Z",
  "assigned_on": "2026-05-15T00:00:00Z",
  "shipped_on": "2026-06-01T00:00:00Z",
  "whitelisted_devices": [
    {
      "sensor_code": "10",
      "mac_address": "1A2B3C4D5E6F",
      "whitelist_status": "CO",
      "created": "2026-06-05T00:00:00Z",
      "modified": "2026-06-05T00:00:00Z"
    }
  ]
}

Scoping Step 2

Step 2 requires one call per Gateway. At a rate limit of 1 request per second, a fleet of 5,000 Gateways takes roughly 83 minutes to inspect in full.

You might not need to call gateway-info for every Gateway, depending on your use case. Use the Step 1 response to identify candidates and inspect only those.

For example, a Gateway with a recent last_measurement and a healthy signal is already reporting normally and needs no detail call. The Gateways worth inspecting are the ones with a null or stale last_measurement, or a low signal strength, because those are the ones where you need last_checkin_time and provisioned to tell you what is actually wrong.

On a healthy fleet this reduces Step 2 from thousands of calls to a small subset, and brings the report runtime from hours to minutes.

Key Gateway Fields

Field	Notes
last_signal_strength	Integer between 0 and 30.
last_checkin_time	Last time the Gateway connected to the Tenovi network; null if never connected.
provisioned	Boolean. If false, the Gateway has not completed provisioning.
firmware_version	Current Gateway firmware. Useful for identifying Gateways that predate a newly available device.
bootloader_version	Bootloader running on the Gateway. Informational.
whitelisted_devices	Devices locked to this Gateway. whitelist_status is RE (Requested) or CO (Confirmed). Most devices are not whitelisted, so an empty array is normal and is not a fault condition.
whitelisted_devices[].sensor_code	Identifies the device type on a whitelist entry. Each device page lists its Sensor Code. See Available Devices.

Note

gateway-info only works for Gateways already associated with your account, either via a fulfillment request, device activation, or bulk order pre activation. It cannot be used to validate an arbitrary Gateway ID.

Step 3: Build the Report

With data from both endpoints, group Gateways into buckets. A sample of what this could look like:

Group	Criteria
Excellent	Signal strength >= 20
Moderate	Signal strength 9-19
Poor	Signal strength <= 8
Offline	Last check-in time is null
Inactive	Last check-in time is more than X days

X is a threshold you define. It signifies the point at which you consider a Gateway or patient inactive, and it depends on the program you are running. A daily monitoring program may treat 3 days as inactive. A monthly compliance program may not flag anything until 30 days. There is no single correct value, so set it to match your clinical workflow.

If whitelisting is a concern of yours, you could extend this report to also list any devices (or the count of devices) that are whitelisted. If you have an extensive re-issue program where you re-use Gateways between patients as they enroll and unenroll into your programs, you should also be cognizant of requested and confirmed status of whitelisted devices as these can impact a patient’s first experience with their devices and Gateway.

Acting on the Results

The report is only useful if each bucket routes somewhere.

Finding	Likely cause	Next step
last_checkin_time is null	Never powered on, no cellular coverage, or not delivered	Confirm delivery and that the patient has plugged the Gateway in
Check-in recent, last_measurement null or stale	Hardware is working, patient is not taking readings	Route to your clinical or care management team
Poor signal, checking in	Marginal cellular coverage at the patient location	Advise repositioning the Gateway to an area with better reception (often closer to a window)
provisioned: false	Provisioning did not complete	Contact Tenovi support
Patient no longer enrolled	Gateway still assigned	Unlink the device

Common Issues

Issues specific to this recipe. For platform wide behavior see Common Gotchas.

Gateway not found The Gateway is not yet associated with your account. It must be linked via a device activation or bulk order before gateway-info will return data.

last_checkin_time is null The Gateway was assigned or shipped but has never connected. Check that the patient has plugged it in and that it reached a cellular signal.

provisioned: false The Gateway has not completed provisioning. Contact Tenovi support if this persists after the Gateway has been powered on and connected.

whitelist_status stays at RE The whitelist request has not been confirmed by the Gateway. This only applies to accounts using device whitelisting. You can clear this request via the Tenovi web app by searching for your Gateway and using the device topology map to view and edit whitelist status on a per device basis.