A capture tool called ApiCatcher shipped something quietly interesting this year: an open real-time sync protocol. The team spent about half a year building an HTTPS debugger across iOS, Android, Windows, and macOS, plus a Burp Suite plugin that streams HTTP/HTTPS traffic off a mobile device in real time. Then they went one step further and opened the sync protocol itself, so users could write their own receiving end instead of depending on the Burp plugin. That last decision came from a user request, and it's the part worth paying attention to if you build tools.
Here's why. A mobile HTTPS debugger has two halves. One half captures traffic on the device, installs certificates, intercepts TLS, and does all the platform-specific work that only a signed native app can do. The other half receives whatever the capture side streams out, stores it, and lets you look at it. The capture half is genuinely hard to reproduce, and it's not something you rebuild on a hosting platform. But once a protocol is open, the receiving half becomes a plain data-ingestion problem. That's the reusable seam.
What you can actually build, and what you can't
Let me be clear about the boundary up front, because it matters. You cannot rebuild the capture-and-interception side on VicroCode. There's no native mobile app, no certificate handling, no on-device TLS interception in the confirmed capability set. If that's what you need, you need ApiCatcher's app or something like it. State that honestly to anyone you hand this to.
What you can build is the receiver: the endpoint that sits on the other end of the sync protocol, accepts streamed records, and turns them into something inspectable. That's a Burp-plugin-style receiver without the plugin, and it lands squarely inside what the platform supports.
The shape of it is three moving parts:
- A hosted endpoint that ingests streamed HTTP/HTTPS records over the sync protocol
- A durable ledger that stores each record in a queryable form
- A viewer you can open in a browser to read what came through
The ingest endpoint
The front door is a Python backend hosted as an API endpoint. It takes whatever the capture side pushes over the protocol, parses each record into fields you care about (method, URL, headers, status, timing, body), and writes it down. Because you can run Python online as a hosted service, you don't stand up a server or wire deployment; the endpoint is the deliverable.
One thing to decide early is how strict you are about the payload. The sync protocol defines what a record looks like, so validate against that rather than trusting arbitrary input. Treat every incoming record as untrusted data, cap body sizes, and don't let a malformed record take down the ingest loop. A receiver that silently drops one bad record and keeps going beats one that crashes on the first surprise.
A word on access control, since this endpoint is network-exposed: an open ingest URL with no auth means anyone who finds it can write into your ledger. Put a shared secret or token check on the endpoint before you point a real device at it. This isn't optional if the data is anything you'd rather not have polluted or read by strangers.
The SQLite ledger
Each parsed record goes into a SQLite table. This is the part that makes the whole thing useful instead of a firehose you can't read. A row per request, columns for the fields you extract, timestamps so you can order and filter. SQLite is a good fit here because the workload is append-heavy writes and read-oriented inspection, and you don't need anything heavier.
Having a real SQLite editor alongside the database matters more than it sounds. When something looks wrong in the viewer, you want to open the raw table, run a query, and see exactly what got written without adding debug code to the endpoint. It also lets you prune, correct schema mistakes, and spot-check that your parser is populating fields the way you expected. Treat the ledger as the source of truth and the viewer as one way to read it.
The viewer
The last piece is a hosted HTML page that reads the ledger and lays records out for a human: a list you can scan, filters by host or status, a detail pane for headers and body. Nothing exotic. You can run HTML online and publish the viewer as its own hosted page, backed by a small read API over the SQLite ledger.
Keep the viewer read-only. It's for inspection, not mutation, and separating the write path (ingest endpoint) from the read path (viewer) keeps the design honest and easier to reason about. If you want editing, that's what the database editor is for.
Why this is a reasonable thing to build
The evidence here is a single builder's account, so treat any claim about ApiCatcher's adoption, performance, or user base as unverified. What's concrete is the design decision: they opened the sync protocol specifically so people could write their own receivers. That's an invitation, and it's the kind of seam that pays off for a solo dev.
You get a debugging surface tailored to how you work, an inspectable ledger you own rather than a UI you're stuck with, and a clean division of labor where the hard native capture stays in the app and the flexible receiving side lives where you can shape it. You could keep it private, share the viewer with a teammate, or publish it. Just don't oversell it. The interception boundary is real, and stating it plainly is part of building something people can trust.