Endpoints

The following endpoints are available from the Dexcom API. For more information on how Dexcom devices generate this data, refer to the CGM introduction, Dexcom product page, and Dexcom product guides.

HTTP Method Endpoint Description
GET /v3/users/self/alerts Alerts
GET /v3/users/self/calibrations Calibration Entries
GET /v3/users/self/dataRange Data Range
GET /v3/users/self/devices Device Information
GET /v3/users/self/egvs Estimated Glucose Values
GET /v3/users/self/events User-Entered Events

The base URL of the endpoints depends on whether the request is targeting the production or sandbox environment.

The base URL for requests made to sandbox data is:

https://sandbox-api.dexcom.com

The base URL for requests made to production data in different geographic regions are:

  • US: https://api.dexcom.com
  • EU and Outside of US: https://api.dexcom.eu
  • Japan: https://api.dexcom.jp

To learn more about the difference between these environments and how to gain access, see the Scopes & Access section. All requests require a valid OAuth 2.0 bearer token; this token is obtained through the process detailed in the Authentication section.

Device Support

Only version 3 and above support patient data from G7 devices. If your current integration is using version 2 of the API, in order to get G7, G6 and Dexcom ONE device data you will need to update your integration to use version 3 endpoints.

Version 2 will continue to be accessible and will still support G6 and G5 generation devices.

G7 Data in the Sandbox Environment

In order to test with G7 data from the sandbox environment, you’ll need to use “SandboxUser7”. You’ll use the same process to connect and interact with the sandbox environment as outlined here.

Transport Layer Security

The Dexcom API requires the use of Transport Layer Security (TLS) version 1.2. You will need to verify that your environment supports TLS 1.2 and, if necessary, make appropriate updates.

Request Rate Limits

Request frequency is limited to 60,000 calls per app per hour. If the limit is exceeded, an HTTP 429 response will be returned. If you believe that your application requires additional capacity, send us a note using the Support Requests form.

Time

There are several notions of time to understand when handling and processing CGM data.

Dates and times are formatted according to the ISO 8601 standard.

For the /egvs, /calibrations, /events, and /dataRange endpoints, two separate fields describing time are provided: systemTime and displayTime. systemTime is the UTC time according to the device, whereas displayTime is the time being shown on the device to the user. Depending on the device, this time may be user-configurable, and can therefore change its offset relative to systemTime. Note that systemTime is not "true" UTC time because of drift and/or user manipulation of the devices' clock.

All requests, except those made to the /dataRange endpoint, require two query parameters—startDate and endDate—that specify a time window. This window can be a maximum of 30 days, and any request with a time window greater than 30 days will return a 400 (Bad Request) error. These are ISO 8601-formatted UTC timestamps, and therefore queries are executed against the systemTime field in the corresponding endpoint. The time component may be specified down to milliseconds. Queries are inclusive of startDate and exclusive of endDate.

Units

Where applicable, units are specified within the responses. At the moment, all glucose values are reported in units of mg/dL and trend rates in units of mg/dL/min. Conversion of these values into user-preferred units, such as mmol/L, is the responsibility of the client application.

Data Availability

Data uploaded from the G7® and G6® Mobile applications is available from the Dexcom API from one hour prior for the US server. Data uploaded from the G7®, G6®, and Dexcom ONE Mobile* applications is available from three hours prior for the OUS servers. Data uploaded directly from a receiver over USB via the Dexcom CLARITY® uploader is available immediately. For more information on this delay, please see the FAQ.

REST

The Dexcom API uses a RESTful architecture to provide programmatic access to authorized user data. This data is available as resources—such as /devices and /egvs—that are accessed using the standard HTTP methods GET and POST. Like most APIs, this one isn't fully RESTful by the strictest definition, but it does follow the common best practices and will be familiar to those who have developed against other web APIs.

JSON

The Dexcom API supports JSON. Responses are returned in JSON format, and POST requests require a valid JSON object for the body. Note that, for response fields that do not have a value, the field still appears in the response and null is returned as the value. Nullable fields are identified in the response field tables.

HTTP Response Status Codes

Responses are returned with a corresponding HTTP response status code. Some will be accompanied by additional explanations of the error type or cause.

Code Text Description
200 OK The request was successful
302 Found The requested resource resides under a different URL (used in redirect for authentication purposes)
400 Bad Request The request could not be understood by the server
401 Unauthorized The request requires user authentication
404 Not Found The server cannot find anything matching the request URL
429 Too Many Requests The request rate limit has been exceeded
500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request

*Dexcom ONE and ONE+ are only available in select countries.