Documentation

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 skills

Claude 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:

Ask your agent to use APIblaze to ready your backend for launch

~/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 — one command, three questions
$ 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 apichat

All 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 <name>
$ 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 claude

Chat with someone else's API

npx apiblaze apichat --target <spec> — no login needed
$ 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?
  • --target is smart: a server base URL (the spec is auto-discovered at /openapi.json etc.), a local OpenAPI file, or a remote OpenAPI URL — JSON or YAML, detected automatically. It builds the same thing create does: a live proxy plus an MCP server.
  • If the upstream API needs a credential, you'll be prompted — or pass --target-auth-env MY_TOKEN to read it from an environment variable (CI-safe).
  • The per-turn curl trace is hidden by default; add --verbose to see the exact call behind every answer.
  • --install-mcp claude (or codex) wires the proxy into that agent instead of chatting in the terminal; --remove-mcp unwires it. --access invite limits the API to you plus the emails you preapprove; --access open lets in anyone who signs in.
  • Optional: npx apiblaze llm set-key stores 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 guide

The 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 — observe, then approve
$ 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
  • init also generates a dev-only /abz-inspector page (skip with --no-inspector) and writes APIBLAZE_API_KEY into a gitignored .env.local. Set APIBLAZE_SIDECAR=off there 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
$ 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. create publishes 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 /publish reports. (A tenant is a named workspace for a group of your users, like one customer company.)
  • Tools speak real MCP: tools/list and tools/call over 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.

the four builders
$ 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, /publish

For 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 (or target_url), openapi, or github.
  • Names auto-generate if omitted (two words + 4 digits). Set name, tenant, product_slug to 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 domain abz.run with standard keys.
  • The two calls differ in one default. This HTTP call opens the API-key door only (auth_type defaults to api_key). npx apiblaze create opens both doors — key and GitHub sign-in. The Authentication section has the exact body that matches the CLI.
curl — choose the names
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 — the exact body npx apiblaze create sends
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 — create a proxy with no caller auth
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

npx apiblaze create --apikey — no sign-in; callers send X-API-Key
# 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 --config

Accept third-party JWTs (your own issuer / audience)

npx apiblaze create --oauth — trust your 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"}'

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

npx apiblaze create — one flag, three login setups (and no API key)
# 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 — create a proxy that introspects tokens
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:

the four calls that show the rule working — all runnable
# 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/DELETE on 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 with npx apiblaze config «docsdemo1» authorization.enforce_authorization false.
  • The admin is the email create asks 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/dev is 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»defaulttenant is created. --auto and --json creates 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.

npx apiblaze rule <project> [sentence] — project first, sentence second
# 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.
  • managers is an ordinary group you fill in Users & Groups. Tenant admins are the built-in apiblaze_admins group — 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.

Ask: is John allowed to see reservation 42?
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 }
Record a fact: John owns reservation 42
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"
List everything John can access of one type
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. All POST.
  • 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
$ 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 makes

userRateLimit 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 --oauth — closes the API-key door create opens by default
$ 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 --oauth — APIblaze-hosted login page with YOUR Google app
$ 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 --config

Providers: 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 version · retarget an environment
# 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 myapi

Each 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
$ 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 one

Import a spec

Instead of a bare target, provision from an OpenAPI document — routes, schemas and docs arrive pre-populated.

curl — create from an inline OpenAPI document
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.

the CLI prints the two commands at the end of every anonymous create
  ⚠ 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_url in 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 — oceanfox2240 is permanently yours, along with everything else you made while logged out (keys, settings, other proxies).
  • Already chatting? /claim works 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.

bash
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 above

Full CLI reference

What 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.

what your consumers use
# 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, live

Prefer 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 / githubThe upstream source (exactly one)
name / subdomain / display_name / tenant / product_slugNaming — all optional, auto-generated
auth_typeShortcut: 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.modepassthrough or authenticate
requests_auth.methodsjwt / opaque / api_key
requests_auth.identified_traffic_onlyRequire a resolvable end-user identity
requests_auth.preapproved_users_onlyRestrict to pre-approved portal users
requests_auth.jwt.allowed_pairsAccepted third-party (iss, aud) pairs
requests_auth.opaqueIntrospection endpoint / method / params / body
requests_auth.key_typesCustom API-key types with scopes
auth_config.who_can_registeranyone / authorized_only (portal login)
login.providers[]Dev-portal OAuth providers (managed or BYO)
login.providers[].token_typeClient-side token: apiblaze / thirdParty
login.providers[].target_server_tokenForwarded token: apiblaze / third_party_* / none
environmentsPer-environment upstream targets
throttlinguserRateLimit (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.