Dexcom API Integration: A Developer's Guide to CGM Data in Health Apps

Building a health app that reads continuous glucose data from a Dexcom device requires navigating two separate systems: the technical API and the partner access program. Both have their own requirements and timelines, and the order in which you handle them matters.

This guide covers the full integration path: registering as a developer, authenticating users with OAuth 2.0, querying the right endpoints, handling the data your app receives, and preparing for production. It also addresses the multi-CGM question, because Dexcom is the most developer-accessible CGM platform, but it is not the only one your users will own.

The Dexcom Developer Program

All Dexcom API access starts at developer.dexcom.com. Register an account, create an app, and you get immediate Sandbox access. No approval required.

The program has three tiers:

Sandbox. Full access to simulated CGM data across all endpoints. Enough to build and test the entire integration before touching any real patient data. Sandbox data mirrors production response formats, so anything you write against the sandbox transfers directly.

Limited Access (production). Up to 5 authorized users on your app in the production environment. Available to individual developers after a short self-service upgrade. Useful for building a working prototype with real devices before pursuing commercial partnership.

Full Access (commercial partnership). Required before you can ship to users at scale. Triggered by completing Dexcom's Partnership Interest Questionnaire and signing a non-negotiable Data Licensing Agreement. The Strategic Partnerships team reviews applications. Expect weeks, sometimes months. Plan for this timeline early.

If your app is a commercial product with more than a handful of users, you need the full partnership path. Budget the review time into your roadmap.

Authentication: OAuth 2.0

Dexcom uses standard OAuth 2.0 Authorization Code flow. Users authenticate directly with Dexcom, and your app receives tokens. You never handle Dexcom credentials.

Endpoints:

Authorization URL parameters:

client_id=YOUR_CLIENT_ID
redirect_uri=YOUR_REDIRECT_URI
response_type=code
scope=offline_access
state=RANDOM_CSRF_TOKEN

One thing to be aware of: Dexcom does not support granular scope selection. Your app requests offline_access and gets access to all available data for that user. There is no way to request read-only glucose access without also having access to calibrations and events. Design your data handling accordingly, and only store what your app actually needs.

Token exchange (POST to token endpoint):

grant_type=authorization_code
code=AUTHORIZATION_CODE
redirect_uri=YOUR_REDIRECT_URI
client_id=YOUR_CLIENT_ID
client_secret=YOUR_CLIENT_SECRET

The response includes access_token, refresh_token, and expires_in. Access tokens expire after 10 minutes. Refresh tokens are long-lived. Store refresh tokens securely and implement automatic refresh logic before building any data-reading features.

Core Endpoints

All v3 endpoints follow the same pattern:

GET https://api.dexcom.com/v3/users/self/{endpoint}
Authorization: Bearer {access_token}

Required query parameters for time-ranged endpoints:

• startDate: ISO 8601 datetime, e.g. 2025-01-01T00:00:00
• endDate: ISO 8601 datetime

Maximum query range is 90 days. Data retention is also 90 days.

/egvs — Estimated Glucose Values

The primary endpoint. Returns CGM readings at approximately 5-minute intervals.‍

{
  "egvs": [
    {
      "systemTime": "2025-01-15T14:05:00",
      "displayTime": "2025-01-15T09:05:00",
      "value": 112,
      "realtimeValue": 112,
      "smoothedValue": 111,
      "status": null,
      "trend": "flat",
      "trendRate": -0.2
    }
  ],
  "unit": "mg/dL",
  "rateUnit": "mg/dL/min"
}

Key fields:

• value: Current glucose in mg/dL. For mmol/L conversions, divide by 18.
• trend: One of doubleUp, singleUp, fortyFiveUp, flat, fortyFiveDown, singleDown, doubleDown, notComputable, rateOutOfRange. Use this for directional alerts and coaching logic.
• trendRate: Rate of change in mg/dL per minute. Negative means falling, positive means rising.
• status: Will be non-null when the sensor returns a special reading (e.g. "high" for values above 400 mg/dL or "low" for values below 40 mg/dL). Always check this before using value.
• systemTime vs displayTime: systemTime is UTC. displayTime is the user's local timezone. For clinical logging, use systemTime. For display, use displayTime.

/devices — Device Information

Returns the devices associated with the user's account: transmitters, receivers, and mobile apps.

{
  "devices": [
    {
      "transmitterGeneration": "g7",
      "displayDevice": "iOS",
      "lastUploadDate": "2025-01-15T14:10:00",
      "alertScheduleList": [...]
    }
  ]
}

Useful for displaying connection status and for routing your app logic based on sensor generation. G7 has different warmup behavior and data availability patterns than G6.

/dataRange — Available Data Window

Returns the earliest and latest timestamps for each data type. Call this before querying historical data to avoid empty requests.

{
  "calibrations": {
    "start": { "systemTime": "...", "displayTime": "..." },
    "end": { "systemTime": "...", "displayTime": "..." }
  },
  "egvs": {
    "start": { "systemTime": "...", "displayTime": "..." },
    "end": { "systemTime": "...", "displayTime": "..." }
  }
}

Build your historical sync logic around this endpoint rather than guessing date ranges.

/events — User-Logged Events

Returns exercise sessions, meals (carbohydrate intake), insulin doses, and health events logged by the user.

{
  "events": [
    {
      "eventType": "carbs",
      "eventSubType": null,
      "value": 45,
      "unit": "grams",
      "systemTime": "2025-01-15T12:00:00",
      "displayTime": "2025-01-15T07:00:00"
    }
  ]
}

Event data is only available if the user actively logs in the Dexcom app. Treat it as sparse. Build glucose-only features first, then layer event correlation.

/calibrations — Sensor Calibrations

G6 sensors support optional calibrations. G7 does not require or accept calibration. The endpoint still exists for G7 but returns empty data. Check the device generation from /devices before calling this.

Error Handling

Dexcom API errors follow standard HTTP codes:

The 404 case is common and not an error state. A user who has not worn their sensor for the past week will return 404 for that date range. Handle it cleanly in your UI.

Production Architecture Considerations

Data freshness. The Dexcom API is not a real-time push system. You poll for new data. For near-real-time use cases (alerts, live dashboards), poll /egvs every 5 minutes, aligned with sensor transmission cadence. More frequent polling does not return additional data and consumes rate limit budget.

Incremental sync. On first load, pull the full 90-day history using /dataRange to scope the query. On subsequent polls, request only the delta from the last known systemTime.

Token storage. Refresh tokens are long-lived credentials tied to a user's health data. Store them encrypted, never in application logs, and implement rotation on refresh. This is a PHI handling requirement, not just good practice.

Webhook alternative. Dexcom does not provide webhooks in the standard partner program. Polling is the only option unless you are working under a specialized enterprise arrangement.

HIPAA and CGM Data

Continuous glucose readings are Protected Health Information. Any system your app uses to store, process, or transmit Dexcom data needs a signed Business Associate Agreement (BAA) with each service provider: cloud infrastructure (AWS, GCP, Azure all offer BAAs), databases, logging services, and analytics platforms.

Three specific risks to address before production:

Log scrubbing. Application logs that capture API responses will contain glucose values and timestamps. Either disable response logging for Dexcom endpoints or implement automatic scrubbing before log storage.

Data minimization. The Dexcom API returns more data than most apps need. Only store fields your application actually uses. Storing raw API responses as a catch-all creates compliance surface area.

Data retention. Define explicit retention periods for user glucose data and build deletion flows that work. Users removing authorization from Dexcom should trigger data deletion in your system, not just token revocation.

Supporting Multiple CGM Providers

Dexcom G6 and G7 cover a significant share of the CGM market, but not all of it. Abbott FreeStyle Libre has comparable market penetration, particularly outside the US, and is increasingly common in clinical studies. Stelo, Dexcom's consumer-tier device, operates under different API access rules.

Building directly against the Dexcom API works for a Dexcom-only product. It becomes expensive to maintain when users arrive with Libre 3 or Stelo devices and expect the same feature set.

A unified data layer abstracts across providers: one authentication flow, one data model, one set of business logic for glucose processing. The tradeoff is an additional dependency in the stack. Whether that dependency is worth it depends on how many devices you intend to support and how quickly.

Open Wearables is an open-source platform that provides a unified API across CGM and other wearable data sources, including Dexcom and Apple Health. If your app needs multi-device support, it handles provider normalization so your application code works against a single glucose schema regardless of the source device.

What "Integration Complete" Actually Means

A working Dexcom integration is not just a functioning OAuth flow and a successful /egvs response. Before production, verify

• Refresh token rotation works and does not lock users out
• Token expiry during active sessions is handled transparently
• The status field on EGV responses is checked before using value
• Empty date ranges (404) are handled without error states in the UI
• Glucose values above 400 and below 40 are displayed correctly, not as numeric anomalies
• The 90-day data retention limit is communicated to users in the product
• HIPAA controls are in place before the first real user connects their device

The sandbox environment covers most of these scenarios with simulated edge case data. Use it before requesting Limited Access production credentials.