Documentation

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

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

apiblaze — try it, no signup
$npxapiblaze create--target --apikey

--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 — one command, no signup
$ 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
$ 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)
  • --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.
  • 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).
  • 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-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

$ 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)
  • init also generates a dev-only /abz-inspector page (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
$ 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 example acme-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/list and tools/call over 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.

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 "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 (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.
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

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 — 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 keys — opt in with --apikey

npx apiblaze create --apikey — the opt-in: key-protected, bootstrap keys printed
# 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 --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
# 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 — 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 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 — the questions it asks, and the three lines you get back
$ 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/DELETE on 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 an X-End-User-Id header instead.
  • Review or change the list any time with npx apiblaze rule «nino» — the same checkbox, no sentence needed. --auto and --json creates 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 — plain English, one shot
$ 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.
  • 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>.
  • 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

# add --verbose to any command to see the exact API calls it makes

userRateLimit 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 — sign-in is what you get with no flag; --oauth spells it out
$ 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 minted

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)

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.

step 1 — the create response already gave you the link
$ 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_url in 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 — bravotiger4821 is 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.

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

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
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 tokens

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 defaults to oauth)
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 + 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.