How OneTwenty works

Overview

Diabetes management today is fragmented across device manufacturers — Abbott Libre, Dexcom, Medtronic, and Indian-made sensors each export data in proprietary formats. OneTwenty provides a single managed platform that ingests glucose readings from any CGM source, stores them in a normalised format, and exposes them through a unified API consumed by mobile apps, doctor dashboards, ambient displays, and AI-driven health assistants.

The platform is built on a Nightscout-compatible API surface, meaning existing uploaders, widgets, and integrations (xDrip+, Juggluco, Spike App, etc.) work without any modifications. Each customer — an individual patient, a clinic, or a research study — gets a fully isolated tenant environment hosted under their own subdomain.

System architecture

The platform is composed of four logical tiers: device clients that push readings, an edge / routing layer that resolves tenant identity from the incoming hostname, an API tier that validates, normalises and persists data, and an AI layer that runs asynchronously on stored data to produce insights.

Request lifecycle

When a client makes any API call, the following sequence runs before any business logic:

1. DNS resolves the subdomain (patient.onetwenty.dev) to the shared origin via wildcard record.
2. The Host header is extracted and matched to a tenant record in the routing table.
3. The API secret or JWT is validated against that tenant's credentials only — cross-tenant auth is architecturally impossible.
4. A tenant_id claim is attached to the request context and every MongoDB query is scoped to it.

Multi-tenancy & DNS

Every tenant — whether a single patient or a clinic running hundreds of patients — gets a dedicated subdomain. A single wildcard DNS record (*.onetwenty.dev → origin) covers all tenants without any per-customer DNS provisioning.

Why subdomain-per-tenant

• Uploader compatibility. Every Nightscout-compatible uploader expects a distinct base URL — subdomains preserve that contract while sharing infrastructure.
• Browser cookie isolation. Session cookies and local storage are automatically scoped to the origin. No extra work required.
• Operational clarity. Logs, metrics, and alerts can be filtered by hostname without parsing token payloads.

Data plane

The data model centres on two collections: entries (glucose readings, sensor calibration data) and treatments / events (insulin doses, meals, exercise, notes). The API is a strict superset of the Nightscout v1 surface.

Core endpoints

Normalisation on write

When an entry arrives via POST, the API normalises the timestamp chain before storage: the incoming dateString (ISO-8601 with UTC offset) is parsed, the UTC offset is stored separately as utcOffset, and a canonical UTC sysTime is computed. Upserts are keyed on (sysTime, type, tenant_id) — duplicate uploads from retried connections are silently merged.

# Retrieve the last 24 hours of glucose readings
curl -sS \
  -H "api-secret: <your-secret>" \
  "https://<tenant>.onetwenty.dev/api/v1/entries?hours=24&count=288"

# Combined entries + events for a report window
curl -sS \
  -H "api-secret: <your-secret>" \
  "https://<tenant>.onetwenty.dev/api/v1/entries-with-events\
?start=2025-04-01T00:00:00Z&end=2025-04-08T00:00:00Z"

AI pipeline

The AI layer sits entirely outside the request path. It reads from the same API that clients use, assembles context windows, and produces structured outputs that are stored back as first-class data — not ephemeral chat responses.

Agentic flows

The mobile app exposes a conversational interface for logging treatments and querying personal glucose data. The agent follows a propose-confirm-persist pattern — it never writes to the API unilaterally.

Treatment logging

Conversational glucose queries

The chat copilot uses the same pipeline: query synthesis (layer 01) determines the time window and filters, context assembly (layer 02) fetches the relevant data, and the LLM answers within that bounded context. A WebSocket subscription optionally keeps the context fresh as new readings arrive during a live session.

Auth & security

Authentication is multi-strategy to support the range of clients — from existing Nightscout uploaders that only support a shared secret to the doctor portal which uses session-based JWT.

API quick-start — curl examples

Every endpoint accepts an api-secret header for authentication. Your API token and subdomain URL are visible in Settings → API access inside the OneTwenty app. Replace the placeholders below with your values to start integrating immediately.