The 2026 API Reality: Multi-Protocol, Regulated, and Agent-Ready

There’s a comfortable belief in a lot of engineering orgs that REST won, the protocol question is settled, and you can build the next decade of integrations on JSON over HTTP and never think about it again.

That belief is now wrong in a way that costs money. A single integration project in 2026 routinely touches five protocols before it ships. We watched this happen gradually and then all at once, and the teams that designed for REST-only are the ones calling us.

One project, five protocols

Take a real shape. A travel client wants to expose a booking flow to partners. Underneath sits a legacy reservation system that speaks SOAP. It’s been there since before REST was a noun. The new partner-facing API is REST, because that’s what partners expect. The web frontend the client also owns wants GraphQL, so it can ask for exactly the fields it needs and nothing more. A high-throughput internal path between two services runs gRPC, because streaming thousands of price updates a second over JSON is a waste. And now there’s a sixth thing: an AI agent that wants to book on a traveler’s behalf, and it expects an MCP interface it can call as a tool.

That’s SOAP, REST, GraphQL, gRPC, and MCP in one project. None of them is going away on the timeline of this build. The integration work is the reconciliation between them.

Kong’s read of the current state matches what we see on the ground: multi-protocol architectures are the default, not the exception, and gateway proliferation is real. A large share of organizations now run more than one gateway because no single one handles every protocol equally well. Complexity in this part of the stack is going up, not down.

Regulation removed the choice

For a long time you could argue protocol adoption on merit. Regulation ended that argument in specific domains.

Healthcare is the sharpest example. FHIR, the modern REST-and-JSON standard for clinical data, moved from “recommended” to mandated for certain data-exchange requirements. That’s not a technology preference anymore. It’s a compliance deadline with a date on it. If you run health integrations, the question isn’t whether to support FHIR; it’s whether your existing HL7 v2 plumbing can bridge to it before the date.

Finance has its own version with hardened API security profiles for open banking. The pattern is identical: a protocol or profile stops being optional because a regulator wrote it down. When that happens, the integration timeline is set by the compliance calendar, not by the roadmap. The teams that treated the standard as “someday” work discover they’ve lost their runway.

The layer that’s trying to standardize the mess

There’s one hopeful thread. The Kubernetes Gateway API is emerging as a common configuration layer across gateways, a standard way to express routing and policy that isn’t tied to a single vendor’s config format. It won’t collapse five protocols into one. It does mean the operational surface of running multiple gateways can share a vocabulary, which is the difference between managing a fleet and managing a zoo.

We treat this the way we treat every standardization effort: useful, worth adopting, and not a substitute for understanding what sits underneath it. A standard config layer over a gRPC service still requires someone who knows why the stream stalls under backpressure.

The agents are already calling

The number from the current research that should stop a CTO cold: most developers now use AI in their daily work, but only about a quarter design their APIs with AI agents as a consumer in mind.

That gap is the next integration problem, and it’s arriving faster than the last one. An agent is not a browser and not a well-behaved partner integration. It reads your API description and decides, on its own, which calls to make and in what order. If your API assumes a human clicked through a flow (that step two always follows step one because the UI enforced it), an agent will happily call step two first and get a state you never tested.

Designing for agents means the contract has to carry its own rules. Preconditions stated explicitly. Idempotency so a retry doesn’t double-book. Error responses an agent can actually reason about instead of a generic 400. MCP is one way to expose that surface deliberately, as a set of tools with described inputs and effects, rather than hoping an agent reverse-engineers your REST API correctly.

What we tell clients to do

Stop treating protocol choice as a one-time decision and start treating it as a property of each boundary. The boundary to a legacy reservation host is SOAP and will be for years. Build the adapter, own it, monitor it. The boundary to partners is REST. The boundary to your own frontend might be GraphQL. The boundary to agents is a described tool surface. Each boundary gets the protocol that fits it, and the integration layer’s job is to make the translations reliable, not to pretend one protocol serves them all.

The org that designed everything for REST didn’t make a small mistake. They assumed the number of protocols they’d ever touch was one. In 2026 it’s five, two of them are mandatory, and one of them is a machine that calls your API without reading the docs the way you hoped.