4 min read

Reverse engineering my pancreas: syncing Libre Link Up with my ecosystem

Table of Contents

I’ve been a Type 1 Diabetic since 2010, and if there’s one thing I’ve learned in over a decade of managing this condition, it’s that data silos are the enemy. I rely on Humalog and Levemir daily, but I also rely on data—lots of it.

For a long time, I wanted raw access to my Freestyle Libre 3 sensors. The official apps are fine for viewing, but I needed to own my data to build the ecosystem I actually wanted.

That ecosystem starts with a library I built called libre-link-unofficial-api.

Standing on the Shoulders of Giants

I didn’t start from scratch. A huge amount of credit goes to the libre-link-up-api-client by DiaKEM. Their work in reverse-engineering the API was foundational.

I decided to build my own implementation not to reinvent the wheel, but to learn. I wanted a complete, ground-up understanding of how the API worked so I could maintain it long-term and tailor it specifically to my stack.

The Library: A Technical Deep Dive

My implementation is a TypeScript client designed specifically for the Bun runtime. It handles the quirky authentication flow of the LibreLinkUp mobile app to give you programmatic access to your glucose levels.

  • Regional Routing: It automatically handles regional redirects (e.g., EU vs US servers) by querying the country configuration endpoint.
  • Streaming: Instead of messy setInterval loops, it uses async generators to stream readings.
// Stream readings every 90 seconds
for await (const reading of client.stream()) {
  const { value, trendArrow } = reading;
  console.log(`Glucose: ${value} mg/dL | Trend: ${trendArrow}`);
}

The Ecosystem: PAVMS

But the library is just the entry point. I didn’t want to hit Abbott’s servers every time I needed to check my sugar history.

I built a “relay”/“aggregator” system called PAVMS (Personal Aggregated Vitals Management System). libre-link-unofficial-api runs on a server, fetching data from the cloud and pushing it into PAVMS. PAVMS then acts as a central broadcast tower, exposing that data via a unified API to a suite of tools I built for myself.

Because I control the data pipeline, I could put my glucose readings everywhere:

  • VSCode Extension: I can see my blood sugar in the status bar while I’m coding, so I know if a syntax error is me or just low blood sugar.
  • Obsidian Extension: My personal knowledge base now has biological context.
  • Desktop Integration: I built custom taskbar icons for both Windows and Linux to keep readings at a glance.
  • Hardware Hacks: I even gutted an IKEA humidity sensor and rewired it to act as a physical blood glucose display that sits in my living room.

Gaia: The AI Medical Assistant

The crown jewel of this stack is Gaia, my custom mobile application.

Standard apps don’t know that my insulin sensitivity factor shifts dramatically throughout the day—from 3.0 in the morning to 1.5 at night. Gaia consumes the data from PAVMS, applies my specific correction factors, and runs a custom correction calculator.

I even integrated an AI medical assistant into Gaia. It summarizes my current status and allows me to chat with my health data. By decoupling the data fetching (libre-link-unofficial-api) from the logic (PAVMS/Gaia), I’ve built a system that adapts to me, rather than forcing me to adapt to a generic app.

Conclusion

When your pancreas is running on manual mode, precision is just another word for survival. By taking control of the API, I’ve stopped reacting to my diabetes and started engineering around it.

This library is my contribution to the open-source diabetes community. It includes integrity tests that run strictly every day at midnight to ensure the endpoints are still valid.

If you are a developer and a T1D patient looking to build your own custom solution, give it a try.

bun install libre-link-unofficial-api