Patients become the center of the integration. Data streams connect devices to the people using them.
Stable identifiers keep your application insulated from hardware changes.
We are building the next generation of the Tenovi API. API v2 is a ground-up redesign of how you integrate with the Tenovi platform, shaped by five years of real integrations, hundreds of partner conversations, and the patterns we have watched teams build on top of v1.
This page is an early look at what is changing, why, and what you should do now.
Follow the launch
Get API v2 updates by email
Be the first to know when preview documentation, migration guidance, SDKs, and launch details are available.
API v1 grew organically around devices and gateways. That served early integrations well, but it left the most important entity in remote patient monitoring, the patient, as an optional attachment rather than the center of the model. It also left some concepts (Client Device, HWI Device, hardware UUID) carrying more meaning than their names suggest.
API v2 reorganizes the platform around how RPM programs actually work: patients receive devices, devices produce data, and your application consumes that data per patient.
In v2, every integration starts with a patient. The patient object is the root of the data model, identified by the external_id you supply from your own system. Devices, measurements, and fulfillment all hang off the patient rather than the other way around.
The patient object is also the gate to everything v2 adds. Every v2-only capability available at launch, including all three on the 2027 roadmap, requires it. If you have already adopted the patient object in v1, you are ahead of the curve: your migration is significantly simpler and you are already positioned for what comes next.
Data streams replace Client Device
The Client Device concept is retired. In its place, v2 introduces the data stream: the combination of a patient, a gateway, and a Bluetooth device, one per device type per patient. A data stream is what produces measurements, and it is the thing you subscribe to, query, and manage.
This is a naming and modeling change that makes the platform match reality. What you think of today as “the patient’s blood pressure device setup” is a data stream.
HW ID becomes Data Stream ID
The canonical identifier you use today (the HWI Device ID) is renamed to Data Stream ID. Same role, clearer name. Mapping guidance will ship with the migration documentation.
Gateways become infrastructure
Gateways are redefined as infrastructure: the host that carries data streams, not an entity you build your data model around. Gateway swaps and replacements will no longer ripple through your integration logic.
Ordering and fulfillment are decoupled at launch
In v1, requesting hardware, creating a device record, and linking hardware to a patient travel through one nested payload. At launch, v2 tracks ordering and fulfillment as their own objects with their own lifecycle. You order devices to a patient, follow fulfillment as a distinct status, and activate data streams when hardware arrives. Each step is observable and none hides inside another.
The redesign is not change for its own sake. Here is what a v2 integration gets you that v1 cannot:
Less integration code
In v1, resolving which patient a measurement belongs to often means joining device records, hardware UUIDs, and patient IDs in your own database. In v2 the patient is the root object, so patient-centric retrieval is a single query, not a mapping table you maintain.
Hardware changes stop breaking your logic
Gateway replacements in v1 change the hardware_uuid your integration may key on, which is a leading cause of dropped or misattributed data. In v2 the Data Stream ID is stable across gateway swaps and device replacements. You track the stream, we handle the hardware underneath it.
Clearer vocabulary and faster onboarding
Client Device, HWI Device, and hardware UUID all disappear in favor of names that mean what they say. New developers on your team ramp on the model in hours, not weeks.
Official SDKs
v2 ships with official Tenovi SDKs, starting with Python, with JavaScript following. The SDKs are v2-only by design: typed objects, built-in pagination handling, and webhook payload parsing out of the box. If you have been maintaining your own client wrapper around v1, the SDK replaces it.
Every new platform capability from launch onward ships on v2 only. Three are already on the roadmap for 2027:
Inventory management. Fleet-level visibility into every gateway and device on your account: what is in storage, what is with a patient, and how many times a device has been reused across patients.
Patient cohorting. Group patients into facilities and programs using synced fields and patient properties, so reporting and operations follow your org structure rather than a flat patient list.
HL7 and FHIR webhooks. Measurement and fulfillment events delivered in the formats your EHR and clinical systems already speak, alongside the existing JSON payloads.
v1 will continue to operate and receive security and stability fixes, but new platform capabilities will ship on v2 only.
New accounts will be v2-only
Integrations starting after launch will build on v2 from day one.
Existing v1 integrations keep working
There is no forced migration date today. We will publish a migration guide, timelines, and per-account support paths well before any v1 sunset conversation begins.
Migrate on your own schedule, one piece at a time.
v2 is backwards compatible with v1. You can run both side by side and move endpoint by endpoint in small sprints. Only a small set of v2 endpoints, starting with the patient object, is required to unlock v2-only features.
Webhooks remain the primary push mechanism for measurements and fulfillment events. v2 extends them with optional HL7 and FHIR payload formats in 2027, alongside the JSON payloads you use today.
Your API keys and authentication model carry forward.
The device catalog, fulfillment, and replacement workflows continue, reorganized under the new model.
Adopt the patient object in v1 today. It exists now, it is the spine of v2, and it is the one step that unlocks every v2-only capability. Integrations using it will have the shortest migration path. Start with POST /hwi-patients/ and include the nested patient object on device creation.
Use external_id as your primary patient identifier. Feed it from your own system of record.
Avoid building new logic around gateway IDs. Treat them as transport, not identity.
Talk to your Tenovi solutions engineering contact, or reach out through your usual support channel. If you are planning a new integration or a major build on v1 this quarter, tell us first. We can help you make choices now that will save you migration work later.
