Every developer tool launched in the last five years has described itself as “API-first.”
It’s become a marketing term, which means it’s become meaningless. A tool with an API is not an API-first tool. A tool that has an API because someone asked for it is not API-first. A tool where the API is a read-only subset of the UI’s capabilities is definitely not API-first.
API-first is a design philosophy, not a feature. And like most design philosophies, it’s visible in the details — not the homepage.
The actual definition
An API-first tool is one where the API is the canonical interface. Every capability the product has is accessible via the API. The UI, if one exists, is a client of the API — not the other way around.
This has a specific technical implication: the API and the UI share the same underlying implementation. When you create a monitor via the API, it runs through the same validation, the same business logic, the same database writes as when you create it via the UI. There is no “API mode” with different constraints. There is just the API, and the UI is a layer on top of it.
This matters more than it sounds.
Why the implementation detail matters
When a UI is built directly on top of a database — which is how most web applications are actually built — the API gets added later, as a wrapper around a different code path. This produces a specific set of symptoms:
API parity gaps. Certain operations are only possible through the UI because nobody got around to adding them to the API. You can configure something in the dashboard that you can’t automate. The features that were added most recently are the ones most likely to be missing from the API.
Different validation rules. The UI has client-side validation. The API has its own validation. They diverge over time. Things the UI accepts, the API rejects. Edge cases the UI handles gracefully, the API handles with a 500.
Inconsistent response shapes. API responses were designed by different people at different times for different use cases. A resource returned from the GET /monitors endpoint looks different from the same resource returned from the POST /monitors response. Field names are inconsistent. Types are inconsistent. Null handling is inconsistent.
Documentation as an afterthought. When the API is a secondary interface, the documentation reflects that. It covers the happy path. The error responses are undocumented. The webhook payloads are described but their exact shape isn’t guaranteed.
These aren’t symptoms of a bad engineering team. They’re the predictable result of a design approach that treats the API as a feature rather than an interface.
What real API-first looks like in practice
Everything available via API is available to everyone. Not behind a higher pricing tier. Not in “beta” access. The API doesn’t have a different set of capabilities based on how you’re authenticated.
The API documentation is authoritative. If the documentation says a field is a string, it’s a string everywhere, always. If a response shape changes, it changes via versioning with a documented deprecation path — not silently.
Webhook payloads are stable and versioned. This is where many “API-first” tools fall down. The REST API is fine; the webhooks are inconsistent and break without notice. In a genuinely API-first system, webhook payloads have the same stability guarantees as the REST API.
You can fully automate setup. Creating an account, configuring the product, setting up integrations, building an integration that another system can depend on — all of this should be possible without ever opening a browser.
The API is what’s tested. In a UI-first system, QA happens against the UI. In an API-first system, the API contract is tested directly. Regressions in the API are caught before they ship.
The developer experience difference
Why does this matter for how you build?
If you’re integrating a tool into your workflow — automating deployment pipelines, building internal tooling, orchestrating infrastructure from code, running agents that interact with services — the API is the only interface that matters. The UI is irrelevant.
An API-first tool is one you can depend on at that layer. You can write code against it and have reasonable confidence that the code will still work in six months. You can build abstractions on top of it. You can test your integrations without mocking everything.
A UI-first tool with an API bolted on is one where your automations are fragile, your integrations break on minor product updates, and any capability you need that isn’t already in the API requires filing a request and waiting.
The CI/CD test
A simple heuristic: can you fully configure and deploy the tool from a CI/CD pipeline with no human interaction?
If yes, it’s at least approaching API-first. If the honest answer is “mostly, except for these few things you have to do in the dashboard,” it isn’t.
This isn’t a high bar. It’s a baseline. But a surprising number of developer tools fail it.
API-first and AI agents
The API-first question has become more urgent with the rise of AI agents. Agents need to interact with tools programmatically. They need predictable interfaces, stable schemas, and the ability to do everything a human can do through a UI.
A tool that’s UI-first with an API afterthought is a tool that agents can’t reliably use. A tool that’s genuinely API-first is one that works as a component in an automated pipeline — whether that pipeline is a deployment workflow or an AI agent managing infrastructure.
This is where the design philosophy stops being abstract. The distinction between “has an API” and “is API-first” is exactly the distinction between a tool you can build on and a tool you’re constrained by.
Both Vigil and Structr are built API-first — every capability in the dashboard is available via the REST API, with stable schemas and versioned webhook payloads.
