What is an API gateway?
An API gateway is the front door to your server.
Every request, from your website, your phone app, a partner or an AI assistant, goes through it first. It checks who is calling, what they are allowed to do and how often, then hands the request to your code. Your code only does the actual work.
Spin up your own API gateway in one command
$ npx apiblaze@latest create --target https://ninopizzas.com/openapi.yamlPaste it in a terminal. No sign-up, no servers. The link is a sample restaurant API; swap in your own API’s address to put yours online. You get a live web address with keys, sign-in, permissions and limits, plus a way for AI assistants to use it (more on that below).
It sits between your users and your server
First, what’s an API? It’s how one program asks another for something. A restaurant’s app asks the restaurant’s server “show me my bookings”, and the server answers. Your website, your phone app and AI assistants all talk to your server that way.
Without a gateway
Requests go straight to your server. Your code checks each one itself: who sent it, whether they’re allowed, whether they’re sending too many. Every part of your code repeats those checks, and one forgotten check is a security hole.
With a gateway
Requests go to the gateway first. It runs those checks once, for every request, refuses what fails, and passes the rest on with who sent it. Your code does only the actual work, like saving the booking.
What happens to one request
- 1
It arrives
Ana taps “cancel” on booking 42 in a restaurant’s app. The app sends that request to the gateway, not straight to the restaurant’s server.
- 2
Who is it?
The gateway checks her key or her sign-in. It’s Ana.
The tech word for it: authentication
- 3
Is she allowed?
Booking 42 is hers, so yes. If Ben tried to cancel it, he’d be refused, and the restaurant’s server would never even hear about it.
The tech word for it: authorization
- 4
Not too often?
Ana is well under her limit. A broken script sending a thousand requests a second is told to slow down instead.
The tech word for it: rate limiting
- 5
The server does its job
The gateway passes the request on, with a note saying it’s from Ana. The restaurant’s code just cancels the booking.
- 6
It’s written down
Every request is recorded: who asked, for what, the answer, and how long it took.
What problems does an API gateway solve?
Every service on the internet has to answer the same few questions. A gateway answers them once, for every request, so your code doesn’t have to.
“Who is this?”
Every app gets a key, and every person (or AI assistant) signs in, with Google, GitHub or Microsoft for example. Anyone else is refused.
The tech word for it: authentication
“Are they allowed to do that?”
Rules like “only the person who made a booking, or the manager, can change it”, checked on every request before it reaches your code.
The tech word for it: authorization
“Who’s the manager here?”
Put people in groups, such as managers, staff and customers, and decide what each group can do. No code changes when someone gets promoted.
The tech word for it: roles and groups
“Way too many requests!”
A broken script, or an AI assistant stuck in a loop, is slowed down before it overwhelms your server or runs up your bill.
The tech word for it: rate limiting
“One app, many customers”
If businesses use your service, each one gets its own keys, people and managers, and never sees another’s data.
The tech word for it: multi-tenancy
“How do I even get it online?”
Your service gets a secure web address (https://…), your own domain if you like, and a record of every request.
The tech word for it: hosting and logs
And what is MCP?
MCP (short for Model Context Protocol) is how AI assistants such as ChatGPT and Claude use other services. Your service offers a menu of things it can do, like “book a table”, “list my bookings” and “cancel a booking”. The assistant picks from that menu and does it for the person it’s chatting with.
In a chat
Book a table for two at 7:30 tonight.
Done: table 3, tonight at 7:30.
Building an MCP server is the easy 20%
Turning your service into a menu for AI is quick. The rest is what makes it safe to put on the internet:
Who is asking?
The assistant acts for a real person, who has to sign in, so every request says who it’s for. Without that, anyone who finds the address can use your service.What are they allowed to do?
Ana’s assistant can cancel Ana’s booking, not Ben’s. An assistant tries whatever it’s asked to, so the rules have to live outside it, in the gateway.Who is in charge?
The restaurant’s manager sees every booking; a customer sees only their own.Can the AI understand it?
The names and descriptions of your tools are its only instructions. If they are vague it guesses: it asks for a table number nobody knows, or books the wrong day.How often?
An assistant stuck in a loop can call your service thousands of times a minute.
APIblaze does the 80%. Every gateway it creates is also an MCP server, behind the same sign-in, rules, groups and limits as everything else. It builds the menu from your API’s own description, and helps you name and explain each item so the AI picks the right one.
API gateways, compared simply
Every gateway passes requests along. The difference is how much of the security you still have to put together yourself, and how long it takes to go from “my code works” to “it’s safely on the internet”.
| Build it yourself | AWS API Gateway | Kong | APIblaze | |
|---|---|---|---|---|
| Online in one command, without signing up | You build it Rent servers, set up security certificates and a web address, then write everything below. | You build it Create an AWS account, then a fair amount of setup in the AWS console or in config files. | You build it Install Kong on servers you run, or sign up for Kong’s cloud, then set it up. | Built in One command. No account, no servers. Sign up later, only if you want to keep it. |
| Checks who is calling (keys, sign-in) | You build it You write it, or wire in a login service. | You put it together Keys are built in. Letting people sign in means setting up a login service, such as Amazon Cognito, and connecting it. | You put it together Add-ons (plugins) you switch on and set up; some need Kong’s paid edition. | Built in Keys and ready-made sign-in pages (Google, GitHub, Microsoft, or your own). A setting, not code. |
| Decides who may do what | You build it A check you write in every part of your code. | You put it together Code you write and run on AWS, or another AWS service (Verified Permissions) to set up. | You put it together Simple allow and deny lists by group. Finer rules, like “only the owner”, need a separate rules engine. | Built in Rules in plain English, like “only the person who made it can change it”, suggested for you and tested before they’re switched on. |
| Managers, staff, customers: groups for your users | You build it The lists, the screens and the checks, all yours to build. | You put it together Groups live in Amazon Cognito, a separate service; what each group can do is yours to connect. | You put it together Groups for the apps that call you; your own users’ groups are yours to build. | Built in Built in, with a ready-made screen your customers’ managers use to add people and groups. |
| Ready for AI assistants (MCP) | You build it Write an MCP server, put it online, and secure it. | You put it together Yes, through a separate AWS service (Bedrock AgentCore Gateway) to set up. | You put it together Yes, with add-ons (plugins) you switch on and set up. | Built in Every gateway is also an MCP server, behind the same sign-in, rules and groups. |
| Best for | Learning how it works, or very unusual needs. | Teams already on AWS, wiring many AWS services together. | Large teams running many APIs on their own servers, extending it with add-ons. | Your code works and you want it safely online, for people and AI assistants, today. |
Online in one command, without signing up
- You build it
Build it yourself. Rent servers, set up security certificates and a web address, then write everything below.
- You build it
AWS API Gateway. Create an AWS account, then a fair amount of setup in the AWS console or in config files.
- You build it
Kong. Install Kong on servers you run, or sign up for Kong’s cloud, then set it up.
- Built in
APIblaze. One command. No account, no servers. Sign up later, only if you want to keep it.
Checks who is calling (keys, sign-in)
- You build it
Build it yourself. You write it, or wire in a login service.
- You put it together
AWS API Gateway. Keys are built in. Letting people sign in means setting up a login service, such as Amazon Cognito, and connecting it.
- You put it together
Kong. Add-ons (plugins) you switch on and set up; some need Kong’s paid edition.
- Built in
APIblaze. Keys and ready-made sign-in pages (Google, GitHub, Microsoft, or your own). A setting, not code.
Decides who may do what
- You build it
Build it yourself. A check you write in every part of your code.
- You put it together
AWS API Gateway. Code you write and run on AWS, or another AWS service (Verified Permissions) to set up.
- You put it together
Kong. Simple allow and deny lists by group. Finer rules, like “only the owner”, need a separate rules engine.
- Built in
APIblaze. Rules in plain English, like “only the person who made it can change it”, suggested for you and tested before they’re switched on.
Managers, staff, customers: groups for your users
- You build it
Build it yourself. The lists, the screens and the checks, all yours to build.
- You put it together
AWS API Gateway. Groups live in Amazon Cognito, a separate service; what each group can do is yours to connect.
- You put it together
Kong. Groups for the apps that call you; your own users’ groups are yours to build.
- Built in
APIblaze. Built in, with a ready-made screen your customers’ managers use to add people and groups.
Ready for AI assistants (MCP)
- You build it
Build it yourself. Write an MCP server, put it online, and secure it.
- You put it together
AWS API Gateway. Yes, through a separate AWS service (Bedrock AgentCore Gateway) to set up.
- You put it together
Kong. Yes, with add-ons (plugins) you switch on and set up.
- Built in
APIblaze. Every gateway is also an MCP server, behind the same sign-in, rules and groups.
Best for
- Build it yourself. Learning how it works, or very unusual needs.
- AWS API Gateway. Teams already on AWS, wiring many AWS services together.
- Kong. Large teams running many APIs on their own servers, extending it with add-ons.
- APIblaze. Your code works and you want it safely online, for people and AI assistants, today.
When to pick something else: if you must run the gateway on your own servers, want a big library of add-ons, or manage hundreds of APIs across a large company, Kong or your cloud’s gateway will serve you better. APIblaze only runs as a service, and it’s in beta.
Common questions
What is an API gateway, in one sentence?
A single front door for your server that checks who is calling, what they may do and how often, before passing each request to your code.
Do I need an API gateway?
If only your own website talks to your server and you have already built sign-in, permissions and limits into it, maybe not yet. Once other people’s apps, partners or AI assistants use it, a gateway saves you from rebuilding the same security everywhere.
What is the difference between an API gateway and a load balancer?
A load balancer spreads visitors across several copies of your server so none gets overloaded; it does not know who is calling. A gateway looks at each request: who sent it, whether they are allowed, and how many they have sent. Many setups use both.
What is the difference between an API gateway and a reverse proxy?
Both sit in front of your server and pass requests along. A plain reverse proxy, such as nginx, only passes them along; a gateway also checks keys and sign-ins, applies your rules and limits, and keeps a record.
What is an MCP gateway?
A front door for AI assistants. It offers your service as tools they can use, and applies the same sign-in, rules and limits to them as to everyone else. In APIblaze, the API gateway and the MCP gateway are the same thing.
Do I need an account to try APIblaze?
No. The command creates a working gateway without an account. Claim it to an account within 30 days to keep it.
Spin up your API gateway
One command, no sign-up. Sign-in, permissions, groups, limits and a door for AI assistants, built in.
$ npx apiblaze@latest create --target https://ninopizzas.com/openapi.yamlSources
Statements about AWS API Gateway and Kong were checked against their official documentation in October 2026. Both change quickly, and some Kong features depend on the edition. If something here is out of date, tell us and we’ll fix it.
- AWS: usage plans and API keys
- AWS: Lambda authorizers
- AWS: Cognito user pool authorizers
- AWS: API Gateway MCP proxy
- Amazon Verified Permissions
- Kong: Key Auth
- Kong: OpenID Connect
- Kong: ACL
- Kong: OPA
- Kong: AI MCP Proxy
- Kong: AI MCP OAuth2
AWS and Amazon API Gateway are trademarks of Amazon.com, Inc. Kong and Kong Konnect are trademarks of Kong Inc. APIblaze is not affiliated with either.