Eight Sleep Controller
2025shippedReverse-engineered Eight Sleep's API to control my smart bed via hardware buttons instead of the iPhone app—complete with cert pinning bypass and TypeScript client.
// GitHub
// Problem
I wanted to control my Eight Sleep smart bed without reaching for my phone every time. The goal was simple: press a physical button next to my bed and have it adjust the temperature. But Eight Sleep only offers an iPhone app—no official API, no third-party integrations, no way to hook up a Raspberry Pi with hardware buttons. Their app also uses certificate pinning, which means standard proxy tools can't intercept the traffic to figure out how the API works. I was curious whether I could reverse-engineer their system and build my own controller.
// Solution
A complete toolkit for controlling Eight Sleep beds programmatically. First, I used mitmproxy and Charles Proxy to intercept traffic between the iPhone app and Eight Sleep's servers—writing custom Python scripts to bypass certificate pinning and capture authentication flows. Once I mapped out their OAuth endpoints and device control APIs, I built a TypeScript client that handles authentication, session management, and temperature control. The ButtonController class provides the framework to wire up physical hardware buttons (GPIO, USB HID, serial, wireless) that trigger temperature presets with a single press.
// What I Built
A reverse-engineering project that became a fully functional smart home integration. The core is SmartBedAPI—a TypeScript class that authenticates with Eight Sleep's OAuth system (supporting both auth-api and client-api endpoints), retrieves device information, and sets temperature on a -100 to +100 scale for both bed sides independently. The ButtonController wraps this with keyboard simulation for testing, but is architected to support GPIO buttons on Raspberry Pi, USB HID devices, serial communication, or wireless ESP32/Arduino controllers. I also built Python scripts for mitmproxy that log TLS connection attempts, capture authentication headers, and export traffic to JSON for analysis. The project includes comprehensive documentation of Eight Sleep's undocumented API endpoints—login flows, device discovery, temperature control, and status monitoring.
// Technologies
mitmproxy
Man-in-the-middle proxy for intercepting HTTPS traffic. Used with custom Python addons to bypass Eight Sleep's certificate pinning, capture OAuth flows, and document undocumented API endpoints
TypeScript + Bun
Built the SmartBedAPI client and ButtonController using TypeScript with Bun as the runtime—handling OAuth authentication, session tokens, and REST API calls to Eight Sleep's servers
Python
mitmproxy addons for TLS interception, logging certificate pinning failures, capturing authentication headers, and exporting traffic captures to JSON for analysis
Eight Sleep REST API
Reverse-engineered OAuth 2.0 authentication, device discovery endpoints, temperature control API (-100 to +100 scale), and real-time status monitoring across three API domains
Hardware Integration Framework
Architected ButtonController to support multiple input methods—GPIO interrupts for Raspberry Pi, USB HID events, serial port communication, and HTTP/WebSocket for wireless buttons
// Lessons Learned
- 01Certificate pinning isn't as scary as it sounds. Once I understood that apps embed expected certificates and reject anything else, the bypass approach became clear: intercept at the TLS layer, log what's being blocked, and use tools like Frida or rooted devices when needed. The Eight Sleep app's pinning was bypassable with mitmproxy's --ssl-insecure flag and custom addons.
- 02Reverse-engineering APIs is mostly pattern recognition. Eight Sleep uses standard OAuth 2.0 flows, predictable REST endpoint naming (/v1/users/{userId}/devices), and JSON payloads. Once I captured a few requests, the entire API surface became obvious. The hardest part was getting the initial traffic capture—everything after was just documentation.
- 03Interest-driven projects teach more than tutorials. I learned about TLS handshakes, certificate chains, OAuth token flows, and embedded systems integration—all because I wanted to push a button instead of open an app. The motivation made the complexity manageable.
- 04Building for hardware extensibility upfront was the right call. Even though I only tested with keyboard simulation, designing ButtonController to support GPIO/USB/serial/wireless meant the architecture was ready when I eventually got around to the Raspberry Pi setup. The abstraction cost nothing and enabled everything.