Recipes Overview & AI Build Prompts

Recipes are task focused walkthroughs. Each one takes a job a developer actually has to do, breaks it into numbered steps against real endpoints, and ends with a downloadable prompt you can hand to an AI coding assistant to generate a working script in your own language and stack.

Recipes assume you have already completed the Quick Start Guide and have a working API key and client domain.

How the AI Prompts Work

Every recipe has a companion prompt file. Download it, paste it into the AI assistant your team already uses, and answer the questions it asks you. The prompt is written to interrogate you first rather than guess, so it will ask which client domain to use, what language and output format you want, and any thresholds specific to that recipe before it writes a line of code.

Each prompt contains the real endpoint paths, methods, and parameters for that recipe, plus the platform constraints that most commonly break generated scripts. It also instructs the assistant to fetch llms.txt before generating anything, so it grounds itself in current documentation rather than whatever it absorbed during training.

Choosing a Recipe

Backfilling Measurement data

Recover measurements your system missed, or seed a new system with history

Pull measurements on demand when webhook delivery was interrupted, when you are seeding a new system with historical data, or when you need to audit that your records are complete. Covers the patient and device measurement endpoints, half open date windows, and how to reconcile against records you already hold without creating duplicates.

There is no measurement identifier in the API response or the webhook payload, so reconciliation uses a composite key of hwi_device_id plus metric plus timestamp. Records flagged estimated_timestamp: true need their own matching branch.

Read the recipe | Download the AI prompt

Gateway Connectivity Report

Find out which Gateways are healthy, silent, or never connected

Build a health report across every Gateway on your account. Combines the paginated hwi-gateways list with gateway-info to pull signal strength, last check in time, firmware version, and whitelisted devices per Gateway, then groups the results into signal health buckets you define.

Use it for proactive monitoring, for finding Gateways that have gone silent, or for validating a deployment before go live.

Read the recipe | Download the AI prompt

Bulk Unlinking Devices

Retire many devices at once after an audit or mass unenrollment

Retire many devices at once following a device audit, a mass unenrollment, or a program wind down. Covers building the target list from a web app CSV export or a filtered API query, looping the unlink-gateway call at a safe rate, and verifying the result including Gateway occupancy.

Read the recipe | Download the AI prompt

Common Gotchas Across All Recipes

These are the issues that break scripts most often regardless of which recipe you are following. Read them once before you start.

Pagination and result limits

As of May 5, 2026, list endpoints truncate at 1,000 results when no pagination parameters are supplied. This includes hwi-devices and the measurement endpoints. Truncation is silent. Your script will look like it succeeded and will simply be missing everything past the first thousand records. Measurement requests with no time range specified default to the last 30 days. See the Pagination Guide.

Rate limiting

Each API key is limited to 1 request per second. Firing exactly on the one second boundary can trigger 429 responses, so pace at 1.2 seconds between calls rather than 1.0. If you are using Postman Collection Runner, set the iteration delay to 1200 milliseconds. A 429 in the middle of a long loop should not end the run. All requests must be made over HTTPS.

Identifier formatting

Gateway UUIDs must be passed with no hyphens.

hwi_device_id is returned hyphenated and lowercase, but is accepted in either form on request. Normalize case and hyphenation on both sides before comparing identifiers across systems, or your reconciliation logic will report false mismatches.

patient_external_id in a request path and patient_id in a response body carry the same value despite the different names.

Your client domain appears in every request path. Take the exact value from API URL Config and Client Domain rather than guessing at it from your account name.

Time handling

All timestamps returned by the API are UTC and ISO 8601. Send them the same way.

timestamp__gte is inclusive and timestamp__lt is exclusive. Use the half open interval when you page through consecutive windows, otherwise you will double count records at every boundary.

timestamp is when the reading was taken. created is when Tenovi received it. These are not the same value and choosing the wrong one is the single most common cause of a report that returns nothing useful. Delay analysis filters on created. Clinical history filters on timestamp.

timezone_offset is a whole number of hours, positive or negative.

Scoping and permissions

Endpoints that take a specific resource ID only return data for resources already associated with your account. A 404 usually means the resource belongs to another account or has not been linked yet, not that it does not exist.

gateway-info in particular cannot be used to validate an arbitrary Gateway ID before that Gateway has been associated with your account through a fulfillment request, a device activation, or a bulk order pre activation.

Before you run anything destructive

Test against a small batch first. Log every call with its status code and keep the log. Run read only verification after the fact rather than trusting that a 200 response means the outcome you intended.

Testing without writing code

Every endpoint referenced in these recipes is available in the Tenovi Postman Collection with preconfigured requests. Use it to confirm your credentials, client domain, and filters return what you expect before you build anything on top.