[music]

Every API you expose to the world needs

the same things. Authentication, rate

limiting, documentation, analytics. And

if you're building AI powered

applications, add cost tracking and

provider failover to that list. You

could implement all this. I know that. I

know that you can do it. You can do it

in every single service you build.

or you could centralize it in an API

gateway. Today we are exploring what API

gateways actually are when you need them

and when you don't. We'll look at how

they fit into different architectures

from traditional VMs to Kubernetes to

serverless and we will take this

opportunity to explore Zuplow as a

possible solution for your API gateway

needs.

So let's say you're building services

that need to expose APIs to the world.

Browsers hitting your endpoints, mobile

apps consuming your data, partner

integrations calling your services. This

is all standard stuff. But here's the

thing, the problems you face are

universal. Authentication

authorization, rate limiting, request

transformation, API versioning, caching

observability documentation.

Every API needs all of this. Now without

centralized control you end up

implementing these concerns in every

single service. You get scattered logic

across different code bases. You get

inconsistent trade limits because each

team hey does it differently. You get

dedicated course configs everywhere. You

get fragmented monitoring that gives you

no coherent picture. It's a mess. This

is where API gateways come in. They give

you a single entry point for all

external traffic. centralized policies

that apply consistently and the unified

API surface for clients regardless of

how complex your backend architecture

is. The gateway sits between external

clients and your backend services and it

is enforcing all those policies at the

edge before requests even reach your

services. Now, how you deploy and use an

API gateway depends entirely on your

infrastructure. So let's start with the

non- Kubernetes world. VMs, bare metal

serverless functions, managed cloud

services, you name it. In traditional

setups, you typically have a load

balancer handling layer 4 traffic, then

a reverse proxy like EngineX or HARxy

doing basic routing and then you bolt on

authentication and rate limiting and

everything else. An API gateway

consolidates all this into one coherent

layer. For serverless architectures, an

API gateway is is completely essential.

It is it's a must. AWS API gateway

Azure API management, Google Cloud

Endpoints, those are your front door

when you have dozens of Lambda functions

or cloud run services behind them. The

value here is crystal clear. It's clear.

You don't want authentication rate

limiting and API contracts scattered

across 50 or 100 or thousand different

serverless functions. That that would be

insane. Now Kubernetes deployments are a

slightly different story. Ingress plus

load balancer already handles external

traffic routing. You get a public IP

layer 7 routing based on host names and

pots SSL termination and so on and so

forth. It's all there. But here's the

thing. Ingress is just routing and

what's missing? Well, advanced

authentication, rate limiting, request

transformation, API versioning

developer portals, monetization

detailed analytics, and and a few other

things. API gateways add this entire

management layer on top of basic

routing. Now you have options for how to

deploy this. Some English controllers

actually are API gateways. Kong

ambassador, traffic enterprise, and a

few others. these bundle routing and

full API management capabilities inside

the cluster. Everything runs inside your

Kubernetes cluster. The other approach

is external managed services and those

would be cloud hosted platforms that sit

in front of your ingress. These give you

multicloud routing, enterprisegrade

analytics, developer portals

monetization features and a few other

things. The gateway lives outside your

cluster. And then there are hybrid

setups. some services running in

Kubernetes, some on VMs, some as

serverless functions. An API gateway can

unify access patterns across all of

them, giving you one consistent

interface regardless of where your

backend services actually live. Okay

now here's where people screw up. Inside

Kubernetes for servicetoervice traffic

API gateways are useless. They don't

belong there. Kubernetes services

already handle discovery and routing. If

you need more than that, a service mesh

gives you MTLS, observability, retry

circuit breaking, routing, internal

traffic through a gateway just adds

latency for absolutely no benefit. Now

there are different types of API

gateways specialized for different use

cases. API management gateways focus on

REST APIs. They handle open API schemas

API versioning, developer portals

documentation monetization partner

integration, etc. This is about exposing

and managing your business APIs. Then

there are AI gateways. It's the same

concept but for LLMs. They manage

provider access. They rate limit model

calls and log prompts and responses and

track costs and handle model failover

and so on and so forth. Instead of

managing rest endpoints, you're managing

a model access. So here's the bottom

line. API gateways are for north south

traffic. external clients coming into

your internal services for east west

traffic service to service communication

inside your infrastructure. They're just

noise.

Don't do it. Use a service mesh or your

platform's native tools instead. Okay.

Now that we understand what API gateways

are and when to use them, let's actually

build one. We'll use Zuplo as our API

management gateway and we will see how

to set it up the right way.

So why bother with API management

specifically? We covered what API

gateways do in general, but API

management is a particular flavor

focused on the business side of your

APIs. It's not just about routing

traffic. It's about treating your APIs

as products. Think about it. You have an

API. Kudos to you. It's great. But who

is using it? How are they using it? Are

they abusing it? Are they even supposed

to have access? API management gives you

the tools to answer these questions. You

get developer portals where consumers

can discover your APIs, read

documentation, get API keys. You get

analytics showing which endpoints are

popular, which are failing, who's

hitting rate limits, and so on and so

forth. You get versioning so you can

evolve your API without breaking

existing consumers. And you get

monetization if you want to charge for

access. And the alternative is building

all of that yourself. And trust me

nobody wants to maintain a homegrown

developer portal, a custom API key

management system, and handrolled

analytics dashboards. That's not where

your business value is. Okay, with that

intro, let's see how Zuplo handles API

management. Zupl offers three project

types. API management for traditional

REST APIs, AI gateway for LLM access and

MCP gateway for model context protocol.

We will start with API management and

then we'll see about the others. I am

choosing empty project because we'll

import our own open API schema rather

than using their starter template. Don't

do it. We'll get to that later. So this

is Zuplus root designer. You can see

that it lets you manually define routes.

You can set HTTP methods, paths, and

attach policies for request and response

handling. Now, we could define our

entire API schema right here in this UI.

Please don't don't do this. Don't do it.

Don't don't use Zuplo or any other

similar tool for that. You're a software

engineer and I have to assume that you

know how to develop an app that exposes

an API. And more importantly, I will

assume that you know how to create open

API schema. You can generate schema from

an existing API or you can start with

the schema and use it to generate code.

That's your choice. The important point

is that we've been generating schemas

for a long time and there are plenty of

tools that can do it. If you're not sure

how, ask your coding agent. Ask cloud

code or cursor to generate one for you.

So I already have an open API schema for

my API. Let's take a look at it. This

over there is a standard open API 3.0

schema. It defines the API title

description, version, contact info, and

the server URL where the back end lives.

The PS section defines each endpoint

with its parameters and report schemas.

There is nothing fancy over there. This

is what you should already have for any

API you're exposing. Right now, when we

import this schema, Zuplo parses it and

shows us all the routes it found. get

and post endpoints, the full pad

structure, everything extracted

automatically from that schema. Now

after we save it, we can see our full

project structure. On the left, there's

the file tree with config files, module

schemas, and docs. On the right, the

route designer shows all our imported

endpoints. Each route displays its

summary from the open API schema along

with the HTTP method and path. The

bottom bar or there shows the gateway is

deployed and ready. So let's test one of

these routes to make sure everything is

wired correctly. And there we go. The

test model shows our request going

through Zuplus gateway. And notice the

URL. It's hitting Zuplus edge at

zuplodev which then proxies to our

backend. We get 200 okay response with

our API data. The gateway is working.

Now, so far this is not very useful.

This is our existing API API schema in

action. Now, let's spice it up. Let's

add some actual API management

capabilities. And this is where Zuplo

earns its keep. Zupl has a library of

built-in policies you can attach to

routes. Rate limiting, authentication

caching, request transformation, and so

on and so forth. We're going to add rate

limiting to protect our endpoint from

abuse. And there we go. The policy

configuration is just JSON. We're

setting rate limit to IP, which means

each IP address gets its own counter.

Request allowed is set to one. Very low.

Don't don't use that value. And time

window minutes to one as well. That's

one request per minute per IP. That's

absolutely restrictive but perfect for

demonstrating that it works. Okay, now

we can see the policy attached to our

route. The rate limit inbound policy

appears in the request flow, meaning it

runs before the request hits our back

end. Any request that exceeds the limit

gets rejected at the edge without ever

ever touching our service. And there it

is. 4 to9 too many requests. The first

request went through but the second one

got blocked. The response body follows

the RFC something something problem

details format with the status code and

human readable title and trace

information for debugging. Our back end

never even saw this request. Zuplo

rejected it at the edge. Now let's

connect this to version control. Zuplu

integrates with GitHub which means your

gateway configuration lives in a repo

like any other code and from here on any

changes we make to the project can be

pushed to the repo. This means you can

review gateway changes in pull requests

you can track history and you can roll

back if something goes wrong. It's Git

of sorts for your API gateway. Now let's

take a look at what Zuplo created. Now

everything we did through the UI could

be done through code itself. Zup plus

configuration is just text files. The

config routes JSON file contains your

open API schema with Zupo specific

extensions for policies. The policies

JSON file defines reusable policy

configurations. You can write custom

request handlers in Typescript if the

built-in policies don't cover your use

case. So when you're done, you push to

git and zuplo deploys automatically.

Each branch becomes its own environment.

You can test changes before merging to

production. It's I was about to say

proper githubs. It's not really proper

giths, but it's close to it. Now, here's

one gripe I have with this approach.

Zuplo requires a copy of your open API

schema inside its project. That's kind

of silly. I would prefer if it could

reference an external schema instead of

duplicating it. In an ideal world, I

would have my open API schema in my

API's repo as the single source of truth

and Zuplo would pull from there. Having

to sync schemas between repos adds

friction. You either need to manually

keep them in sync or to build automation

to merge changes. Now, it's not a deal

breaker, but it's not as clean as it

could be, as it should be. That said

the overall experience, it's solid. The

GitHubs workflow, it's it's fine. The

built-in policies are great. The edge

deployment, it all works well for what

it's designed to do. Now, beyond what

we've seen, Zupl offers quite a bit more

for API management. The developer portal

is automatically generated from your

open API schema. Your API consumers get

documentation, a test console to try

endpoints, API key management and usage

analytics all all in one place is

deployed on their edge CDN. So it loads

fast for authentication. There are over

50 security policies available API keys

JWT validation or O custom handlers.

Whatever your authentication story is

Zupo probably has a policy for it. Then

there are analytics which integrate with

services like MOSFE to give you deep

insights into usage patterns and who's

calling what and how often and what's

the latency, what's the failing. This

feeds into the monetization story. And

speaking of monetization, Zupl

integrates with Stripe and Open Meter

for usage based billing. You can set up

pricing tiers, trunk consumption, and

automatically block requests when

consumers, not consumers, customers

exceed their limits. So if you're

building an API as a product type of

business, this is the stuff you would

otherwise spend months building

yourself. And the whole thing, all that

runs on their edge network across some

200 data centers. It's serverless. It

scales automatically. there is zero cold

start, all the good things. Your gateway

runs close to your users regardless of

where they are. Okay, so that covers API

management for traditional and I repeat

traditional rest APIs, but Zuplo offers

something specifically for AI workloads.

So let's take a look at their AI

gateway.

Here's the story. Whether you're

building applications that call ALMs or

your team is using coding agents like

cloud code or cursor or copilot, you're

making a lot of calls to AI providers

and that creates problems. On the app

development side, you might start with

one provider, then realize another is

better for certain tasks and suddenly

you're juggling multiple API keys and

different SDKs and inconsistent error

handling and no unified view of costs

and you know all the things. On the

tooling side, every developer on your

team has their own API keys and their

own spending and their own model

choices. Finance has no idea what AI is

actually costing the organization. and

security has no visibility into what

data might be flowing through these

tools. An AI gateway sits between all of

this and the LLM providers. You get a

single API endpoint that handles

automatic failover when providers go

down. You get load balancing, caching to

avoid redundant calls, cost tracking

across all usage and rate limiting so

nothing spirals out of control.

Developers get one API key instead of

managing credentials for every single

provider. the organization gets a

unified control plane. It's the same

essentially the same pattern as API

management. It's just specialized for

LLM traffic. So let's see that in action

through ZUPI gateway. We create a new

project just like before, but this time

selecting AI gateway as the project

type. Then the setup wizard walks us

through configuring a provider. We

select I'm going to select a topic.

Enter API key and choose which models to

expose through the gateway. This is the

key your organization manages centrally.

Developers using the gateway never see

this key. Never directly at least. Now

here's something that frustrated me.

Claude Hayeku 4.5 is not or it wasn't at

the time of recording in the list. So

come on Zupllo. If you're not going to

let us specify any model we want, then

you need to stay on top of the list

you're curating. It had been months

since, Haiku, 4.5, was, released,, at least

when I recorded this. And we are not

talking about some obscure model over

there. Hayeku is almost as good as set

but faster and cheaper. It's one of the

most important models Antropic has

released. So either let us type any

model of name we want or keep your

curated, list, current., Pick, you, you you

make a choice. Anyway, that was the

message for Zuplo. Now back to you. What

should we do next? Yeah, we create a

team. Teams lets us organize access and

enforce usage limits across different

groups in an organization. Finally, we

create an app within that team. This is

where it gets interesting. Each app gets

its own API key that developers use. You

can set budget limits both daily and

monthly. You can do it in dollars or

whichever currency. You can set token

limits. You can configure warnings

before limits are hit. This is how you

prevent a runaway script from burning

through your entire AI budget overnight.

So once the app is created, Zuplo gives

you gives us an endpoint URL and an API

key. Now, Zuplo has instructions for

integrating their SDK into your

applications.

Don't do it. Don't use it. Build your

apps to support any OpenAI compatible

endpoint instead. That way, you're not

locked into Zuplo specifically. You can

swap in any gateway or you can go direct

to providers without changing your code.

At least that's what I did for my app.

And here's how I configured my

application to route through Zuplus AI

gateway. We set the base URL to Zupus

endpoint. Provide the API key ZUPO

generated for our app and specify the

model. The app itself doesn't know or

care that it's talking to Zuplo. That's

not the problem of the app. It just sees

an OpenAI compatible API. So let's

verify it works. I will fire up Cloud

Code and ask it to check the system

status. Look at it. The AI provider

shows as connected using the model we

configured. The request went through

Zuplus gateway and Zuplo forwarded it to

Entropic and we got our response. All

the cost tracking rate limiting and

observability we configured and Zuplo is

now capturing this traffic.

So let me give you my honest assessment

after working with Zuplo. Schema

duplication is annoying. Zupl requires a

copy of your open API schema in its

project rather than referencing it from

your source repo. That means that schema

drift is a real risk unless you build

automation to keep things in sync. What

else? Oh yeah, custom logic is

Typescript only. If your team lives in

Go or Python or Rust, you're writing

gateway code in a language you might not

prefer. Kong, for example, lets you

write Lua plugins. Touk supports

multiple languages. Zuplo doesn't. Next

there's no self-hosting option. It's

fully managed. If you need to run your

gateway in your own infrastructure for

let's say, compliance or control

reasons, you need to look elsewhere like

Kong or Tuk or Gravity or one of those.

What else? Oh, yeah. Uh, it's a new

platform with a smaller ecosystem than

established players like Kong or

Mulesoft. There are fewer community

plugins, fewer battle tested production

stories and fewer things in general. Now

for the good side for the pros, let's

start with the developer experience

which is really really great. Code first

configuration, GitHub, GitHub like out

of the box, TypeScript for custom logic.

It feels like a tool built for

developers. Then we have edge deployment

across 300 or more than 300 a huge

number of data centers with zero

configuration. Your gateway runs close

to your users globally without you

managing infrastructure. Then there is

UI. UI is absolutely excellent. If you

prefer visual configuration, I don't

but I recognize that it's great. It's

clean and it's intuitive. MCP support is

builtin. The MCP gateway automatically

transforms your APIs into model context

protocol servers so AI agents can

discover and use them. Then there is

monetization and there are developer

portals and that's all included not

bolted on. And the pricing pricing is

very transparent. There are no surprise

bills. What you see on their pricing

page is what you pay. That's that's

really cool. All in all, the bottom line

is Zuplo is a solid choice for teams

that want a managed developer friendly

API gateway. If you need self-hosting or

if you need multi- language plugins

stick with Kong or something like that.

For everything else, Zupl is really

great. And remember the core principle.

API gateways are for not traffic.

Centralize your API concerns at the

edge. Keep your services focused on

business logic and don't route internal

traffic through a gateway when

Kubernetes services or a service mesh

will do. Thank you for watching. See you

in the next one. Cheers.