A platform matters when its own interface stops being mandatory.
Boomi’s September 12 release made every Data Integration data flow and source reachable through an API, not only through the product’s UI. Customers can now build, trigger, and manage pipelines programmatically or embed those controls inside their own tooling. That sounds like a developer feature, but I think it’s a product-boundary decision.
I’ve worked around enough integrations to know the awkward middle state: an API exists, but the one operation you need still requires somebody to click through an admin screen. Automation then grows a human-shaped dependency exactly where the team expected software.
API coverage changes who can own the workflow
Partial APIs are useful for extensions. Full API coverage does something different because customers can decide where the workflow belongs.
A data team might create pipelines from infrastructure code, a platform team can wrap approved patterns in an internal portal, and another product can provision integrations during customer onboarding. Boomi’s documentation describes more than 180 supported sources and targets, plus Source to Target, Logic Flow, and REST Action data-flow types. Once those objects are controllable outside the console, the console becomes one client of the platform rather than the only front door.
That’s a subtle shift, with a fairly brutal test: if an administrator can perform an important action in the UI, can software perform the same action without screen-scraping or a manual handoff?
I like that test because it exposes API-ish products quickly.
The UI still has a job
API-first doesn’t mean UI-last because humans still need a good place to inspect state, troubleshoot failures, learn the object model, and make occasional changes without writing or maintaining automation code.
The difference is architectural authority. A UI-only capability quietly says the vendor owns that part of the workflow; an API-accessible capability lets the customer decide whether it belongs in a script, CI/CD pipeline, internal portal, or another product.
There is a cost: public APIs turn internal object models into promises, so versioning, permissions, idempotency, errors, rate limits, auditability, and deprecation behavior stop being implementation trivia. A sloppy public API can freeze yesterday’s architecture just as effectively as a database schema shared with every customer.
That trade is usually worth making for platform products because enterprise customers already have their own control planes, approval systems, deployment pipelines, and odd little pieces of glue. Forcing every operation back through one vendor console doesn’t simplify that environment; it just relocates the complexity to somebody’s runbook.
I’ve argued before that developer platforms should hide their internal architecture. Full API coverage adds the other half: hide the machinery, but don’t trap the controls behind your preferred interface.
My favorite platform test is now slightly rude: imagine deleting the web UI for a week.
If important customer workflows become impossible rather than merely less convenient, the API surface is telling you exactly where the platform boundary still ends.
Comments
Comments are powered by GitHub Discussions through Giscus.