You have an API that works. Then the asks start: a customer wants an API key, someone wants to use it from Claude or Cursor, users should only change their own records, and you need rate limits and quotas. Each of those is its own project: auth middleware, OAuth plumbing for MCP clients, authorization rules, a developer portal.
APIblaze is a serverless MCP & API gateway with all of that built in. This post walks through what it sets up, with the real commands and output.
One prompt
Open Claude Code (or Codex) in your backend's folder and paste:
Show me what APIblaze does using npx apiblaze skills
npx apiblaze skills looks at the folder (framework, port, OpenAPI spec) and tells the agent the next step: put your API behind APIblaze, or try it on a sample app first. If you have no OpenAPI spec, the agent writes one.
What's built in
- Secured MCP: an MCP server for your API, behind OAuth, so agents act as the signed-in user.
- Multi-tenant: each customer gets its own keys, users, portal and MCP address.
- Self-serve API keys: a hosted developer portal, plus a drop-in React widget for your own site.
- OAuth sign-in: GitHub by default, or Google, Microsoft, Auth0 or any OIDC provider.
- Authorization: only a record's creator (or an admin) can read or change it, enforced at the proxy, straight from your OpenAPI spec.
- Throttling & quotas: a per-consumer rate limit and a daily quota, on by default.
- Localhost tunneling: your API and its MCP server on public URLs that reach your laptop.
- Custom domains: your API on your own domain, TLS handled.
By hand: one command
No agent? Point it at an OpenAPI spec:
npx apiblaze create --target https://ninopizzas.com/openapi.yaml
It asks two questions and prints everything you need. Here's a real run, logged out (trimmed):
? Should only creators of a resource in the API be able to amend that resource?
❯◉ restaurants — only the person who created a restaurant, or an admin, can view or change it
◉ restaurants/{restaurantId}/reservations — only the person who created a reservation, or an admin, can view, change or delete it
◉ restaurants/{restaurantId}/tables — only the person who created a table, or an admin, can change or delete it
? Who is the admin? Their email address (Enter to skip): admin@ninopizzas.com
✔ API proxy created!
✓ https://daringfox2395.tryabz.run/1.0.0/prod — your backend and widget use the API key; people and agents use an APIblaze login (with GitHub)
✓ restaurants, reservations + tables locked to their creator
MCP URL (for agents): https://daringfox2395-victorymeadow1963.mcp.tryabz.run/1.0.0/prod
Try saying to your agent:
✓ "List the restaurants." → allowed (lists stay open)
✓ "Create a reservation, then show it to me." → allowed: you created it
✗ "Delete a reservation you didn't create." → refused: not yours, and you're not an admin
✓ "Now do that again as an admin." → allowed: admin@ninopizzas.com is an active admin
No account is needed to try it: logged out, you get an anonymous proxy you can claim to your account within 30 days.
Who's asking? Your backend knows
An MCP server is there to take actions, and every action needs a person behind it. Every call that reaches your backend carries who's calling, set by the gateway (and stripped if a client tries to send them itself):
POST /reservations
x-abz-user-id: user_8f2k… # the signed-in person
x-abz-tenant-id: ninopizza # their customer space
x-abz-identity: eyJhbGciOi… # the same, signed by the gateway
Your code doesn't change; it can read who's calling from these headers. Lists stay your job: filter collections by tenant and user.
Are they allowed? Rules at the proxy
The ownership rules come from your spec. Groups and plain-English rules go further:
# groups and plain-English rules need a login first: npx apiblaze login
# groups, from the widget or the CLI
npx apiblaze group create admin
npx apiblaze group create staff
npx apiblaze group add-group staff admin # staff sits inside admin
npx apiblaze group add-user maria staff
# one rule, in plain English: tried in shadow mode, then enforced
npx apiblaze rule reserv \
"users see only their own reservations; anyone in admin sees all"
Every call is then checked at the proxy, before your backend sees it:
GET /reservations/42 john his own → 200
GET /reservations/42 alice not hers, not in admin → 403
GET /reservations/42 maria staff, inside admin → 200
Still on localhost?
npx apiblaze dev --port 3000
one of your proxies has an openapi.yaml file with a target set to localhost:3000
Tunnel:
https://myapp.abz.run/1.0.0/dev -> localhost:3000
The API and its MCP server get public URLs that reach your laptop, with all of the above on, and every call streams to your terminal so you can adapt your responses live.
See it on a sample app
npx apiblaze demo
In about 40 seconds, with nothing but Node 18, a table-booking app for two pizzerias runs on your laptop behind APIblaze.
Ask the assistant to book a table. It goes through the MCP server, as the signed-in user:
Now sign in as Ben and try to cancel Ana's booking. The gateway refuses before the backend sees the call:
Each pizzeria also gets an admin page, with self-serve API keys and a widget to manage users, groups and admins:
Pricing and lock-in
There's no subscription. You pay per request, with every check (sign-in, permissions, rate limits) included, so an API nobody calls costs nothing. If you outgrow it, one command exports your setup to a runnable Kong bundle: config, users, groups and API keys (as hashes, so your callers keep theirs).
- Site: apiblaze.com
- Docs: apiblaze.com/docs
- The demo, step by step: apiblaze.com/docs/full-test-project
- CLI: npmjs.com/package/apiblaze
APIblaze is in beta. I'd love to hear where it breaks on your stack.
Top comments (0)