Ship an API in one command
Don’t like reading docs?
Type this, then ask your favourite AI chatbot to do it for you:
$ npx apiblaze apichat --target https://api.mcp.apiblaze.com/openapi.jsonIt adds APIblaze as an MCP server to Claude Code or Codex — then you discover features and action them by asking: create a proxy, add a login, invite a teammate, point a custom domain.
Needs an account, since the tools act on your own proxies — npx apiblaze login is free and takes a few seconds.
Everything below works without an account — the CLI or a plain curl call. Try it live right here:
--apikey protects the proxy with a key (what this demo does). Without it, create defaults to sign-in with GitHub and mints no key.
Edit the URL, then hit Run — your API goes live instantly. No signup.
Quickstart
Point APIblaze at any URL. No account, no setup — you get a live proxy where callers sign in with GitHub (or, if you ask, present an API key). Pick your tool:
$ npx apiblaze create --target https://pokeapi.co
? How should callers sign in? Sign in with an account (OAuth) # the default — no API key is minted
✓ Live → https://bravotiger4821.tryabz.run/1.0.0/prod · callers sign in with GitHub
Portal: https://quietfox5093.portal.apiblaze.com/1.0.0
Claim URL: https://dashboard.apiblaze.com/claim?claimCode=G7QN-…
# call it — sign in once as a user of the API, then send the token
$ TOKEN=$(npx apiblaze consumer login --tenant quietfox5093 >/dev/null && npx apiblaze consumer tokens --json | jq -r .access_token)
$ curl https://bravotiger4821.tryabz.run/1.0.0/prod/api/v2/pokemon/ditto -H "Authorization: Bearer $TOKEN"
# prefer keys? add --apikey and the keys are printed instead (see Authentication)All three paths create the same thing: a serverless proxy in front of your API, with a sign-in door (or API keys) and a hosted dev portal. Since you didn't log in, the proxy isn't attached to an account yet — it works right away, but it's temporary. That's what the claim_url in the response is for: keeping it. (The next.js path is covered in depth in the sidecar section.)
Want the complete endpoint list? Jump to the Full API reference.
Chat with your API
Point apichat at any OpenAPI spec and start asking questions — no login needed. Under the hood it creates a live proxy and an MCP server, then opens a chat that actually calls your API.
$ npx apiblaze apichat --target https://apiblaze.com/pokeapi_openapi.yaml
✓ proxy live → https://pokeapi4821.tryabz.run/1.0.0/prod
✓ MCP server → pokeapi4821.mcp.apiblaze.com
you › what types is ditto?
agent › GET /api/v2/pokemon/ditto … → Ditto is a Normal-type Pokémon.
(the exact curl for every call is printed above each answer)- •
--targetis smart: a server base URL (the spec is auto-discovered at/openapi.jsonetc.), a local OpenAPI file, or a remote OpenAPI URL — JSON or YAML, detected automatically. - • If the upstream API needs a credential, you'll be prompted — or pass
--target-auth-env MY_TOKENto read it from an environment variable (CI-safe). - • Every turn prints the equivalent
curl, so the chat doubles as a live API explorer. Hide it with--no-verbose. - • Optional:
npx apiblaze llm set-keystores your own LLM key locally (OpenRouter / Anthropic / DeepSeek / OpenAI) — lifts model quality and bills your key instead.
The drop-in widgets — keys, groups & chat
Three React components your users see on your site, one shared pattern: a page with the component, and (for the server-backed ones) one API route on your backend that holds the APIblaze credential and answers “who is signed in?”. The browser never holds a secret.
| <ApiKeyWidget/> | your users mint, rotate and revoke their own API keys |
| <UsersGroupsWidget/> | your customers' admins manage their users and nested groups |
| <ChatWidget/> | your users talk to your API — a floating chat bubble that calls it live |
Full setup for all three — every value explained, with copy-paste frontend + backend tabs for NextAuth, Clerk, Auth0, Supabase or your own sessions:
The widgets guideThe Next.js sidecar
Install once, and every external call your app makes shows up in your dev console. Approve an origin and its traffic routes through APIblaze — auth, rate limits, observability — with zero code changes. What you don't approve is never touched.
$ npx apiblaze init # in your Next.js app; wires the sidecar + dev inspector
$ npm run dev
[apiblaze/sidecar] active — approved origins route through APIblaze; the rest go direct.
[apiblaze/sidecar] direct (not approved) → https://api.stripe.com
$ npx apiblaze sidecar approve api.stripe.com
✓ proxy created — api.stripe.com now routes through APIblaze
$ npx apiblaze sidecar deny analytics.example.com # stop suggesting it
$ npx apiblaze sidecar remove api.stripe.com # go direct again (deletes the proxy)- •
initalso generates a dev-only/abz-inspectorpage (skip with--no-inspector). - • No login needed — proxies created this way are temporary until you keep them, exactly like the quickstart one.
Publish an MCP server
Any proxy can serve as a Model Context Protocol server, so Claude, Cursor and other agents call your API as typed tools. Build the catalogue in a short chat, then publish.
$ npx apiblaze agent mcp acme
you › expose search + order lookup as tools
agent › search_products(q, limit)
get_order(order_id)
/publish
✓ Published MCP server — acme-acmecorp.mcp.apiblaze.com/1.0.0/prod- • The server address is
{project}-{tenant}.mcp.apiblaze.com/{version}/{environment}— for exampleacme-acmecorp.mcp.apiblaze.com/1.0.0/prod. (A tenant is a named workspace for a group of your users, like one customer company. If your proxy doesn't have one, the address is just{project}.mcp.apiblaze.com.) - • Tools speak real MCP:
tools/listandtools/callover JSON-RPC 2.0, with path/query/body marshalling and streaming. - • Access is OAuth-gated — agents authenticate like any other consumer of your API.
- • apichat publishes an MCP server automatically as part of its one-command setup.
Builder agents
Chat-driven builders that write configuration for you — each proposes, you review, then /publish. Billed per turn.
$ npx apiblaze agent # general: describe what you want, it makes the calls
$ npx apiblaze agent openapi acme # drafts your OpenAPI spec from real captured traffic,
# then /publish — or opens a GitHub PR to your repo
$ npx apiblaze agent authz acme # drafts access rules, tests them on real
# traffic watch-only, /enable to enforce
$ npx apiblaze agent mcp acme # picks routes to become MCP tools, /publishFor a single rule without a conversation, use npx apiblaze rule "users see only their own rows" acme — one shot, watch-only by default, --enforce to turn it on immediately.
The create request
POST https://api.apiblaze.com/proxy — no auth header. Provide exactly one source; everything else is optional and defaulted. Every option below also works as a --config file.json passed to npx apiblaze create.
- • One source, required:
target(ortarget_url),openapi, orgithub. - • Names auto-generate if omitted (two words + 4 digits). Set
name,tenant,product_slugto choose them. - • Created without an account, the proxy serves on the try-it domain
tryabz.run. Once you keep it, it serves on the permanent domainabz.runwith standard keys.
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"target": "https://pokeapi.co",
"name": "pokeproxy"
}'Authentication
Control how callers authenticate with auth_type (none | api_key | oauth) or the full requests_auth object (which wins when present). Every example below is the complete, runnable call — the highlighted part is the setting that turns the feature on. The same keys can be set later with npx apiblaze config.
No auth (passthrough)
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"target": "https://api.example.com",
"requests_auth": { "mode": "passthrough" }
}'API keys — opt in with --apikey
# without --apikey, create sets up sign-in and mints NO key — this flag is how you ask for keys
$ npx apiblaze create --target https://api.example.com --apikey
✓ Live → https://bravotiger4821.tryabz.run/1.0.0/prod
API key (prod): sk_prod_… # also minted for dev & test
# issue a key to one named person — calls made with it count as them:
$ npx apiblaze apikeys mint --tenant acme --for alice@example.com
# custom key types / identified-only: use the curl tab or --configAccept third-party JWTs (your own issuer / audience)
$ npx apiblaze create --target https://api.example.com \
--oauth '{"iss":"https://login.acme.com/","aud":"acme-api","jwks":"https://login.acme.com/.well-known/jwks.json"}'That's the whole thing — iss, aud, jwks_url. The end-user identity defaults to the token's sub claim. Only if your user id lives in a different claim do you add "endUserIdSource": "claim", "endUserIdClaimName": "email" (or map external subs to your users with "endUserIdTransformation": "map").
Sign-in doors — the three shapes of --oauth
# APIblaze-hosted GitHub sign-in (managed — nothing to register). This is what create
# does with no auth flag at all; --oauth just spells it out.
$ npx apiblaze create --target https://api.example.com --oauth
# YOUR hosted login: the proxy trusts your JWT issuer
$ npx apiblaze create --target https://api.example.com \
--oauth '{"iss":"https://login.acme.com/","aud":"acme-api","jwks":"https://login.acme.com/.well-known/jwks.json"}'
# APIblaze-hosted login page with YOUR OAuth app (github · google · microsoft · facebook · auth0)
$ npx apiblaze create --target https://api.example.com \
--oauth '{"provider":"google","clientId":"xxxx.apps.googleusercontent.com","clientSecret":"GOCSPX-xxxx"}'Full provider control (token types, scopes, callback URLs) lives in Dev-portal login.
Opaque tokens — introspect at your endpoint
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"target": "https://api.example.com",
"requests_auth": {
"mode": "authenticate",
"methods": ["opaque"],
"opaque": {
"endpoint": "https://auth.example.com/introspect",
"method": "POST",
"params": "?access_token={token}",
"body": "token={token}"
}
}
}'Lock an API down in one command
Give create an OpenAPI spec and it offers to protect what people make: only the person who created a thing — or a member of the apiblaze_admins group — can view, change or delete it. The rules are read straight from your spec (which routes create things, which routes touch one thing by id). No AI, no login needed, nothing changes in your backend. You see the list before anything is turned on.
$ npx apiblaze create --target ./openapi.yaml --name nino
? How should callers sign in? Sign in with an account (OAuth) # default · --apikey for keys
? Do you want to prevent unauthorized users from taking unauthorized actions? (Y/n) Y
? Which of these do you want on? (space toggles · a = all · enter accepts)
◉ Only the person who created a reservation — or an admin — can view, change or delete it.
◉ Only the person who created an order — or an admin — can view, change or delete it.
? Who is the admin? Their email: you@example.com
✓ Live → https://nino.abz.run/1.0.0/dev · callers sign in with GitHub
✓ Ownership rules ON for reservations, orders — enforcing
✓ you@example.com added as admin — active on their first sign-in
# try it — log in as a user of the API, then call it with the token
$ TOKEN=$(npx apiblaze consumer login --tenant nino >/dev/null && npx apiblaze consumer tokens --json | jq -r .access_token)
$ curl https://nino.abz.run/1.0.0/dev/reservations -H "Authorization: Bearer $TOKEN"
# changed your mind? this turns the rules off (they stay saved):
$ npx apiblaze config nino authorization.enforce_authorization false- • What stays open to any signed-in caller: listing a collection (
GET /reservations), creating a thing (POST /reservations— that is how the proxy learns who owns it), and action-style POSTs that do not create anything (POST /search). What gets locked:GET/PUT/PATCH/DELETEon one thing by id, e.g./reservations/42. - • Who "the person" is: the signed-in account. Using API keys instead? Issue the key to a person —
npx apiblaze apikeys mint --tenant «nino» --for «alice@example.com»— and every call made with it counts as Alice. A key shared by your backend identifies the user with anX-End-User-Idheader instead. - • Review or change the list any time with
npx apiblaze rule «nino»— the same checkbox, no sentence needed.--autoand--jsoncreates take the same defaults (sign-in, every rule on, admin step printed as a command) with no prompts. - • One catch: things created before the rules were on have no recorded creator, so only admins can reach them until you record owners (see Authorization from your backend).
Authorization rules
Rules like "users can only see their own reservations", enforced at the proxy — your backend doesn't change. New rules start in watch-only mode (called "shadow"): they report what they would have blocked on real traffic, without blocking anything, until you turn enforcement on.
$ npx apiblaze rule "users see only their own reservations; \
managers see all" reserv
✓ rule created — watch-only for now:
reporting what it WOULD block, blocking nothing
# happy with the report? turn it on:
$ npx apiblaze rule "…" reserv --enforce
GET /reservations/42 # john · owner → 200
GET /reservations/42 # alice · nobody → 403
GET /reservations/42 # maria ∈ managers → 200- • Ownership is captured at the proxy when objects are created — no backend changes.
- •
managersis an ordinary group you fill in Users & Groups. Tenant admins are the built-inapiblaze_adminsgroup — name it in the rule to let them through; it takes direct members only (no child groups). - • For an interactive design session over many routes, use
npx apiblaze agent authz <project>. - • Enforcement fails closed: if the policy engine is unreachable, requests are denied, not leaked.
Authorization from your backend
The same permission engine that guards your proxy is also a plain HTTPS API. Call it straight from your own backend to ask "is this user allowed?", or to record who owns what — even for requests that never go through your proxy. You define the model once in the dashboard (or with npx apiblaze rule); here you just read and write facts against it.
curl -sX POST https://policies.apiblaze.com/1.0.0/prod/v1/check \
-H 'x-api-key: sk_prod_…' \
-H 'content-type: application/json' \
-d '{ "tuples": [ { "user": "user:john", "relation": "owner", "object": "reservation:42" } ] }'
# → { "results": [ { "allowed": true } ], "all_allowed": true }curl -sX POST https://policies.apiblaze.com/1.0.0/prod/v1/write \
-H 'x-api-key: sk_prod_…' \
-H 'content-type: application/json' \
-d '{ "writes": [ { "user": "user:john", "relation": "owner", "object": "reservation:42" } ] }'
# to remove it later, send the same shape under "deletes"curl -sX POST https://policies.apiblaze.com/1.0.0/prod/v1/list-objects \
-H 'x-api-key: sk_prod_…' \
-H 'content-type: application/json' \
-d '{ "user": "user:john", "relation": "owner", "object_type": "reservation" }'
# → { "objects": ["42", "77"], "count": 2 }- • Four endpoints:
/v1/check,/v1/write,/v1/list-objects,/v1/read. AllPOST. - • Which tenant you're acting on comes from your API key — never from the URL, so one key can only ever touch its own data.
- • Each call is one ordinary request on your bill, at the same band price as a proxied call.
- • The model (what relations exist, how they nest) is authored in the dashboard or via
npx apiblaze rule; this API reads and writes facts, it doesn't change the model.
Throttling
Set a per-user rate limit and a proxy-wide quota — at creation or any time after.
$ npx apiblaze throttle myapi --rate 10 --quota 10000 --period daily
✓ userRateLimit=10 r/s · proxyQuota=10000/daily
# add --verbose to any command to see the exact API calls it makesuserRateLimit is requests/second per user; proxyQuota with quotaPeriod (daily / weekly / monthly) caps total volume. Callers over the limit get a clean 429.
Dev-portal login
Every proxy gets a hosted developer portal. Omit login for a default APIblaze-managed GitHub sign-in, or bring your own providers with per-provider token types.
Managed GitHub (the default, made explicit)
$ npx apiblaze create --target https://api.example.com --oauth
# the same as plain `npx apiblaze create --target https://api.example.com` — no API key is mintedBring your own Google — choose client & target-server token types
$ npx apiblaze create --target https://api.example.com \
--oauth '{"provider":"google","clientId":"xxxx.apps.googleusercontent.com","clientSecret":"GOCSPX-xxxx"}'
# providers: github · google · microsoft · facebook · auth0
# advanced (token types, scopes, callback URLs): use the curl tab or --configProviders: github · google · microsoft · facebook · auth0. token_type is what the browser receives; target_server_token is what gets forwarded to your API.
Versions & environments
Run old and new API versions side by side, point dev/staging/prod at different upstreams, and choose what your main URL serves.
# add a 2.0.0 alongside the existing 1.0.0 (serves at /2.0.0/…)
$ npx apiblaze create --name myapi --target https://api-v2.example.com --apiversion 2.0.0
# point one environment somewhere else
$ npx apiblaze target myapi --env dev --url https://dev.example.com
# choose which version/environment the bare domain serves
$ npx apiblaze domain set-base myapiEach environment gets its own API keys, so a leaked dev key never touches prod.
Custom domains
Keep the free subdomain, or serve your API from your own domain — APIblaze provisions the hostname and TLS.
$ npx apiblaze domain add myapi
→ set this DNS record at your provider:
CNAME api.yourcompany.com → <shown-target>.apiblaze.com
$ npx apiblaze domain status myapi
api.yourcompany.com ✓ TLS issued · ✓ active
$ npx apiblaze domain list myapi # all custom domains for a proxy
$ npx apiblaze domain rm myapi # remove oneImport a spec
Instead of a bare target, provision from an OpenAPI document — routes, schemas and docs arrive pre-populated.
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"openapi": "<full OpenAPI YAML or JSON document as a string>"
}'Importing straight from a GitHub repo (and keeping it in sync) is a one-click flow in the dashboard — it connects your GitHub once, then pulls the spec for you.
Already live without a spec? npx apiblaze agent openapi <project> drafts one from your real traffic — see Builder agents.
Keep your proxy (claiming)
The quickstart worked without an account, so the proxy you just made isn't attached to anyone yet. It runs immediately, but it's temporary: it gets deleted after 72 hours if it never receives a request, or after 30 days without traffic. "Claiming" it makes it permanently yours — it takes about 30 seconds.
$ curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{ "target": "https://pokeapi.co" }'
{
"project_id": "bravotiger4821",
…
"claim_url": "https://dashboard.apiblaze.com/claim?claimCode=G7QN-…"
}- 2. Open the
claim_urlin your browser and sign in with GitHub — that's also how you create an account if you don't have one. - 3. Pick a team, or accept the new one created for you. Done —
bravotiger4821is permanently yours, along with everything else you made while logged out (keys, settings, other proxies).
After claiming, your proxy also serves on the permanent domain abz.run instead of the try-it domain tryabz.run. Prefer the terminal? npx apiblaze login then npx apiblaze claim does the same thing — you don't even need the code if you're on the machine you created the proxy from.
The CLI
Everything on this page, from the terminal. npx apiblaze (Node 18+) — no install required. Add --verbose to any command to print the exact API calls it makes.
npx apiblaze apichat --target <url|file> # chat with any API, no login
npx apiblaze create --target https://pokeapi.co # go live behind GitHub sign-in, no signup
npx apiblaze create --target ./openapi.yaml # …from a spec: also offers to lock down what people create
npx apiblaze create --target https://pokeapi.co --apikey # …with API keys instead of sign-in
npx apiblaze rule myapi # review / change the ownership rules
npx apiblaze init # sidecar into a Next.js app
npx apiblaze dev 3000 # tunnel localhost, stream traffic
npx apiblaze login && npx apiblaze claim # claim it to your account
npx apiblaze config myapi # browse & change EVERY settingWhat your API's users get
The people who call your API (your "consumers") get a hosted portal — login, self-serve keys, live "try it" — plus their own CLI commands under apiblaze consumer.
# the hosted portal — login, self-serve keys, try endpoints live
https://{project}.portal.apiblaze.com/{version}
# or from the terminal:
$ npx apiblaze consumer login # device-flow login to a tenant's portal
$ npx apiblaze consumer apikeys # list keys (reveals expiring ones), offer to create
$ npx apiblaze consumer tokens # show the access / refresh / id tokensPrefer keys on your own page instead of the portal? That's the API-key widget.
Field reference
The create option set at a glance. The authoritative source for types, enums and defaults is the live OpenAPI spec at api.apiblaze.com/openapi.json — browsable in the API portal.
| target / target_url / openapi / github | The upstream source (exactly one) |
| name / subdomain / display_name / tenant / product_slug | Naming — all optional, auto-generated |
| auth_type | Shortcut: none / api_key / oauth (the HTTP call defaults to api_key; npx apiblaze create defaults to oauth) |
| requests_auth.mode | passthrough or authenticate |
| requests_auth.methods | jwt / opaque / api_key |
| requests_auth.identified_traffic_only | Require a resolvable end-user identity |
| requests_auth.preapproved_users_only | Restrict to pre-approved portal users |
| requests_auth.jwt.allowed_pairs | Accepted third-party (iss, aud) pairs |
| requests_auth.opaque | Introspection endpoint / method / params / body |
| requests_auth.key_types | Custom API-key types with scopes |
| auth_config.who_can_register | anyone / authorized_only (portal login) |
| login.providers[] | Dev-portal OAuth providers (managed or BYO) |
| login.providers[].token_type | Client-side token: apiblaze / thirdParty |
| login.providers[].target_server_token | Forwarded token: apiblaze / third_party_* / none |
| environments | Per-environment upstream targets |
| throttling | userRateLimit + proxyQuota + quotaPeriod |
Full API reference
Every endpoint of the APIblaze control-plane API — creating and configuring proxies, keys, tenants, users, groups and authorization — with request/response schemas, enums and defaults.
Prefer the raw spec? It's served as OpenAPI at api.apiblaze.com/openapi.json — import it into Postman, Insomnia or your own tooling.