apiblaze

Superseded 2026-09-24 for throttling, quota and credits by specs/TQC/final_throttling_quota_credits.MD. Upstash is gone; anything below about Redis keys, Lua gates, leases-on-Upstash or the reclaim crons is historical. Money history is the money ledger (apiblaze billing history, apiblaze op ledger).

CLI for APIblaze — chat with your APIs, run them as serverless proxies, and let your customers self-serve keys, users & groups from your own site.

Install

npx apiblaze --help        # run without installing
npm install -g apiblaze    # or install globally

Requires Node.js 18+.

Running as npx mcpblaze

mcpblaze is the same CLI under its MCP name: a thin wrapper that runs this package with APIBLAZE_BRAND=mcpblaze. Every command and flag is identical; the wording changes — create says "Create an MCP server", the thing you make lives at https://{name}-{tenant}.mcpblaze.com/{version}/{env}, and the demo after a create is connecting Claude Code or Codex to it rather than a curl. Set APIBLAZE_BRAND=mcpblaze yourself to get the same output from npx apiblaze.

Quick start

The easiest way is to just chat with it:

npx apiblaze agent

Talk in plain English — "make an API for httpbin.org", "set its rate limit to 50/sec", "give me a key". It does the work and shows what each step costs.

Prefer commands? A few one-liners:

# Chat with your API
npx apiblaze apichat --openapi https://apiblaze.com/pokeapi_openapi.yaml

# Make an API in one line — no account needed (prints a claim URL).
# Both doors open by default: an API key for your backend and widget (send X-API-Key and
# say who is calling with X-End-User-Id), and GitHub sign-in for people and agents.
# --apikey = the key door only; --oauth = the sign-in door only.
npx apiblaze create --target https://api.example.com

# Or build it straight from an OpenAPI spec — a URL or a local file.
# The routes, the API version and one environment per `servers` entry all come from the spec,
# and you're asked which resources to lock to the person who created them (e.g. /reservations).
# At the end it offers to connect Claude Code or Codex to the new MCP server — by default with
# an API key issued to you (works on the first message), or with GitHub sign-in.
npx apiblaze create --target https://petstore3.swagger.io/api/v3/openapi.json

# Same thing with zero prompts: both doors, every lockable resource locked.
npx apiblaze create --target ./openapi.yaml --auto

# Teach Claude Code to do all of the above for you when you say "ship this API"
npx apiblaze skill --install

# Configure how your backend is accessed through the proxy
npx apiblaze config

# Configure who accesses your backend through the proxy
npx apiblaze tenant

# Your local code, shipped safely: both doors, resources locked to their creator,
# an admin, Claude Code connected — with localhost as the target, through a tunnel.
npx apiblaze dev --port 3000 --openapi ./openapi.yaml

# What to add to your frontend + frontend-server (widgets, call-through, env vars)
npx apiblaze integration myapi --stack nextjs

# Route a Next.js app's outbound fetch() through APIblaze
npx apiblaze sidecar

# Sign in to manage APIs under your team
npx apiblaze login

Skill

npx apiblaze skill --install writes .claude/skills/ship-safely/SKILL.md into your project. From then on, when you tell Claude Code to ship, expose or add auth to an API, it puts APIblaze in front of your code instead of hand-rolling auth: it uses the control-plane MCP (claude mcp add --transport http apiblaze https://mcp.apiblaze.com, then /mcp to sign in once) to create the server, propose and apply the ownership rules, add an admin, issue keys and hand you the integration snippets — your backend does not change. Under npx mcpblaze the same skill names MCPblaze and mcp.mcpblaze.com; it is the same server.

skills is an alias of skill — Claude Code's folder is .claude/skills/, so both spellings do the same thing:

npx apiblaze skill              # print SKILL.md to stdout
npx apiblaze skills             # identical
npx apiblaze skills --install   # write .claude/skills/ship-safely/SKILL.md (add --force to overwrite)

Where your callers sign in

The skill teaches Claude to ask "where do your users sign in today?" before creating anything, because a multi-tenant app usually already has a login and its users should not get a second one. Three shapes, exactly as create --oauth (and dev --oauth) accepts them:

# 1. Nothing passed — both doors: an API key for your server, plus hosted GitHub sign-in
#    for people and agents. Bare --oauth narrows it to the sign-in door alone.
npx apiblaze create --target https://api.example.com

# 2. YOUR OWN OAuth app on a hosted login page — the agent's users sign in exactly where
#    your users already do. provider is one of: oidc · auth0 · google · github · microsoft · facebook.
#    clientSecret is optional for every provider except github and facebook (public client, PKCE is always on).
npx apiblaze create --target https://api.example.com \
  --oauth «'{"provider":"auth0","issuer":"https://acme.auth0.com/","clientId":"AbC123…","clientSecret":"s3cr3t…"}'»
#    Any OpenID Connect IdP (Okta, Entra, Keycloak, Cognito, …) is `oidc` + its issuer URL:
npx apiblaze create --target https://api.example.com \
  --oauth «'{"provider":"oidc","issuer":"https://acme.okta.com/oauth2/default","clientId":"0oa…"}'»

# 3. YOUR OWN JWT issuer — no login page at all; the proxy verifies the tokens you already
#    issue. All three fields are required; jwks is that issuer's JWKS URL.
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"}'»

Your tenants then self-serve their own keys from the key widget inside your app (npx apiblaze integration <name> --stack nextjs), your frontend-server holds one server key and says who is calling with X-End-User-Id, and npx apiblaze apikeys mint --tenant <tenant> --for <email> mints a key bound to one person.

Embeddable widgets (React)

Let your customers self-serve from your site — API keys (<ApiKeyWidget/>) and users, groups & admins (<UsersGroupsWidget/>). Each is one server route holding your Widget key (Dashboard → Developers) plus one component; the browser only ever talks to your backend — no secrets in the client. One getUser maps your session ({ tenant, userId, email }); both widgets share the same key.

// app/api/apiblaze/keys/route.ts    → <ApiKeyWidget/>
import { createApiblazeKeys } from 'apiblaze/server';
const keys = createApiblazeKeys({ cpKey: process.env.APIBLAZE_CP_KEY!, getUser });
export const GET = keys.handler, POST = keys.handler;

// app/api/apiblaze/groups/route.ts  → <UsersGroupsWidget/>   (same key)
import { createApiblazeGroups } from 'apiblaze/server';
const groups = createApiblazeGroups({ cpKey: process.env.APIBLAZE_CP_KEY!, getUser });
export const GET = groups.handler, POST = groups.handler;

'use client';
import { ApiKeyWidget, UsersGroupsWidget } from 'apiblaze/react';

<ApiKeyWidget theme={{ accent: '#7C3AED' }} />;        // keys: create · rotate · revoke
<UsersGroupsWidget theme={{ accent: '#7C3AED' }} />;   // users · nested groups · co-admins · seen-in-traffic

Every color and font is a theme token — white-label to any brand. Eligibility and admin rights are decided on your server from your session, never the browser.

Help

apiblaze --help            # all commands
apiblaze help create       # help for one command
apiblaze domain --help     # subcommands of a group (domain/tenant/key/spec)

Add --verbose (or -v) to any command to print the exact series of API calls it makes — as copy-pasteable curl you could run yourself with your own login token, plus the underlying admin-api leaf each one drives:

apiblaze limits set myapi --rate 50 --verbose

Commands

Chat

| Command | What it does | |---|---| | apiblaze agent | Chat about anything — create, configure, and inspect your APIs | | apiblaze agent openapi <project> | Chat to build your API spec from real traffic | | apiblaze agent authz <project> | Chat to design and turn on access rules | | apiblaze agent mcp <project> | Chat to build an MCP server for your API |

Every chat turn shows its cost.

Setup

| Command | What it does | |---|---| | apiblaze create --target <url> | Make an API from a backend (no account needed). Both doors by default: an API key for your code, GitHub sign-in for agents. --apikey / --oauth open one door only | | apiblaze create --target <file\|url> | Make an API from an OpenAPI spec — a local file or a spec URL. Asks which resources to lock to their creator, then offers to connect Claude Code / Codex; --auto locks them all | | apiblaze skill [--install] | Print (or install into .claude/skills/) the Claude Code skill that teaches Claude to ship your API safely with APIblaze. apiblaze skills is the same command; --force overwrites an existing SKILL.md | | apiblaze sidecar | Route a Next.js app's external fetch() calls through APIblaze (one command) | | apiblaze dev --port <p> [--openapi <spec>] | The hero command for code on this machine: everything create does, with localhost as the target through a tunnel. Without --openapi it looks for /openapi.json, /openapi.yaml, /docs/openapi.json on that port. --auto = every answer is the default | | apiblaze integration <name> --stack nextjs | What to add to your frontend and frontend-server (also express, fastapi, other): the widgets, the call-through with the key + X-End-User-Id, what your backend must trust, env vars, what stays open. --json for the raw kit | | apiblaze login / logout | Sign in / out (logout asks producer or consumer) | | apiblaze whoami | Who am I — both Producer and Consumer | | apiblaze team [name] | Switch team | | apiblaze claim [code] | Claim an API you made before signing in |

Producer — your APIs

| Command | What it does | |---|---| | apiblaze projects | List your APIs | | apiblaze delete <project> | Delete it and everything under it (asks first) | | apiblaze domain add <project> --domain <host> | Add your own domain (shows the DNS records to set) | | apiblaze domain status / list / rm <project> | Check / list / remove custom domains | | apiblaze domain set-base <project> [--env <e>] | Pick which version/env your main URL serves | | apiblaze tenant create --name <name> | Create a tenant (a separate group of your API's users) | | apiblaze tenant attach <project> --tenant <slug> | Give a proxy its own set of users | | apiblaze tenant cors --tenant <slug> --origins <a,b> | Set which websites can call it | | apiblaze tenant list / delete <slug> | List / delete tenants |

Producer — users, groups & authorization

| Command | What it does | |---|---| | apiblaze group create / list / delete <name> | Manage a tenant's groups (also <UsersGroupsWidget/>) | | apiblaze group add-user / remove-user <user> <group> | Put a user in a group (or take them out) | | apiblaze group add-group / remove-group <child> <parent> | Nest a group inside a group | | apiblaze rule <project> [--enforce] | Lock the spec's resources to the person who created them (or an admin) — tick what to lock, save, turn on | | apiblaze rule <project> "<plain english>" | Describe any other access rule in one shot (billed per turn; shadow, then --enforce) | | apiblaze config <project> authorization.enforce_authorization false | Turn the rules off (they stay saved) | | apiblaze agent authz <project> | Design & turn on authorization interactively (chat) |

Producer — change a proxy's config

| Command | What it does | |---|---| | apiblaze target <project> --url <url> [--env <e>] | Change where it forwards requests | | apiblaze rename <project> --display-name <name> | Rename it | | apiblaze spec get <project> | Print its OpenAPI spec | | apiblaze spec set <project> --file <path> | Replace its OpenAPI spec from a file |

Producer — limits

Three names, fixed: rate limit (requests per second per consumer key — approximate per location, free, a burst may briefly exceed it), quota (an exact count per fixed UTC window) and spend cap (exact dollars per month). Every rate is shown with its 10-second figure beside it (50/s (500 per 10 s)), because that is the window the Standard limiter counts.

| Command | What it does | |---|---| | apiblaze limits get <project> [--version v] | Show mode, rate limits, ceiling, quota, spend cap, credential quota | | apiblaze limits set <project> [--rate n] [--end-user-rate n] [--quota n --period daily\|weekly\|monthly] [--spend-cap usd] [--credential-quota n] | Change any subset (--quota none / --spend-cap none clear). A rate above the self-serve ceiling is refused and the output prints the exact limits request-max command | | apiblaze limits request-max <project> --rps n [--use-case "…"] | Ask for a higher ceiling (instant to 1,000/s for a proven wallet; an operator approves above) | | apiblaze limits usage <project> [--watch] | The team quota meter: used / in use / limit / resets in. Per-project usage is not exposed by the API yet — the output says so | | apiblaze config <project> limits.<key> [value] | The same settings by key: limits.mode, limits.consumerRps, limits.endUserRps, limits.ceilingRps (read-only), limits.quota.limit, limits.quota.period, limits.spendCapCents. The old throttling.* keys still work for one release |

apiblaze throttle <project> --rate n --quota n --period p still works for one release: it prints a deprecation line and runs limits set with the same numbers.

Producer — billing

| Command | What it does | |---|---| | apiblaze billing balance [--team] | Available, in use (pre-paid to live requests), grace owed, status, auto-rebuy, last top-up. Numbers are shown only to the wallet owner | | apiblaze billing topup <usd> [--team] [--open] | Prints (or opens) the dashboard wallet page for that amount — card checkout runs in your browser session | | apiblaze billing history [--since d] [--until d] [--project p] [--limit n] [--before cursor] [--format table\|json\|csv] [--raw] | The team's money ledger, newest first: pending lines (made by the wallet, not sent yet), then events (kind, amount, balance after) and 5-minute usage blocks (requests, amount); follows pages up to --limit (default 100) and prints a --before cursor when more remain. Then usage and exact cost per project as daily rollups; --raw = one usage row per 5-minute bucket | | apiblaze billing rebuy on\|off\|status [--amount usd] [--threshold usd] | Auto-rebuy: add --amount whenever available drops under --threshold |

When a call is refused for money or limits, every command prints the same thing for the same refusal (application/problem+json): service-paused shows the producer's contact and status page (and, if it is your wallet, the billing topup hint), trial-exhausted the claim URL, quota-exceeded when it resets, spend-cap-reached the limits set command, and platform-degraded when to retry.

Exit codes for every command: 0 ok, 1 your input (flags, not found, forbidden), 2 the server could not answer (5xx) — retry on 2.

Every command in these two sections accepts --verbose (see the equivalent API calls), plus --team, --apiversion, and --json.

Consumer — use an API

Log in to one of your tenants' portals as a consumer — handy for testing auth and keys end-to-end. This is a separate identity from your producer login; whoami shows both, and logout asks which to drop.

| Command | What it does | |---|---| | apiblaze consumer login --tenant <slug> | Log in to that tenant's portal (device flow in your browser); no producer account needed | | apiblaze consumer login | Producer shortcut: pick one of your team's tenants | | apiblaze consumer tokens | Show your consumer access / refresh / id tokens | | apiblaze consumer apikeys | List your API keys (reveals expiring ones in clear), then offer to create one |

--tenant uses the tenant's default login app; add --client <appClientId> to pick a specific one.

Advanced: apiblaze apikeys manages producer control-plane keys for scripting.

apiblaze dev — your local code, shipped safely

$ npx apiblaze dev --port 3000 --openapi ./backend/openapi.yaml

  Tunnel → http://localhost:3000
  Spec: ./backend/openapi.yaml
? Name: nino
? Do you want to prevent unauthorized users from taking unauthorized actions? Yes
? Lock these to the person who created them (or an admin): reservations, tables, restaurants
? Who is the admin? Their email address (Enter to skip): [email protected]

  ✓ https://nino.abz.run/1.0.0/dev  → localhost:3000   (sign-in with GitHub, or an API key)
  ✓ reservations, tables + restaurants locked to their creator · [email protected] is admin
  ✓ agents: https://nino-ninodefaulttenant.mcpblaze.com/1.0.0/dev

  API key (for your frontend-server, shown once): sk_dev_…   → send it as X-API-Key and say who is calling with X-End-User-Id

? Connect Claude Code to it now? Yes
  ✓ connected — it acts as [email protected]; try "Create a reservation, then show it to me."

  Tunnel is up — leave this running. Ctrl-C stops it.

No login needed (logged out, the proxy lives in an anonymous workspace you can claim). What it does, in order:

1. Reads your OpenAPI spec (--openapi, or /openapi.json · /openapi.yaml · /docs/openapi.json on the port). No spec → no rules; everything else still works.
2. Asks four short questions (name, lock resources, which ones, the admin) — --auto takes the defaults.
3. Creates the proxy with both doors open, points it at your machine through a tunnel, applies the rules, adds the admin (active now — a key issued to them creates their identity first).
4. Offers to connect Claude Code (or Codex) with a key that acts as the admin — nothing to sign in to.
5. Streams live traffic until Ctrl-C, then restores the project's original target.

If a project already points at this machine, dev offers to re-attach it instead (--project <name> picks one for scripts). Then npx apiblaze integration <name> --stack nextjs tells you what to add to your frontend and frontend-server.

Sidecar — proxy a Next.js app's egress

apiblaze sidecar wires your Next.js backend so its outbound fetch() calls transparently route through APIblaze. Each distinct upstream origin (Stripe, an internal API, anything) lazily becomes a first-class APIblaze proxy on first use — so you get identity, rate-limits, quotas, and audit wrapped around APIs that have none of it, with no per-call changes.

cd my-next-app
npx apiblaze sidecar     # logs you in, mints a scoped key, wires it up
npm install apiblaze
npm run dev              # then open http://localhost:3000/abz-inspector

The command mints a scoped data-plane key (create/use proxies for one team, nothing else) into gitignored .env.local as APIBLAZE_TOKEN + APIBLAZE_TENANT. Your control-plane login stays in ~/.apiblaze and never enters the project. It also writes instrumentation.ts:

import { register as apiblaze } from "apiblaze/sidecar";
export function register() { apiblaze(); }

The interceptor is stateless and fail-open: if it can't reach APIblaze it falls back to a direct fetch, so it never breaks your app. External HTTPS origins are intercepted; same-origin, localhost/private, and known analytics/CDN noise are left alone.

How it works

• No project yet? apiblaze dev sets one up (see above): both doors, rules from your spec, an admin, an agent — pointed at http://localhost:<port> and tunneled immediately.
• Server not running yet? If nothing is listening on the local port, requests aren't dropped: each one is printed in full (headers + body, with API keys/JWTs masked and JWTs decoded) and answered with a friendly synthetic 200. The moment your dev server comes up, the next request forwards to it automatically. Add --capture-file <path> to also stream every request/response to a JSON-lines file.

License

MIT