Opening our API, or: how we learned to stop worrying and love other people's code.

Every platform team has the meeting. Someone proposes opening the API, properly opening it, documented, supported, for anyone to build on, and the room fills with reasons to wait. We had that meeting, and we had exactly two fears worth taking seriously. Both turned out to be wrong, and both were wrong in ways that taught us more than being right would have. This is the field log.

Fear one: the API is safer hidden

The argument felt responsible at the time: the API existed for our own portal and apps, nobody else knew its shape, and keeping it that way was a form of protection. Publishing documentation felt like publishing a map.

Here is what that fear actually was, once we looked at it honestly: hope, dressed up as a security posture. Hiding an endpoint is not a security layer; it is a security delay. Anyone who can join a network and open a developer console can watch our own portal talk to our own API, which means the map was already published to anyone curious enough to look. Security that depends on people not finding your endpoints is not architecture. It is optimism with a firewall.

The uncomfortable admission is that the fear was doing a job for us: it let us defer work the architecture owed regardless. We always had a real authentication layer, that was never the gap. The gap was the worldview behind it: the API had been designed for one trusted consumer, us. Auth built for a single, well-behaved, first-party caller quietly leans on the caller’s good behaviour, and the API’s privacy gets counted as part of the security story even though it was never a load-bearing part.

Deciding to open the API meant deciding that every caller is untrusted, and rebuilding the model around that assumption: the same gates, the same limits, the same isolation for every caller, no matter whose name is on the request.

And here is the part we did not expect, and the reason this post exists: once we made the decision, the work was not the mountain the fear had promised. The dread was expensive; the engineering was not. The fear had been costing us more than the fix.

The lasting consequence is the principle we now hold hardest: we are zero trust for ourselves, exactly as we are for every customer. Our own portal, our own apps, our own dashboards are just API consumers. No privileged backdoors, no internal-only side doors that partners cannot see. We eat at the same table we serve, which means every improvement the public API earns, first-party inherits, and every claim we make about the API’s security is a claim we stake our own product on. That is a far stronger security statement than obscurity ever was, and it is checkable, which obscurity never was.

Fear two: we will lose control of the experience

This one wore better clothes. It sounded like product craft: we have opinions about how guest WiFi should feel, we sweat the flows, and handing partners an API means handing them the ability to build something worse and put our engine behind it.

With some distance, we can name that fear for what it was: myopic, and more than a little self-aggrandising. “Protecting the experience” assumed we had already imagined every experience worth having, that the ceiling of the product was the ceiling of our own imagination. A platform whose experiences are bounded by its makers’ foresight is not a controlled product; it is a small one.

The evidence against the fear was not long in coming. We wrote in the previous engineering post about partners building fully custom login flows against our engine, their brand, their steps, their logic, and doing it elaborately. Those flows are not degraded versions of what we would have built. Many of them are things we would never have prioritised, for markets and workflows we were not staring at, and some of them taught us what the platform actually was. The moments that changed our minds were the integrations we could not have specified, because we did not know enough to specify them.

Then partners went further than flows. Linkbase, who run guest WiFi for short-term rentals in Canada, built a full API integration: they and their property clients manage every one of their networks from Linkbase’s own dashboard, inside the web app where the rest of their rental operation already lives. The experience we were so worried about protecting? For their vertical, they replaced it wholesale, and theirs is the right one, because a host managing a rental at 11pm wants one pane of glass, not two. Cloud-Fi, our partner in Uganda, went a different direction entirely: an Android app they hand to their own customers, who use it to manage venues and watch revenue collection and disbursement, an operating business with money moving through it, built on top of us. We did not design either of those experiences. We could not have. One replaced our interface and the other turned our platform into the plumbing of someone else’s product, and both are better arguments for the API than anything we shipped ourselves.

Control, it turns out, was never the valuable thing. The valuable thing was the floor: making the worst integration a partner can build still safe, still fast, still respectful of the guest. So that is where our opinions went. Instead of gatekeeping the experience, we engineered its minimums: the one-shot bootstrap that hands custom code everything it needs before it can improvise, the structured context that makes the lazy path and the correct path the same path, the guardrails that hold when the guidelines go unread. We stopped trying to be the author of every experience and became the physics of all of them. Physics scales better than authorship.

What the bomb turned out to be

The Strangelove joke in the title is only half a joke. The bomb, the thing we feared and learned to love, is other people’s code running against our platform, permanently, at the most latency-critical moments we have. It is still slightly terrifying, and it should be; healthy platforms stay a little afraid of their consumers.

But the ledger is not close. Fear one, faced, made the platform safer than hiding ever could, and made us our own strictest customer. Fear two, faced, made the platform bigger than our roadmap, and turned partners into a source of product direction we could not have hired. The API is open, the fears were mirrors, and the only regret is the time we spent in the meeting.

If you want to see what the platform hands your code before you write a line of it, the API docs are where we would start. Build something we did not imagine. At this point, we are counting on it.