Dexcom CGM API integration
OnboardingThe adapter is implemented; the OAuth application is awaiting provider approval.
Dexcom is continuous glucose monitoring, and it is the provider whose data is most directly clinical. Interest has grown sharply beyond diabetes care — metabolic health, GLP-1 programmes and performance nutrition products all want CGM traces.
Two constraints define the integration. First, the developer API is deliberately delayed: readings are not available in real time, because Dexcom separates its clinical real-time pathway from its developer pathway. Any product promising live glucose alerts from the standard developer API is promising something it cannot deliver.
Second, glucose is regulated health data in most jurisdictions. Handling it puts you inside HIPAA, GDPR or DPDP obligations depending on where your users are, and the compliance posture of your data pipeline stops being optional.
How the Dexcom integration works
- Authentication
- OAuth 2.0 authorisation code, separate sandbox and production hosts
- Sync model
- Pull-based. Dexcom does not push.
- API base
- https://api.dexcom.com
- Integration type
- Cloud OAuth
Dexcom data available through WearLink
Everything below arrives in the shared normalised schema. The same field names and units apply whether the record came from Dexcom or from any other provider, so your scoring, charting and storage code is written once.
- Continuous blood glucose
- Glucose trend & rate of change
- Calibration events
- Device events
Webhook events you can subscribe to
blood_glucose.createdseries.blood_glucose.createdConnect a Dexcom user
Two calls: create a connect session for your end user, then read their normalised data. You never handle Dexcom OAuth credentials, token refresh or webhook registration.
# 1. Create a connect session for your end-user
curl -X POST https://wearlink.io/api/v1/connections/session \
-H "Authorization: Bearer $WEARLINK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"user_id": "'"$USER_ID"'", "provider": "dexcom"}'
# → { "connect_url": "https://wearlink.io/widget/connect?token=..." }
# Redirect the user there; they authorise dexcom and land back on your redirect_uri.
# 2. Pull normalised data whenever you want
curl -H "Authorization: Bearer $WEARLINK_API_KEY" \
"https://wearlink.io/api/v1/users/$USER_ID/summaries?provider=dexcom&days=7"What makes the Dexcom API hard to integrate directly
These are the things that turn an estimated one-week integration into a one-month one. They are worth knowing whether you use WearLink or build it yourself.
Developer data is delayed by design
The public developer API is not the real-time clinical feed. Do not design alerting or dosing features on top of it.
Sandbox and production are separate hosts
Different base URLs and different credentials. Promotion to production requires Dexcom review of your use case.
Glucose is regulated data
Storing CGM traces triggers health-data obligations. For Indian users that means DPDP, including data-residency expectations.
Dexcom API — frequently asked questions
- Can I build a real-time glucose alerting app on the Dexcom API?
- Not on the standard developer API — it is delayed by design. Real-time access is a separate clinical pathway with its own requirements.
- Is Dexcom available on WearLink?
- The adapter is implemented but the OAuth application is still in onboarding. /providers shows the live state.
- What compliance applies to CGM data?
- It depends on your users' jurisdiction — typically HIPAA in the US, GDPR in the EU, and DPDP in India, which additionally expects health data on Indian residents to be stored on Indian infrastructure.
Other integrations
Start with Dexcom — free for up to 3 users
No credit card. Create an account, add your provider credentials once, and your users connect through a hosted widget or our mobile SDK.