Ship an API in one command
Don’t like reading docs?
Type this in your favorite agent:
❯ Tell me what apiblaze can do for me using npx apiblaze skillsClaude Code or Codex installs the skill into your project and answers from it. Then it can do the work for you: put a proxy in front of your app, add sign-in and API keys, lock records to whoever created them, and hand you the snippets for your own code.
No account needed to start — the first proxy runs in an anonymous workspace you can claim later.
Everything below works without an account — the CLI or a plain curl call. One command gives you a proxy, an MCP server, both sign-in doors and resources locked to whoever created them. This is the whole of it:
~/code/mybackend $
Quickstart
Point APIblaze at your API — a plain base URL, or an OpenAPI file or URL. No account, no setup. You get a live proxy with both doors open: an API key for your own backend and widget, and a GitHub sign-in for people and agents. Point it at a spec and it also offers to lock every resource to whoever created it. Pick your tool:
$ npx apiblaze create --target https://ninopizzas.com/openapi.yaml
--target is an OpenAPI document (https://ninopizzas.com/openapi.yaml) — creating FROM the spec.
Create an API proxy
? Proxy name: docsdemo1
? Should only creators of a resource in the API be able to amend that resource?
(press space to untick one · a toggles all · enter accepts — every box starts ticked)
❯◉ 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): julien@apiblaze.com
You are about to create a proxy and an MCP to your backend, authenticated by both:
API key — npx apiblaze consumer apikeys (list and create keys)
OAuth — npx apiblaze consumer login (APIblaze login with GitHub)
Rules: restaurants, reservations and tables — only their creator, or an admin, can change them
Admin: julien@apiblaze.com — can change anything
? Create proxy "docsdemo1" from https://ninopizzas.com/openapi.yaml? Yes
✓ https://docsdemo1.abz.run/1.0.0/dev — your backend and widget use the API key; people and agents use an APIblaze login (with GitHub)
/dev → https://backend.resiresi.com
/test → https://backend.resiresi.com
/prod → https://backend.resiresi.com
✓ restaurants, reservations + tables locked to their creator
API key (for your backend and widget — shown once, save it now):
sk_dev_pmtUZMCeGr_…
Send it as X-API-Key and say who is calling with X-End-User-Id.
(Separate keys were also created for: test, prod.)
Try it — copy/paste:
curl https://docsdemo1.abz.run/1.0.0/dev/restaurants -H "X-API-Key: sk_dev_pmtUZMCeGr_…" -H "X-End-User-Id: you"
X-End-User-Id = who your server is acting for; the rules check that person (any handle works for a test).
MCP URL (for agents): https://docsdemo1.mcp.abz.run/1.0.0/dev
? Connect an agent to it now? Claude Code (detected) # also Codex · "Not now"
✓ admin: julien@apiblaze.com — active on first sign-in
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
? Do you want to chat with your API now? Yes # hands you straight to apichatAll three paths create the same thing: a serverless proxy in front of your API, an MCP server for agents, and a hosted dev portal. The transcript above is a logged-in run, so the proxy lives on the permanent domain abz.run. Run the same command logged out and you get the identical questions on tryabz.run instead, plus one extra line — ⚠ Anonymous — claim within 30 days or it expires. — and the command to keep 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
The last question create asks is “Do you want to chat with your API now?” — say yes and you land in the chat straight away. npx apiblaze apichat <name> is how you come back to it later, and apichat --target <spec> is how you chat with an API that isn't yours.
Come back to a proxy you made
$ npx apiblaze apichat docsdemo1
Chat with your API · docsdemo1.mcp.abz.run
Ask a question in plain English. /exit to quit · /login for more free chats · /claim to keep this workspace
you › which restaurants are there?
agent › ⚙ list_restaurants…
✓ list_restaurants (ok, 412ms)
…then the answer, in plain English, from what your API actually returned.
# wire it into Claude Code or Codex instead of chatting here:
$ npx apiblaze apichat docsdemo1 --install-mcp claudeChat with someone else's API
$ npx apiblaze apichat --target https://ninopizzas.com/openapi.yaml --name pizzachat
✓ proxy https://pizzachat.tryabz.run/1.0.0/prod
✓ mcp https://pizzachat.mcp.tryabz.run/1.0.0/prod
Claude/ChatGPT-connectable (GitHub sign-in) · access: open — anyone who signs in can call this API
Anonymous workspace — /claim inside the chat to log in and keep it beyond 30 days.
Chat with your API · pizzachat.mcp.tryabz.run
you › which restaurants are there?- •
--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. It builds the same thingcreatedoes: a live proxy plus an MCP server. - • 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). - • The per-turn
curltrace is hidden by default; add--verboseto see the exact call behind every answer. - •
--install-mcp claude(orcodex) wires the proxy into that agent instead of chatting in the terminal;--remove-mcpunwires it.--access invitelimits the API to you plus the emails youpreapprove;--access openlets in anyone who signs in. - • 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 · approve to route it: npx apiblaze sidecar approve api.stripe.com
$ npx apiblaze sidecar approve api.stripe.com
✔ Approved https://api.stripe.com → proxy scapistripecom3f9a21. Your app will route it within ~5 min.
$ npx apiblaze sidecar deny analytics.example.com # ✔ Dismissed — it won't be suggested again
$ npx apiblaze sidecar remove api.stripe.com # ✔ goes direct again (deletes the proxy)
$ npx apiblaze sidecar # list what's routed and what's still a candidate- •
initalso generates a dev-only/abz-inspectorpage (skip with--no-inspector) and writesAPIBLAZE_API_KEYinto a gitignored.env.local. SetAPIBLAZE_SIDECAR=offthere to turn the whole thing off without removing anything. - • Approving or removing an origin takes about 5 minutes to reach your running app — the routes list refreshes on a timer.
- • 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- • You already have one.
createpublishes an MCP server for every proxy and prints its address —https://docsdemo1.mcp.abz.run/1.0.0/dev— then offers to connect Claude Code or Codex for you. apichat does the same. This section is for curating which routes become tools. - • Four addresses serve the same server, so use whichever fits:
{project}.mcp.abz.run/{version}/{environment}(what the CLI prints),{project}.mcp.tryabz.run/…(before you claim it),{project}.mcpblaze.com/…, and the tenant-explicit{project}-{tenant}.mcp.apiblaze.com/…that/publishreports. (A tenant is a named workspace for a group of your users, like one customer company.) - • Tools speak real MCP:
tools/listandtools/callover JSON-RPC 2.0, with path/query/body marshalling and streaming. - • Agents get in through the same doors as any other caller: MCP clients like Claude and ChatGPT use the GitHub sign-in, and a script can send the API key instead.
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 acme "users see only their own rows" — the project comes first, the sentence second. One shot, saved in watch-only mode by default, --enforce to turn it on immediately. Drop the sentence entirely (npx apiblaze rule acme) and you get the same checkbox create showed you, with nothing billed.
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. - • The two calls differ in one default. This HTTP call opens the API-key door only (
auth_typedefaults toapi_key).npx apiblaze createopens both doors — key and GitHub sign-in. The Authentication section has the exact body that matches the CLI.
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"target": "https://pokeapi.co",
"name": "pokeproxy"
}'Authentication
npx apiblaze create opens both doors: an API key for your own code, and an APIblaze GitHub sign-in for people and agents. One flag closes one of them — --apikey keeps only the key, --oauth keeps only the sign-in, --auth none opens the API to anyone. Over plain HTTP you control the same thing 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.
Both doors — what you get with no flag at all
curl -sX POST https://api.apiblaze.com/proxy \
-H 'content-type: application/json' \
-d '{
"target": "https://api.example.com",
"auth_type": "api_key",
"requests_auth": { "mode": "authenticate", "methods": ["api_key", "jwt"] },
"login": { "providers": [{ "type": "github", "managed": true }] }
}'
# the bootstrap keys ARE minted (one per environment) AND the GitHub sign-in is
# provisioned. Add "preapproved_users_only": true inside requests_auth to let in
# only you and the emails you pre-approve.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 key only — close the sign-in door with --apikey
# keys are minted either way. --apikey is how you say "key only, no GitHub sign-in".
$ npx apiblaze create --target https://api.example.com --apikey
✓ https://myapi.abz.run/1.0.0/dev — callers send the API key (X-API-Key) — no sign-in
API key (for your backend and widget — shown once, save it now):
sk_dev_… # also minted for test & prod
# 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), and NO API key:
# --oauth closes the key door that create opens by default.
$ 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 protects what people make by default: 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 and can untick the whole list before anything is turned on.
It is one question, asked in the middle of the quickstart transcript — a checkbox with every resource already ticked. Untick what should stay open, press enter, and that is it. Here is what those ticks do to real requests, on the proxy that transcript created:
# 1. Listing a collection stays open to anyone who gets in.
$ curl https://docsdemo1.abz.run/1.0.0/dev/restaurants \
-H "X-API-Key: sk_dev_…" -H "X-End-User-Id: you"
→ 200 [ … ]
# 2. Creating is open too — that POST is how the proxy learns who owns the new thing.
$ curl -X POST https://docsdemo1.abz.run/1.0.0/dev/restaurants \
-H "X-API-Key: sk_dev_…" -H "X-End-User-Id: ana" \
-H 'content-type: application/json' \
-d '{"slug":"ana-trastevere","name":"Ana Trastevere"}'
→ 201 { "id": "…", "slug": "ana-trastevere", … }
# 3. Ana created it, so Ana can read it back.
$ curl https://docsdemo1.abz.run/1.0.0/dev/restaurants/ana-trastevere \
-H "X-API-Key: sk_dev_…" -H "X-End-User-Id: ana"
→ 200 { "slug": "ana-trastevere", … }
# 4. Same key, same URL, different person → refused. Your backend did not change.
$ curl https://docsdemo1.abz.run/1.0.0/dev/restaurants/ana-trastevere \
-H "X-API-Key: sk_dev_…" -H "X-End-User-Id: ben"
→ 403- • What stays open to any caller who gets in: listing a collection (
GET /restaurants), creating a thing (POST /restaurants— 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./restaurants/ana-trastevere. The checkbox sentence tells you which verbs each resource actually has. - • Who "the person" is: whoever the call is attributed to. A signed-in caller is their account. Your backend holds one shared key and names the person per request with
X-End-User-Id, exactly as above. Or issue a key to one person —npx apiblaze apikeys mint --tenant «portalteststenant» --for «alice@example.com»— and every call made with it counts as Alice, no header needed. - • Review or change the list any time with
npx apiblaze rule «docsdemo1»— the same checkbox, no sentence needed, nothing billed. Turn enforcement off withnpx apiblaze config «docsdemo1» authorization.enforce_authorization false. - • The admin is the email
createasks for right after the checkbox. Admins bypass every ownership rule. Add more later:npx apiblaze admins add «teammate@example.com» --tenant «portalteststenant». An admin who has never signed in shows as active on first sign-in. - • Where it lives:
https://«docsdemo1».abz.run/1.0.0/devis name, API version and environment; the proxy belongs to a customer workspace (tenant) — pass--tenant «slug»to pick one, otherwise your team's most recently used tenant is reused, or«docsdemo1»defaulttenantis created.--autoand--jsoncreates take every default (both doors, every resource locked, no admin, no agent) with no prompts at all. - • 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
The creator-only lock that create sets up covers most of what people need. When you want something it can't express — "managers see everyone's reservations" — describe it in plain English and the proxy enforces it; your backend doesn't change. A rule written this way starts in watch-only mode (called "shadow"): it reports what it would have blocked on real traffic, without blocking anything, until you turn enforcement on.
# no sentence = the same checkbox create showed you. Free, and not a chat.
$ npx apiblaze rule docsdemo1
# a sentence = an LLM turn, billed. The project still comes first.
$ npx apiblaze rule docsdemo1 "users see only their own reservations; managers see all"
✓ rule created — watch-only for now:
reporting what it WOULD block, blocking nothing
# happy with the report? turn it on:
$ npx apiblaze rule docsdemo1 "users see only their own reservations; managers see all" --enforce
GET /restaurants/nino/reservations/42 # john · owner → 200
GET /restaurants/nino/reservations/42 # alice · nobody → 403
GET /restaurants/nino/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>. Writing a sentence is billed per turn; picking from the checkbox is not. - • 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
# --end-user-rate is a fairness sub-limit INSIDE one credential: with a shared
# backend key, no single X-End-User-Id can starve the others.
$ npx apiblaze throttle myapi --end-user-rate 2
# add --verbose to any command to see the exact API calls it makesuserRateLimit is requests/second per credential — one API key or one signed-in caller. endUserRateLimit (the --end-user-rate flag) divides that allowance between the people a shared credential is acting for, read from X-End-User-Id; it only applies to credentialed calls, and the credential cap still bounds the total. proxyQuota with quotaPeriod (daily / weekly / monthly) caps total volume. Callers over any limit get a clean 429.
Dev-portal login
Every proxy gets a hosted developer portal, and create already provisions an APIblaze-managed GitHub sign-in for it. Change the providers here — your own OAuth app, per-provider token types — or use --oauth to make the sign-in the only door.
Managed GitHub — sign-in only, no API key
$ npx apiblaze create --target https://api.example.com --oauth
✓ https://myapi.abz.run/1.0.0/dev — callers use an APIblaze login (with GitHub) — no API key
# plain `npx apiblaze create --target https://api.example.com` provisions the SAME GitHub
# sign-in and mints the bootstrap API keys as well. --oauth is how you drop the keys.Bring 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)
Run create, dev, apichat or init without logging in and the proxy 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, and everything you made while logged out comes with it.
⚠ Anonymous — claim within 30 days or it expires. To claim these proxies:
npx apiblaze login && npx apiblaze claim G7QN-62JB-VN3D-RQNR-F6EZ
# on the machine that created them you can drop the code — the CLI remembers:
$ npx apiblaze login && npx apiblaze claim
# merge into a team you already have instead of promoting a new one:
$ npx apiblaze claim G7QN-62JB-VN3D-RQNR-F6EZ --team my-team- • 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. - • Pick a team, or accept the new one created for you. Done —
oceanfox2240is permanently yours, along with everything else you made while logged out (keys, settings, other proxies). - • Already chatting?
/claimworks inside apichat — your conversation is preserved and the chat re-points at the permanent host.
After claiming, your proxy serves on the permanent domain abz.run instead of the try-it domain tryabz.run — and its MCP server moves from {project}.mcp.tryabz.run to {project}.mcp.abz.run with it.
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 create --target https://ninopizzas.com/openapi.yaml # THE command: proxy + MCP,
# both doors, resources locked to their creator
npx apiblaze create --target https://pokeapi.co # no spec? same thing, nothing to lock yet
npx apiblaze create --target https://pokeapi.co --apikey # …API-key door only, no sign-in
npx apiblaze dev 3000 # the same, with localhost behind a tunnel
npx apiblaze apichat myapi # chat with a proxy you made
npx apiblaze apichat --target <url|file> # chat with someone else's API, no login
npx apiblaze rule myapi # review / change the ownership rules
npx apiblaze integration myapi --stack nextjs # the snippets to paste into your app
npx apiblaze admins add you@example.com --tenant acme # who bypasses the rules
npx apiblaze init # sidecar into a Next.js app
npx apiblaze login && npx apiblaze claim # claim an anonymous workspace
npx apiblaze config myapi # browse & change EVERY setting
npx apiblaze docs # ask a chatbot — it can act on your account
npx apiblaze skills --install # teach Claude Code to do all of the aboveWhat 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. The address names
# the workspace your users live in (the tenant), not the proxy — with the product tag
# in front of it when the proxy has one:
https://{tenant}.portal.apiblaze.com/{version}
https://{product}-{tenant}.portal.apiblaze.com/{version}
# or from the terminal. The first two are the ones create prints in its plan block:
$ npx apiblaze consumer login --tenant portalteststenant # device-flow login
$ npx apiblaze consumer apikeys # list keys (reveals expiring ones), offer to create
$ npx apiblaze consumer tokens # show the access / refresh / id tokens
$ npx apiblaze consumer logs # stream YOUR OWN requests on this tenant, livePrefer 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 opens BOTH doors — auth_type api_key plus a managed GitHub login — unless --apikey, --oauth or --auth closes one |
| 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 (per credential) + endUserRateLimit (per person inside one credential) + 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.