Bringing your APIs under management

Every integration decision of the past decade left an API behind, and most enterprises are now connected by a tissue of interfaces nobody can fully list. The official ones live in a portal. The rest — the point-to-point endpoint a project stood up in a hurry, the internal service that three other teams quietly took a dependency on, the version that was deprecated but never switched off — carry production traffic with no owner, no contract, and no place in anyone's risk register. This playbook is about bringing the estate under management before it decides to prove the point. 1. Find the estate, not the portal Start with traffic, not documentation. Gateway logs, load balancers, and network observability will surface the APIs that actually carry calls — including the shadow interfaces nobody registered and the zombie versions that should have died at deprecation. Expect the discovered list to be multiples of the documented one. Each discovery gets the same triage: who owns it, who consumes it, what data it moves, and whether it deserves to exist. 2. The gateway as control point An API policy enforced in a document is a suggestion; enforced in the traffic path, it is a control. Route the estate through a gateway layer and the disciplines stop depending on every team's goodwill: authentication and authorisation applied per consumer, rate limits that protect shared platforms from their own clients, observability that shows who called what and what it cost, and versioning rules enforced where the calls actually flow. The goal is not a bigger portal. It is a single place where the organisation's interface rules are true by construction. 3. Lifecycle as a contract An API is a promise to its consumers, and promises need lifecycle discipline. Version deliberately. Publish deprecation with dates and consumer notifications, and honour the dates — a deprecation nobody enforces trains consumers to ignore the next one. Retire what the traffic says is dead. The catalogue that results is not documentation for its own sake; it is the dependency map every incident, migration, and modernisation plan will reach for first. 4. Security at machine scale API consumers are machines, and machine trust deserves the same discipline as the identity estate: credentials scoped to the least each consumer needs, rotated and revocable; no shared keys passed between teams like folklore; data classification flowing through to the interface, so an endpoint serving sensitive data is authenticated, rate-limited, and logged like one. Most large data losses are, mechanically, API calls — made by a caller who was allowed to make them far too broadly. 5. The AI traffic has already arrived Model calls, retrieval requests, and agent actions are API traffic — usually the fastest-growing and least-governed kind in the building. Routing it through the same control point buys the same disciplines exactly where they are newly needed: per-consumer authentication for agents, rate and budget limits that keep experimentation from becoming an invoice, and the call-level logging that AI evidence and unit-economics work both depend on. The organisations that already manage their APIs will govern their AI traffic with machinery they own; the ones that do not will meet both problems at once. 6. The first 90 days Run discovery from traffic and triage the surprises — ownership first. Route the three most sensitive or most-consumed APIs through the gateway with authentication and rate limits enforced. Publish the catalogue with owners and lifecycle status, and schedule the first honest deprecation. Then point the AI traffic at the same front door before its volume makes the decision for you. Integration debt is quiet until it is not. The estate under management is the one that can change safely — and changing safely is the whole game.