Dexcom API integration guide 2026: CGM data paths that hold up
TL;DR
Dexcom API integration in 2026 means the v3 API: OAuth 2.0 with two-hour access tokens and single-use refresh tokens, glucose data delayed one hour in the US and three hours elsewhere, query windows capped at 30 days, and a limit of 60,000 calls per app per hour. That is a retrospective feed, not a live stream. Real-time access and Abbott's Libre data both run through partnerships.
- Dexcom's notice ended G6 manufacturing on July 1, 2026. Code on v2 records serves a shrinking population.
- Polling cadence sets your scale. One glucose call per user every 5 minutes caps an app near 5,000 connected users.
- A public guide updated in August 2026 still prints v2 URLs, a 10-minute token and a 90-day window.
- Share and LibreLinkUp routes are community reverse engineering.
Where CGM data lives in 2026
Start with the two manufacturers this guide covers. Dexcom reported full-year 2025 revenue of $4.662 billion, up 16%, and launched the G7 15 Day system in the United States. Abbott says more than 7 million people use Libre across over 60 countries.
Neither number tells you how a reading reaches your backend. It comes from the manufacturer's cloud, from the phone through Apple Health, or from the clinic, where Abbott announced in April 2025 that LibreView accounts can link automatically into Epic. Each route has its own delay and an owner who can change the terms without asking you.
The G6 left production on July 1, 2026
Dexcom states that the G6 will no longer be manufactured starting July 1, 2026.
That matters for code. Dexcom's v2 glucose reference describes record behavior for G4, G5 and G6 devices; G7 is not mentioned on that page. The v3 endpoint overview covers G6, G7, G7 15 Day, Dexcom ONE and ONE+, and the v3 glucose record reports a transmitterGeneration that includes g7 and g715day. An app still calling /v2 was built for a sensor leaving the shelf.
How we checked this guide
Every Dexcom limit below comes from Dexcom's developer pages as they read in October 2026. Engineering examples are our own published cases.
Mercury Development builds device-connected and healthcare software, so this is an agency-authored guide with an interest in your project. The most detailed public alternative we checked handles error codes and regional delays well. Where its figures differ from Dexcom's current v3 pages, we show both.
Six CGM data paths at a glance
| Path | Who grants access | Freshness | What breaks it |
|---|---|---|---|
| Dexcom v3 API | Dexcom, in tiers | 1 hour US, 3 hours elsewhere | Token races, v2 leftovers |
| Dexcom real-time partner APIs | Dexcom, by invitation | Real time | Invitation scope |
| Dexcom Share libraries | Nobody; patient login | Near real time | Service changes, lockouts |
| Libre through Abbott | Abbott, named partners | Not published | Partnership terms |
| Apple Health | The user, one iPhone | 3 hours for G7 | Your app must run |
| EHR via LibreView or FHIR | The health system | Clinic cadence | Onboarding |
Only the first row is open to any registered developer.
Dexcom v3 auth: two-hour tokens, single-use refresh
v3 uses the OAuth 2.0 authorization code flow at /v3/oauth2/login and /v3/oauth2/token on api.dexcom.com, with offline_access as the only accepted scope, per Dexcom's authentication page. The sample token response sets expires_in to 7200 seconds. Refresh tokens last up to one year, and each "can be used only once".
That sentence bites in production. Two workers refresh the same user at once, the second presents a spent token, and the grant is gone until the user logs in again. Lock refresh per user, persist the new refresh token first, and schedule re-consent before the year runs out. v3 also requires TLS 1.3, which older gateway stacks fail.
Endpoints, 30-day windows and the one-hour delay
v3 exposes six read endpoints under /v3/users/self: alerts, calibrations, dataRange, devices, egvs, events. Data arrives one hour late in the United States and three hours late elsewhere. A request covers at most 30 days, dataRange excepted, so backfill means reading dataRange first and walking the span in 30-day slices.
Inside egvs, three details keep charts honest:
- Values arrive in mg/dL and trend rates in mg/dL/min. Conversion to mmol/L is the client's job.
- 39 means below 40 and 401 means above 400. Dexcom uses both in calculations but not on screen, so render LOW and HIGH.
- Mobile app records carry a UTC offset in
systemTimeanddisplayTime; receiver records do not. Normalize before you sort.
The rate limit is a polling budget
Dexcom caps traffic at 60,000 calls per app per hour and answers the excess with HTTP 429. The cap is per app, so cadence sets your user count. Our arithmetic, one egvs call per poll:
| Polling per user | Calls per user per hour | Users under 60,000 calls |
|---|---|---|
| Every 5 minutes | 12 | 5,000 |
| Every 15 minutes | 4 | 15,000 |
| Every hour | 1 | 60,000 |
US data already lags an hour, so a five-minute poll buys one reading from an hour ago, while an hourly poll collects the same twelve in one call. Spend the spare budget on backfill.
Figures older guides still repeat
| Figure | Guide updated August 2026 | Dexcom v3 pages today |
|---|---|---|
| OAuth paths | /v2/oauth2/login, /v2/oauth2/token | /v3/oauth2/login, /v3/oauth2/token |
| Access token lifetime | 10 minutes | 7200 seconds |
| Maximum query range | 90 days | 30 days |
That guide, last updated in August 2026, prints the middle column. Those values may fit v2, not v3, the version that knows about the G7. The record shape differs too: v2 splits realtimeValue from smoothedValue, v3 returns one value. A v2 parser in a v3 client fails quietly.
Sandbox, five users, then a partnership review
Registration is free, and every app gets a sandbox of simulated accounts. Per Dexcom's scopes and access page, Limited Access authenticates up to 5 real users for testing. Dexcom's Strategic Partnerships team reviews the request, and approval comes with "a standard, non-negotiable Data Licensing Agreement". Full Access, required before launch, adds a questionnaire and a technical and commercial review. Dexcom publishes no timeline, so apply as soon as the sandbox build works.
Real time is a separate door. In July 2021 the FDA cleared the Dexcom Partner Web APIs for invited third-party developers; Garmin and Livongo were named as early testers.
Share and Nightscout are not a developer contract
Dexcom Share is near real time, needs no approval and runs on the patient's own credentials. pydexcom, a community library, needs Share switched on with at least one follower and warns that "The Dexcom Share API sometimes changes". Nightscout's Share bridge page asks for the account holder's password and notes that wrong logins lock the account, usually for 10 to 15 minutes.
Read that as a spec: you store a patient's password, depend on an interface with no published contract, and a careless retry loop locks users out. Keep Share behind an adapter and cap retries hard.
Libre data reaches you through partners
Abbott's partner integrations page lists named partners, mostly insulin delivery such as Omnipod 5 and Tandem t:slim X2, plus Omada Health, and describes no application process for developers. For clinics, the April 2025 Epic agreement links LibreView data into charts for more than 575,000 US providers.
The unofficial route is the LibreLinkUp sharing API. Its best-known community documentation disclaims any Abbott affiliation and was archived by its owner on May 13, 2024. For a commercial product, Libre support starts with Abbott, not a repository.
Apple Health and the EHR are secondary paths
Apple Health is the easiest Dexcom path on iOS and the slowest: Dexcom says Apple Health receives G7 data after a three-hour delay. Fine for trends, wrong for alerts.
Into the chart, HL7 publishes the Continuous Glucose Monitoring implementation guide, version 1.0.0, STU 1, on FHIR R4. A patient app authorizes with SMART on FHIR and posts a bundle to the EHR's $submit-cgm-bundle operation, with profiles for readings and summaries such as time in ranges and glucose management indicator. Code readings with LOINC 99504-3, glucose in interstitial fluid.
The international consensus on time in range recommends 14 days of data with 70% of possible readings, and more than 70% of time between 70 and 180 mg/dL. Show nothing when that sufficiency rule fails.
The Apple Health and Health Connect side, with aggregators such as Terra, is compared in health data integration for fitness apps.
Where HIPAA stops and the FTC rule starts
Which law governs glucose data depends on who holds it. A covered entity, or its business associate, works under HIPAA. A direct-to-consumer app usually falls under the FTC's Health Breach Notification Rule, whose amendments, effective July 29, 2024, clarified its coverage of many health app developers. It counts an unauthorized disclosure as a breach, so an analytics SDK that forwards readings to an ad platform can trigger notices due within 60 calendar days.
FDA classifies an integrated CGM as Class II with special controls, able to "reliably and securely transmit glucose measurement data to digitally connected devices". Drive an alarm or a dose from a reading and you need a regulatory assessment before an architecture.
Once a reading drives an alarm or a dose, start the regulatory assessment from our comparison of healthcare compliance standards.
Which data path fits your product
- Wellness or coaching that tolerates hours of lag: Apple Health first, Dexcom v3 once you need history across devices.
- Remote monitoring or clinical review: Dexcom v3 with Full Access, a FHIR route into the EHR, Libre through Abbott.
- Caregiver alerts on the current reading: Dexcom's partner APIs or an Abbott partnership. Share is a prototype.
- Insulin dosing or decision support: regulatory scoping first. Integration follows from it.
In an RPM program the data path is one part of the backend, as our breakdown of remote patient monitoring architecture shows.
What we would build first
Build the adapter layer before the second vendor. One internal glucose record carrying source, sensor generation, unit, normalized time and a sufficiency flag. One adapter per vendor behind it. One token store with per-user locks.
Vendor interfaces move. On Fitbit, our client since 2011, early Android phones lacked Bluetooth 4.0, and we spent two months deciphering Samsung's proprietary technology to make the tracker sync. On Tonal we built the Apple Health integration that keeps data in step across the watch app, the phone app and the trainer. The vendor decides the interface; you decide how much depends on it.
We build to HIPAA and GDPR requirements, and the adapter is where they live: an audit trail of who pulled which readings and deletion when a user revokes the grant. One limit: adapters buy nothing if you will only ever support Dexcom.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder.
Send us your sensor list and we will map the data paths
Tell us which sensors your users wear, where you ship, and what the data has to do: show a trend, raise an alert or land in a chart. We will come back with the paths that fit, the access each one needs, and what we would keep behind an adapter.