Why Your Company Needs One API Platform, Not Six

Why your company needs one API platform, not six

I counted the tools we were using to manage our APIs last year. Six. Six separate SaaS products, each with its own login, its own config format, its own billing page, its own way of thinking about the world.

One for the gateway. One for the developer portal. One for monitoring. One for documentation. One for billing. One for SDK generation. Each bought at a different time, by a different team, for a different reason. All of them doing part of the job. None of them talking to each other properly.

The real cost is not money

Six subscriptions add up. But that is not what made me build something different.

When an API went down, we checked one dashboard for the gateway, a second for metrics, a third for error logs. By the time we found the issue, the customer had already filed a ticket. Sometimes two tickets, because the first one got lost between tools.

New engineers spent their first week learning six different UIs. Not learning our APIs. Not learning our product. Learning where to click in six different tools to do things that should have been one workflow.

Our security team audited six vendors every year. Six data processing agreements. Six sets of access controls. Six surfaces where a misconfiguration could let something through.

And nobody, at any point, had a complete picture of a single API. The gateway knew about routing. The monitoring tool knew about latency. The docs tool knew about the schema. But no single place could tell you: this API is healthy, well documented, properly billed, and has current SDKs. That information lived in six places, or more often, in someone's head.

What we replaced it with

The platform I built does six things that used to be six products. Routing, monitoring, developer portal, documentation, billing, and SDK generation. One config format. One dashboard. One audit log.

When you import an OpenAPI spec, the platform reads it and sets up everything. The routes, the docs, the SDK templates, the monitoring hooks. You do not configure six tools. You configure one.

When something breaks, you see it in one place. The alert tells you which API, which endpoint, what the error rate looks like, who the consumers are, and whether the docs match what the API actually does. No tab switching. No cross referencing dashboards at 2am while the on call phone keeps buzzing.

The audit log matters more than people expect. Every change to every API goes into one stream. Routing rules, documentation edits, billing tier adjustments. Your compliance team reads one log instead of stitching together six.

What we got right

A single config format. Every API is defined in one file. Routes, rate limits, documentation, billing tiers, SDK output. One file, version controlled, reviewable in a pull request. No more "I changed the gateway config but forgot to update the docs." That class of bug just stopped happening.

Bulk import from OpenAPI specs. Most teams already have specs sitting around. We let them import 50 APIs in an afternoon instead of hand configuring each one across six tools. That is what made adoption fast. Nobody wants to spend a sprint on migration.

A unified audit log. Sounds boring. It is boring, right until the day your auditor asks "who changed the rate limit on the payments API last Tuesday?" In the old world, that question takes an hour of digging through separate tools. Now it takes ten seconds.

What we got wrong

We tried to build billing from scratch. Usage tracking, metering, invoicing, payment collection. All of it. In house.

Bad idea.

Billing has edge cases that will eat your roadmap alive. Proration. Failed payments. Tax calculation across jurisdictions. Currency conversion. Refunds. Disputes. Each one looks simple for about a week, then you are three weeks deep and you have accidentally built half a payment processor.

We stopped. Ripped it out. Integrated with an external payment provider instead. The platform tracks usage and calculates what to charge. The payment provider handles the money. That split works. Building everything ourselves did not.

Consolidation does not mean building everything from nothing. It means one interface, one config, one view for the people using it. What runs underneath can still be separate systems. The team just should not have to know or care about that.

When this does not make sense

If you have five APIs and one team, you do not need a unified platform. You need a gateway and maybe a docs tool. Done.

This starts to matter at a certain scale. 50 or more APIs. 10 or more teams consuming those APIs. Three or more environments where config drift between staging and production keeps causing incidents on Friday afternoons.

Below that, buy the separate tools. They are good. They are well maintained. The coordination pain only becomes unbearable when the number of APIs and the number of teams grows to the point where keeping six tools in sync costs more than the tools themselves.

A quick test

Pick any API your company runs. Try to answer these five questions. What is its p99 latency right now? When was its documentation last updated? How many consumers does it have? What SDK versions are those consumers using? Is the billing tier correct?

If you can answer all five from one screen, you are in good shape. If answering them requires logging into four different tools and asking two different people, you have the problem I am describing.

The fix does not have to be building your own platform. Sometimes it is picking one vendor that covers most of the surface. Sometimes it is writing glue code between existing tools. The point is the same: your engineers should not need a mental map of six products to manage one API.

Six tools made sense when each category was its own market and each tool was the only option. The cost of keeping them separate compounds every time you add an API, add a team, or add an environment. At some point, consolidation stops being optional and becomes the only way to keep shipping.