Parallel Processing with Multiple API Keys

When activating large numbers of devices, pulling measurements for many patients, or running batch operations in a short window, sequential API calls can be slow and are at greater risk of hitting rate limits. This recipe shows how to partition work across multiple Tenovi API keys to process requests in parallel safely.

• Activating or updating hundreds or thousands of devices in a single batch job
• Bulk unlinking many devices from Gateways
• Backfilling measurement data after a webhook outage
• Any operation where sequential calls would take too long or risk throttling

Setup API Keys

Tenovi API keys are scoped to a client account (CLIENT_DOMAIN). You can create multiple API keys for the same account in the Tenovi Web App, each key maintains its own rate limit bucket. By distributing work across keys in parallel workers, you multiply your effective throughput.

Work Queue
    ├── Worker 1 → API Key A → Tenovi API
    ├── Worker 2 → API Key B → Tenovi API
    ├── Worker 3 → API Key C → Tenovi API
    └── Worker N → API Key N → Tenovi API

Note

Each API Key has a rate limit of 1 request per second. All requests to the API must be performed over HTTPS.

Patterns

Two common patterns for working with parallel processing are using worker pools with key rotation, and queue-based with a key pool.

Worker Pool with Key Rotation

The safest approach is a fixed worker pool where each worker is pinned to a single API key. This avoids key contention and makes rate limit errors easy to attribute to a specific worker.

Queue-Based with Key Pool

For larger jobs or jobs that need retry logic, use a shared queue with a pool of workers that each pull from the queue and use their own key.

Error Handling Rate Limit Responses

If you receive a 429 Too Many Requests response:

1. Stop sending requests on that key immediately.
2. Wait before retrying — use exponential backoff starting at 2 seconds.
3. Do not switch to another key to bypass the limit. Each key has its own bucket; rotating keys does not reset a rate limit on the key that was throttled.

Tracking Results and Failures

Always persist results as you go rather than at the end. For large batches, encountering an erro mid-run would lose all progress otherwise. Retry failed items as a separate pass before escalating.

Considerations

Key security Store API keys in environment variables or a secrets manager. Never hardcode them in source files.

Idempotency Tenovi device activation is not idempotent by default. If a request succeeds but your system does not record it (e.g., due to a crash), retrying will create a duplicate device. Check for existing devices by patient__external_id or hardware_uuid before retrying a failed activation.

Order sensitivity If your operations have dependencies (e.g., create patient before activating device), do not parallelize across dependency boundaries. Parallel processing is safe for independent, same-type operations.