cyphr.
All deep dives
AutomationNov 20248 min read·Self-directed

Router Management API Bot

Headless Browser Automation

A RESTful API that puts programmatic control of a home router in reach, driving the router's own undocumented web UI through a headless browser when no official API exists to call instead.

Duration
6 weeks
Year
2024
Status
Shipped
Type
Self-directed
Think of it this way

Think of it like a tireless assistant filling out the router's own website — clicking the same menus a person would, just in under a second and without ever getting bored or logging you out.

The challenge

The router only exposes a web admin panel — no public API. Reverse-engineering that undocumented interface meant keeping a session alive across requests, waiting out dynamic element loads, and getting past authentication dialogs without a human at the keyboard.

The approach

A persistent Puppeteer instance drives the panel directly: scripted DOM interactions replace clicking through menus, dialog handlers clear the popups that would otherwise stall a headless run, and encrypted session-based credentials keep the bot logged in across calls.

Built with
Node.jsExpressPuppeteerexpress-validatorSession Management
View source
CYPHR · ROUTER_MANAGEMENT_APIask about this build
Want something like this built for you?
$
The write-up
01

Why not just use an API

Consumer routers almost never ship one. The manufacturer's admin panel is the only interface, and it assumes a human with a mouse. Anything you want to automate — blacklisting a device, pulling connection stats, restarting an interface — means either flashing custom firmware or driving the panel the way a person would. Custom firmware voids warranties and breaks on model changes. Driving the panel is uglier but survives.

02

Keeping a session alive

The panel expires sessions aggressively and re-authenticates through a modal rather than a redirect, which breaks most naive automation. The fix was a persistent browser context with an interceptor that detects the auth modal, re-submits stored credentials, and resumes the interrupted action — so a caller hitting the API never sees the difference between a warm session and a cold one.

03

Dialogs that stall headless runs

Confirmation dialogs are invisible in headless mode but still block execution. Every destructive action needed a registered dialog handler before the click that triggers it, not after — a race condition that took longer to diagnose than it did to fix. That single ordering issue accounted for most of the early failure rate.

04

Credential handling

Storing router credentials in plaintext to automate a router is a bad trade. Credentials are encrypted at rest, decrypted only into the browser context, and never logged — including in error traces, which is where they usually leak.

What it did
Automated 7+ router management functions via clean API endpoints
Cut a 5+ minute manual process to under 10 seconds
95% success rate across 50+ test operations
Ethical credential handling with encrypted session storage
Runs fully headless — deployable on a server with no display
What I'd tell myself
01Register dialog handlers before the action that triggers them, not after
02Undocumented UIs change without warning — selector resilience matters more than elegance
03Encrypted-at-rest is table stakes the moment you store someone else's credentials