Skip to content

Cloud OAuth

Dexcom CGM API integration

Provider onboardingThe adapter is implemented; the production OAuth application is awaiting provider approval.OAuth application pending

Dexcom device illustration

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.

Connect a Dexcom user

Two calls. The first mints a hosted connect URL for your end-user; the second reads the normalised summaries once they have authorised with Dexcom. Subscribe a webhook to receive the same objects as they land.

connect + read — dexcom
# 1. Create a connect session for your end-user
#    The API key goes in X-WearLink-API-Key, not in Authorization.
curl -X POST https://wearlink.io/api/v1/connections/session \
  -H "X-WearLink-API-Key: $WEARLINK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "'"$USER_ID"'", "provider": "dexcom", "redirect_uri": "https://yourapp.com/connected"}'

# → { "connect_url": "https://wearlink.io/widget/connect?token=...", "expires_in": 3600 }
# Redirect the user there; they authorise dexcom and land back on your redirect_uri.
# The token is scoped to that one user — it is safe to put in a browser URL.

# 2. Pull normalised data whenever you want
curl -H "X-WearLink-API-Key: $WEARLINK_API_KEY" \
  "https://wearlink.io/api/v1/users/$USER_ID/summaries?provider=dexcom&days=7"

Dexcom data available through WearLink

  • Continuous blood glucose
  • Glucose trend & rate of change
  • Calibration events
  • Device events

Webhook events you can subscribe to

  • blood_glucose.created
  • series.blood_glucose.created

Normalised families this provider feeds: Blood Glucose & CGM.

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.

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 consent and cross-border transfer analysis; for US users, HIPAA if a covered entity is involved.

FAQ

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. DPDP does not impose a blanket localisation rule, but cross-border transfers need a documented basis and sectoral regulators can add requirements. WearLink states exactly where it runs so that analysis starts from a fact.

Related

Other cloud integrations

Oura Ring API

Connectable now

The Oura Ring API (v2) is one of the cleaner wearable APIs to work with — the documentation is accurate and the daily-summary endpoints are stable. The complexity is not in reading it, it is in keeping it read: Oura backfills and revises data after the fact, so a sleep record you fetched this morning can legitimately change by this evening.

WHOOP API

Connectable now

WHOOP's developer API exposes the four objects the product is built around — cycles, recovery, sleep and workouts. The data is high quality and the model is coherent, which makes WHOOP a favourite for recovery and readiness products.

Fitbit API

Connectable now

Fitbit has the largest installed base of any dedicated wearable, which makes it the provider most consumer health products need first. It is also the API with the most historical baggage — the surface has accreted since 2011 and it shows in inconsistent date handling and endpoint shapes.

Strava API

Connectable now

Strava is the best-instrumented activity API in the consumer space and the only provider in the WearLink catalogue with a true push model — an activity upload triggers a webhook within seconds, not on a poll cycle. If your product cares about workouts rather than sleep or recovery, Strava is usually the fastest path to a working demo.

Withings API

Connectable now

Withings is the connected-scale and blood-pressure provider, which makes it the one that matters most for clinical-adjacent products — weight management, hypertension programmes, GLP-1 follow-up and remote patient monitoring. Its data is measurement-shaped rather than continuous: discrete readings taken when a user steps on a scale or straps on a cuff.

Garmin API

Provider onboarding

Garmin has the broadest data surface of any provider in the catalogue — if a metric exists in consumer wearables, a Garmin device probably measures it. For endurance, military, occupational-health and research use cases it is frequently non-negotiable.

Start with Dexcom — free for up to 3 users

No credit card. Your API key is issued at sign-up, and the hosted connect flow works from the first request.