Dexcom Share API in production 2026: what the guides leave out
TL;DR
The Dexcom Share API is where many CGM products end up in 2026, because Dexcom's official v3 API delivers US glucose data one hour late. Share is near real time, has no public developer contract, and breaks in production in ways integration guides skip.
- Dexcom publishes no Share rate limit. A G7 sends a reading every 5 minutes, so faster polling buys nothing.
- Failed logins are the documented cause of lockouts, which usually last 10 to 15 minutes.
- By late June 2026 Nightscout had patched a Share login response that changed shape and left its connector reporting zero failures while data stopped.
- Hide error codes. Never hide the age of the last reading.
- Dexcom's Terms of Use restrict third-party access, and Dexcom is not reviewing new US partner applications except for Stelo. Clear Share with counsel first.
Why CGM products end up on Dexcom Share
Dexcom's v3 API is OAuth 2.0 and capped at 60,000 calls per app per hour. Its endpoint overview adds the catch: app-uploaded data arrives one hour late in the United States and three hours late elsewhere. Fine for a trend chart. Wrong for a parent watching a child's overnight low.
The sensor is faster. ADCES lists the Dexcom G7 15 Day as sending a reading every 5 minutes, with up to 10 followers through Share. Dexcom's real-time Partner Web APIs, cleared by the FDA in July 2021, are invitation only, and Dexcom's partner page says US applications other than Stelo are not being reviewed. That gap explains a common build order: prototype on the v3 sandbox, hit the delay, wire in Share through Nightscout or pydexcom, launch. The trouble starts after.
June 2026: Nightscout patched a silent Share failure
A fix in nightscout-connect, committed at the end of June 2026, records that newer Dexcom accounts, observed on G7, get {accountId: "<uuid>"} back from the Share call AuthenticatePublisherAccount where clients expected a bare UUID. The plugin kept logging RUNNING 0 failures 0 while Dexcom answered the next request with 500 InvalidArgument. Nothing flagged a failure. Readings just stopped.
Nightscout's plumbing is moving too. Its configuration docs mark the legacy Share bridge deprecated: from version 15.0.8, BRIDGE_* credentials go to Nightscout Connect by default, and a draft pull request would delete the old engine in 15.0.9. Self-hosting Nightscout? Check which engine polls.
How we checked these failure modes
Everything here comes from public sources read in October 2026. Dexcom publishes no developer documentation for Share, so for its behavior we cite the open-source code that copes with it.
The most detailed public Dexcom guide we found, last updated in August 2026, covers the v3 happy path well and never mentions Share or Nightscout. Mercury Development builds device-connected healthcare software, so read this as an agency's view with an interest in your project.
Seven CGM failure modes at a glance
| Failure mode | Path | What users see | What to build |
|---|---|---|---|
| Polling faster than readings arrive | Share | Nothing, while you risk an unpublished limit | One poller per account |
| Retrying failed logins | Share | A locked account | Zero retries on password errors |
| Response shape change | Share | A frozen last value | Schema checks, data-age alerts |
| Wrong regional host | Share and v3 | No data for accounts in other regions | Region stored per account |
| Refresh token race | v3 | A forced re-login | Per-user refresh lock |
| Client version bump | LibreLinkUp | Errors for everyone at once | Pinned version, canary account |
| Silent staleness | All | An old number that looks current | Reading age on every screen |
Share has no published rate limit, so set your own
Dexcom documents a rate limit for v3 and none for Share. That does not prove Share has none. If it has one, you find it in production.
Open-source clients behave as if one exists. Nightscout's legacy bridge waited 150,000 milliseconds between polls by default. In a 2021 Home Assistant forum thread, the reply on that integration's original 180-second default said it was chosen "to not run the risk of hitting any of the Dexcom Share API rate limits". pydexcom's constants cap a request at 288 readings: one day at one reading per 5 minutes.
So poll once per reading. Run one poller per Dexcom account, never one per follower or device, timed to the expected reading plus a small random offset, and serve every screen from your cache. Three caregivers' phones polling every 30 seconds cost Dexcom 360 calls an hour. One shared poller costs 12.
Failed logins lock accounts, so retries need rules
The documented lockout is about passwords. Nightscout's Share troubleshooting page warns that wrong credentials make Dexcom lock the account, and that the lock usually lifts after 10 to 15 minutes without bad attempts. pydexcom's error mapping names the codes: AccountPasswordInvalid, SSO_AuthenticateMaxAttemptsExceeded, SessionIdNotFound and SessionNotValid.
Generic retry middleware treats them alike. Don't. A session error deserves one re-login, which is what pydexcom does. A password error deserves zero retries: stop, flag the account, ask the user. A patient's password change breaks your stored copy at once. Per the pydexcom docs, Share also stays off until the patient adds at least one follower, so check during onboarding.
Endpoint and response changes fail silently
Share runs on three hosts, per the same pydexcom constants: share2.dexcom.com for the US, shareous1.dexcom.com outside it and share.dexcom.jp for Japan. The v3 API splits the same way across api.dexcom.com, api.dexcom.eu and api.dexcom.jp. Store the region with each account, as Nightscout's setup does for every user outside the USA.
Shape changes are worse, because they pass for success. The June 2026 wrapper surfaced as a 500 about deserializing a UUID, not as a login problem. pydexcom's README sums it up: "The Dexcom Share API sometimes changes."
So alert on the age of the newest reading per account, not on HTTP status. Validate every response against a schema and fail closed. Run a canary account through login and read on a schedule, so a shape change reaches your pager before a caregiver.
Hide the error code, never the age of the reading
Requirements often say "never show users an error". Half of that is right: a raw 500 means nothing to a parent at 3 a.m. The other half is dangerous, because a screen that keeps showing the last value looks healthy while it is wrong.
Upstream fails too. When Dexcom's servers were overloaded in late November 2019, Dexcom Follow was down from Saturday to late Monday, MedTech Dive reported. In September 2025 FDA posted a correction, identified as the most serious recall type, for Dexcom's own G7 and ONE+ apps: a design error ended sensor sessions without a "Sensor Failed" alert.
Dexcom's Follow app FAQ shows the better pattern: named states such as No Data and Disconnected, and a plain "The Dexcom server may be down." Nightscout's default stale-data alarms warn at 15 minutes and go urgent at 30. Show every reading's age, gray out a value after one missed reading, and keep technical detail in support logs.
The official v3 API fails differently
Moving to v3 removes the stored password and adds its own traps. Each refresh token "can be used only once", per Dexcom's authentication page, so two workers refreshing one user at once leave one of them holding a spent token and a 400. Treat that 400 as Dexcom advises, as a prompt to re-authorize, and you log out a user whose grant is fine. Lose the winner's new token and the grant really is gone. Lock refresh per user. US data is also an hour old by design, so give v3 its own staleness thresholds. Our Dexcom API integration guide covers the rest.
Libre's unofficial path breaks the same way
Libre usually arrives as LibreLinkUp, Abbott's follower service. The best-known uploader's release history reads like someone else's changelog: a fix for "connection errors starting November 2024", the LibreLinkUp version it reports bumped to 4.12.0 and then 4.16.0, a new way to obtain the account ID. Pin the version you send, alert on errors that hit every account at once, and treat an Abbott partnership as the commercial route.
Terms and FDA lines a Share-based product crosses
Two documents belong in your architecture review, and neither is technical.
Section 5.11 of Dexcom's Terms of Use, dated January 26, 2023, restricts enabling unauthorized third-party applications to access Dexcom services, sharing an account password or authorizing a third party to use the services unless Dexcom provides an approved mechanism, and automated access such as bots. Compare that with a backend that stores patients' passwords and polls for them. We are engineers, not lawyers: take section 5.11 to counsel.
FDA has a category for follower apps. Product code PJT, continuous glucose monitor secondary display, is Class II and exempt from 510(k) within limits, first classified in January 2015 for Dexcom's own Share apps. The special controls in 21 CFR 862.1350 still apply, including protection against unauthorized access to data and the label "Dosing decisions should not be made based on this device."
Which other frameworks apply once the product crosses the FDA line is shown in our comparison of healthcare compliance standards.
Which CGM data path fits your product
- Personal tools and internal prototypes: Share, with the safeguards above and a legal read of section 5.11.
- Trend dashboards and coaching: Dexcom v3, with the one-hour US delay shown honestly in the UI.
- Caregiver alerts a family relies on overnight: Dexcom's real-time partner APIs. Dexcom is not reviewing most new US applications, so ask before you build.
- Libre users at commercial scale: a partnership with Abbott. LibreLinkUp clients are for prototypes.
- Insulin dosing or treatment decisions: regulatory scoping before any integration work.
In an RPM program the CGM feed is one part of the backend, as our breakdown of remote patient monitoring architecture shows.
How we would harden a Share-based product
If counsel clears Share at all, treat it as a bridge with an expiry date, and make removing it a configuration change.
In practice: one internal reading record that knows its source, its region and its timestamp, with an adapter per source behind it. One poller and session cache per Dexcom account. Error classes mapped to actions. Data age as the metric on-call watches. A kill switch per source, and a written migration path to v3 or a partner API before launch.
We have built on interfaces we did not control before. On Kensington Proximo, Android had no built-in BLE support at the time, so the first app ran on a pre-release Samsung SDK that supported one phone, then reached more phones through Google's official BLE SDK in 2014. On Fitbit the team spent two months deciphering Samsung's proprietary Bluetooth technology to make sync work. On ORIGO the hardware maker's driver was unstable, so we wrote our own. We build to HIPAA and GDPR requirements, and the adapter is where those controls sit: encrypted credentials, an audit trail of reads, deletion on revoke.
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 CGM data path and we will show where it breaks
Tell us which sensors you support, how readings reach your backend today and who relies on them: the patient, a caregiver or a clinic. We will map where the current path can fail silently, what to monitor first, and which official route to move toward.