Recipes, explained

A proxy is one API you run on apiblaze: a URL of your own that receives requests, checks who is calling, rewrites the request if it needs to, and forwards it to the real API behind it. A recipe is a frozen copy of one proxy's configuration — its settings, its login setup, its transform rules, its API description and the AI tools generated from that description.

It is one JSON file. @jayjaychicago/pokeapi is about 400 KB of it, most of which is a 97-route API description.

The name has two parts. @jayjaychicago is the handle — the publisher's namespace, claimed once and owned by their team. pokeapi is the recipe's name. Recipes also have a revision: 1, 2, 3. That is the version of the recipe, not the version of the API inside it.

We call it a recipe rather than a template or a package because a recipe lists ingredients you supply yourself. The publisher wrote down the method. You bring your own OAuth client, your own API key, your own account.

What a recipe is not

• It is not a copy of the publisher's account. No users, no API keys, no email addresses, no team identifiers. Not because they are stripped out, but because a recipe has nowhere to put them — there is no tenant inside a recipe, and a tenant is where users live.
• It never carries the publisher's credentials. Their Google client secret, their Stripe key, their private signing key: none of it travels. A recipe is assembled from a written-down list of fields that are allowed out, so anything not on that list was never read in the first place.
• It is not a running service. Installing does not point you at the publisher's proxy. It builds a new one, on your own URL, in your own account, billed to you.
• It is not inert data either. A recipe can carry transform rules, and those rules run on every request your proxy serves. There is a fence around what they may touch — see below.

Read one before you run it

Every public recipe is readable in full, by anyone, with no login. There is nothing hidden in it.

# the whole file$ npx apiblaze show @jayjaychicago/pokeapi # just one part of it$ npx apiblaze show @jayjaychicago/pokeapi --transforms

Or open /api/recipes/jayjaychicago/pokeapi/2 in a browser.

$ npx apiblaze install @jayjaychicago/pokeapi

You need an apiblaze account, because install creates things in it. If you are not signed in, run npx apiblaze login first — it opens a browser once and remembers.

What it asks you, and why

First, a name for the new proxy. It suggests one — mypokeapi — and you press enter or type your own. Names are lowercase letters and digits only, at least three characters: mypokeapi, never my-pokeapi.

The name comes first for a reason. Everything else is built from it. If the recipe needs an OAuth client, the redirect address you have to paste into Google's or GitHub's console is https://mypokeapiusers.auth.apiblaze.com/callback, and that address does not exist until the name does. Asking in this order means you do the console work once, in the middle of the install, and the install finishes finished — not "installed, now two more steps."

Then a summary, and a yes or no. Before anything is created you see what it will create, every host it will send requests to, what it will ask you for, and whether your API's description becomes public. Nothing happens until you answer.

Then the recipe's own questions — the values only you can supply. @jayjaychicago/pokeapi asks for two: an OAuth client ID and an OAuth client secret, because the publisher's proxy signs its users in with GitHub and the OAuth client has to be yours, not theirs.

• Secret answers are masked as you type.
• Each answer is held in memory and sent on the single step that needs it. The client secret goes to the step that creates your login provider and nowhere else. It is never written to a file and never echoed back.
• Running without a terminal? Answers come from environment variables — ABZ_ANSWER_OAUTH_CLIENT_SECRET — and never from a command-line flag, because a flag lands in your shell history and in your CI logs.

What gets created

One step at a time, reported as it goes, so a failure names the step rather than leaving you with a half-built proxy and a job id.

creating mypokeapi                 ✓  proxy + tenantsettings and environments          ✓GitHub login provider              ✓2 key types                        ✓6 transforms, 1 mapping table      ✓API spec → 97 routes, MCP tools    ✓ done in 18s.  proxy  https://mypokeapi.abz.run  mcp    https://mypokeapi-mypokeapiusers.mcp.apiblaze.com

A tenant is apiblaze's word for one set of your API's end users together with the login that serves them. Install always creates a brand-new one to hold the recipe's login setup. It never touches a tenant you already have, and it never copies one of the publisher's — there is no tenant in the file to copy.

Pinning a revision

@jayjaychicago/pokeapi means "the newest public revision", which today is revision 2. Tomorrow it might be 3. To install exactly the one you read, add @2:

$ npx apiblaze install @jayjaychicago/pokeapi@2

A published revision is frozen. Revision 2 is the same bytes forever — nobody can edit it in place, not even the publisher. Their fix becomes revision 3, and revision 2 keeps working for everyone who pinned it. The only way a revision changes is that it stops existing; withdrawing is that.

Whichever number you install is recorded on the proxy, so its history is always a specific revision, never "latest".

Skipping the prompts

# name it yourself, skip the rename question$ npx apiblaze install @jayjaychicago/pokeapi --as pokedex # re-run over a proxy that already exists (see below)$ npx apiblaze install @jayjaychicago/pokeapi --into pokedex # no terminal at all — CI, a script$ npx apiblaze install @jayjaychicago/pokeapi --as pokedex --yes

--yes answers the routine confirmations and declines everything on the consent list — exactly the same as pressing enter at that screen. A script can never agree, on your behalf, to a stranger's quota or a stranger's open-to-the-internet setting.

Re-running it, and when a step fails

If a step fails, the command tells you which one and why, and gives you the way back in. That way back is --into, which starts from step two — the proxy already exists, so it is never created twice.

$ npx apiblaze install @jayjaychicago/pokeapi --into mypokeapi

--into is also how you move an existing proxy to a newer revision. Same proxy, same URL, same API keys, same users — the configuration is replaced. Questions you already answered are not asked again.

A recipe can carry settings that change who can reach your proxy, what it trusts, and what it costs you. Install shows those settings on their own screen and makes you type yes. Press enter instead and it installs the recipe using your own current settings for everything on the list — which, for most recipes, is still a completely working proxy.

Every public recipe's page shows the same list before you run anything. Here is the real one for @jayjaychicago/pokeapi.

Publishing takes a proxy you already run and freezes a copy of it. You do not write a recipe file; the platform reads your live proxy.

$ npx apiblaze publish pokeapi

That becomes @yourgithubhandle/pokeapi. Your handle defaults to your GitHub login, so the first publish asks nothing — inventing a namespace before you have published anything is a decision you have no basis to make, and your GitHub login is already unique and already the name people know you by.

# set just the recipe name$ npx apiblaze publish pokeapi --as pokedex # set the handle too — a team that wants @acme claims it here$ npx apiblaze publish pokeapi --as @acme/pokedex # only your team can see or install it$ npx apiblaze publish pokeapi --private

Once claimed, a handle belongs to the team, not to the person; your GitHub login only seeds it. About 124 handles are reserved — @google, @stripe, @openai, plus apiblaze's own words like @admin and @portal — because the risk worth stopping is a recipe pretending to be the API it wraps. @jayjaychicago is instant.

Names cannot be changed later. Renaming would break every record of where an installed proxy came from, so this is settled at the start.

Public or private

Private is not a lesser mode. An internal platform team publishes @acme/billingapi once and every squad installs the same working setup instead of copying settings by hand.

Visibility is set per revision. Flipping a recipe from private to public publishes only from that point on — it does not retroactively publish the four private revisions you pushed while it was internal.

What the scanner does — and what it cannot promise

Before it freezes anything, publish reads inside every value it is about to send out — each entry of each mapping table, each transform rule, each field of the API description — and matches them against known secret shapes: AIza, sk-, ghp_, AKIA, xox, GOCSPX-, -----BEGIN … PRIVATE KEY, long high-entropy strings, email addresses, and private hostnames like .internal or 10.0.0.5.

Anything it flags stops the publish and asks you what to do with it:

checked 340 values against 9 known patterns. 2 need your decision:   transformations → rule "auth header" → X-Api-Key      AIzaSyD4k2...9mQ                      looks like a Google API key      [k] keep  [a] ask the installer  [r] remove   openapi → servers[0].url      https://relay.internal.acme.com       not a public hostname      [k] keep  [a] ask the installer we cannot judge the other 338 values. run with --show to read the whole recipe.

[a] is the interesting one: it turns that value into a question the installer answers for themselves, and replaces it in the file with a placeholder. That is how "my Salesforce instance URL" becomes "your Salesforce instance URL". Your choices are remembered on the proxy, so publishing revision 4 next month stops only for values that are new or newly suspicious.

Values that are already encrypted in your account are replaced with a marker rather than carried across. The ciphertext is tied to your proxy and could never be decrypted by an installer, so carrying it would only publish the fact that a secret sits at that spot.

It also tells you what it left out

A recipe contains only the fields on a written-down list. Everything else is excluded — not blocked, just never read. That is safe but silent, so every publish prints what did not travel and waits:

3 settings were not included, because they are not on the publish list:    rateLimit.perUser    cors.maxAge    listenToTraffic   continue without them? [y/N]

Nothing there can leak. The risk it catches is the opposite one — a recipe quietly missing a setting that ought to travel, which you can now see and report.

Publishing from a script

--yes accepts the routine confirmations. It does not accept scanner findings: if anything is flagged, the command fails and prints them. Fix the value in the proxy, or publish interactively and decide. Otherwise the first --yes in a GitHub Action turns the scanner into decoration.

Publishing is also in the dashboard, on a proxy's General → Advanced settings tab, together with the public/private switch and the list of what your team has published.

The most likely reason to pull a revision is that the scanner missed a real secret, and minutes matter, so it is self-service and immediate.

$ npx apiblaze withdraw @jayjaychicago/pokeapi@1

this permanently deletes revision 1. installs of it will fail.3 accounts installed it — rotate any secrets it contained.type the recipe name to confirm: _

The file is deleted, the cached public copy is purged, and @jayjaychicago/pokeapi@1 answers 410 withdrawn by publisher. You have to type the name; --yes does not skip it.

Withdrawing is the only way a published revision ever changes. There is no editing one: a published revision is frozen. Publish again and you get revision N+1, while everyone pinned to the old number carries on unaffected.

A recipe is written by a stranger and runs in your account. Four things make that a reasonable thing to do, and one thing it deliberately does not protect you from.

1. The publish list is an allowlist

There is one list, in one file, naming the fields a recipe is allowed to contain: some settings, the shape of the login client, the login provider's type and scopes, key types, transform rules, mapping tables, the API description. Anything not named does not travel.

Not a denylist, not a judgement call per column. Your email, your team id, your project id, your custom domain, your GitHub repository, your workspace claim code and every field added to apiblaze next year are all excluded — because being excluded is what happens when you are not named. A recursive secret scrubber (client_secret, private_jwk, claim_code, password, at any depth) runs behind it as a second pass.

2. Transform rules may not read credentials or claim an identity

A transform rule is the most powerful thing a recipe carries, because of when it runs. On every request apiblaze first attaches who is calling and, for a bring-your-own-OAuth proxy, swaps in the end user's real third-party access token. Publisher rules run after that. Left unrestricted, a rule could copy a live Google token into a query parameter and send it to the recipe's own upstream — for every user of every install, silently, forever.

The fence is about reading, not writing:

Publish refuses a rule outside that fence and names it. Install refuses it too, in case a recipe was assembled by hand against the API.

3. Identities never leave, structurally

A recipe has no tenant in it, so there is no container for users, memberships, API keys, email addresses or team identifiers to travel in. What travels is login configuration. That is a stronger guarantee than "we remember to strip the users", because there is nothing to remember.

4. A private recipe does not exist to anyone else

Fetching one while logged out returns 404, not 403. So does a withdrawn revision to a stranger, and so does a name nobody ever used. One indistinguishable answer, because a different answer is itself information: it tells you the name is taken and by whom.

And only the team that first published a name can publish revision N+1 to it, withdraw it, or change its visibility. Otherwise anyone could push a new head revision onto a popular name and every unpinned install would pick it up.