How to Integrate the Dexcom API (2026)

Dexcom's API returns continuous glucose monitor (CGM) data, such as estimated glucose values and events, to apps that Dexcom users authorize. Access is staged: anyone can register and build against simulated data, but real users' data needs Dexcom's approval, first for a handful of test users and then for a commercial launch. Everything below is from Dexcom's developer documentation as read on October 17, 2026. For other connected health devices, see the Withings API guide.

Access and approval#

Dexcom describes three levels of access:

Dexcom splits Limited Access requests by who you are. Individual developers apply from the app's profile; commercial app developers submit a request for a commercial partnership through Dexcom's partnership questionnaire; research use goes through a separate research portal. Dexcom says it values every company that applies but reserves the right to decline apps that do not meet certain commercial and technical standards. Each app is reviewed on its own, so a second app needs its own upgrade.

Once an app has Full Access and at least one active Dexcom user within 60 days of public availability, the developer can apply to become a Dexcom Digital Health Partner and appear in Dexcom's Partnerships Gallery, which Dexcom says is not an endorsement. Dexcom also reminds developers that complying with all applicable regulations is their responsibility, and points to the FDA's Digital Health site for US rules.

Auth and scopes#

Dexcom uses OAuth 2.0 with the authorization-code flow, and requires partners to keep tokens and the client secret on their servers, never on a mobile device. Send the user to Dexcom's login:

GET https://api.dexcom.com/v3/oauth2/login
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.example.com/callback
  &response_type=code
  &scope=offline_access
  &state=RANDOM_ANTI_CSRF_STRING

code is the only response type and offline_access the only scope you can request. Behind that scope, the HIPAA authorization the user signs lists four kinds of data: estimated blood glucose levels, calibration data, events entry data and device details. Neither you nor the user can pick a subset.

The user logs in with their Dexcom account, signs the HIPAA authorization, and comes back with a code that is single-use and expires after one minute. Exchange it at https://api.dexcom.com/v3/oauth2/token:

curl -s -X POST "https://api.dexcom.com/v3/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d grant_type=authorization_code \
  -d code=AUTHORIZATION_CODE \
  -d redirect_uri=https://yourapp.example.com/callback \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET

Dexcom's example response has an access token with expires_in of 7200 seconds and a refresh token. Each refresh token works once: exchanging it issues a new one and invalidates the old, and a refresh token is valid for at most one year. A 401 on a data call means refresh; a 400 on a refresh means the token is dead, for example because the user revoked access or reset their Dexcom password, and the user must authorize again. Users revoke apps from Permissions in their Dexcom account, and Dexcom says data already provided to your app is not affected by the revocation.

Data: the v3 endpoints#

curl -s "https://api.dexcom.com/v3/users/self/egvs?startDate=2026-10-01T00:00:00&endDate=2026-10-02T00:00:00" \
  -H "Authorization: Bearer ACCESS_TOKEN"

The base URL depends on the user's region: https://api.dexcom.com in the US, https://api.dexcom.eu for the EU and outside the US, and https://api.dexcom.jp for Japan. The v3 API covers data from Dexcom G6, G7, G7 15-day, Dexcom ONE and Dexcom ONE+ devices; Dexcom ONE and ONE+ are not sold in the United States.

Four data rules shape every query:

• A 30-day window. Every endpoint except /dataRange needs startDate and endDate, and a window over 30 days returns 400. The window includes startDate and excludes endDate, and it is matched against systemTime.
• Two clocks. Records carry systemTime, the device's UTC time, and displayTime, what the user sees; Dexcom notes that systemTime is not true UTC because of drift and user changes.
• mg/dL only. Glucose values come in mg/dL and trend rates in mg/dL/min; converting to mmol/L is your job.
• Delayed data. Data uploaded from Dexcom's mobile apps reaches the API with a one-hour delay in the United States and three hours elsewhere, including Japan. Uploads from a receiver through Dexcom's uploader are available immediately.

Sandbox#

Every Registered Developer can call https://sandbox-api.dexcom.com with simulated users, named for the G6, G7, Dexcom ONE and G7 15-day apps, through the same OAuth flow, choosing the user from a drop-down instead of entering a password. Dexcom warns that sandbox data is not guaranteed to match production or to be permanent, and should not be used for formal testing, validation or training algorithms.

Rate limits and transport#

Dexcom limits requests to 60,000 calls per app per hour and returns 429 above that. The API requires TLS 1.3.

What changed recently#

Dexcom's developer documentation publishes no dated changelog. The current documentation describes the v3 API, with support for the G7 15-day sensor alongside G6, G7, Dexcom ONE and Dexcom ONE+.

Gotchas and production notes#

• The one-minute code. Exchange the authorization code immediately.
• All or nothing. The HIPAA authorization covers all four data scopes; there is no way to ask for less.
• Server-side only. Dexcom requires tokens on your servers, not in the mobile app.
• Mind the delay. A one-hour or three-hour delay is normal for app uploads, so do not treat a gap as missing data.
• Region-specific hosts. Send each user's calls to the right regional base URL.
• Limited Access is for testing. Five real users is the ceiling until Full Access.

The rest of the cluster is at how to integrate a fitness or health API.