So I have been working my way through the major gateway and identity providers, rebuilding the little SoundCloud script that does the whole thing in one file — open a browser, do PKCE OAuth, register an app, print client_id and client_secret to stdout. That script is my yardstick for what programmatic API onboarding should feel like. This week it is Cloudflare’s turn, and Cloudflare is interesting because it sits right in the middle of the agentic story — it is the gateway in front of a huge slice of the web, and with API Shield it is the thing deciding whether an API consumer gets through at all.

Here is the honest mapping. Cloudflare has no Dynamic Client Registration. There is no POST /register, no RFC 7591, no OAuth dance you can script to mint a brand-new application identity from nothing. What Cloudflare does have is a clean management API for tokens, and an API token is the closest analog they offer to “register an app and get credentials.” You call POST /user/tokens (or POST /accounts/{account_id}/tokens), you hand it a name and a policies array of permission groups plus resources, and it hands you back a result.value — the token string, shown exactly once. Everything authenticates with a plain Authorization: Bearer header. As management APIs go, it is well-designed and pleasant to call.

The catch is the bootstrap. To create a token via the API, you have to already hold a token, and that very first token is dashboard-minted. You go to My Profile, API Tokens, Create Token, and you click. There is no public self-serve path that gets you from “I have a Cloudflare account” to “I have a credential” without a human in a browser. So this lands squarely in what I have started calling bucket (b): a real management API gated behind a personal access token you paste in by hand. It is not the SoundCloud ideal, but it is a long way from the cloud providers who give you nothing scriptable at all. I’ll take what I can get.

That shape changes what my script can honestly do. There is no browser flow to mirror, so I dropped the PKCE callback server entirely — it would be theater. Instead the CLI reads CLOUDFLARE_API_TOKEN and an optional CLOUDFLARE_ACCOUNT_ID from the environment, verifies the bootstrap token is live with GET /user/tokens/verify, looks up a permission group by name through GET /user/tokens/permission_groups, and then mints a fresh, narrowly-scoped child token. It handles the already-registered case the way the SoundCloud one does: if a token with the same name already exists, it tells you, because Cloudflare will never reprint an existing token’s secret. The script is committed in the repo at /assets/scripts/agentic-onboarding/cloudflare-api-auth.mjs, Node 18+, no npm install:

#!/usr/bin/env node
/**
 * cloudflare-api-auth.mjs
 *
 * Provider: Cloudflare (API / API Shield context)
 * What it does: Mints a SCOPED Cloudflare API Token via the management API — the
 *   closest thing Cloudflare has to "register an app and get credentials." It is the
 *   bucket-(b) shape: you paste a bootstrap API Token (dashboard-minted) via an env
 *   var, and this CLI creates a fresh, narrowly-scoped child token and prints its
 *   value ONCE. There is no RFC 7591 Dynamic Client Registration and no self-serve
 *   OAuth/PKCE app registration at Cloudflare, so there is no browser dance here.
 *
 * Auth model: Bearer API Token on every call (Authorization: Bearer <token>).
 *   The bootstrap token must itself hold "API Tokens Write" (User) permission so it
 *   can create other tokens.
 *
 * Env vars:
 *   CLOUDFLARE_API_TOKEN   (required) bootstrap token, dashboard-minted:
 *                          My Profile > API Tokens > Create Token. Needs the
 *                          "Create Additional Tokens" / API Tokens Write permission.
 *   CLOUDFLARE_ACCOUNT_ID  (optional) if set, an ACCOUNT-owned token is created at
 *                          POST /accounts/{id}/tokens; otherwise a USER token at
 *                          POST /user/tokens.
 *
 * Doc links:
 *   Create user token:  https://developers.cloudflare.com/api/resources/user/subresources/tokens/methods/create/
 *   Create acct token:  https://developers.cloudflare.com/api/resources/accounts/subresources/tokens/methods/create/
 *   Verify token:       https://developers.cloudflare.com/api/resources/user/subresources/tokens/methods/verify/
 *   Permission groups:  https://developers.cloudflare.com/api/resources/user/subresources/tokens/subresources/permission_groups/methods/list/
 *   API Shield mTLS:    https://developers.cloudflare.com/api/resources/client_certificates/methods/create/
 *
 * Node.js 18+ stdlib only (no npm dependencies).
 */
import { parseArgs } from "node:util";
import process from "node:process";

const API_BASE = "https://api.cloudflare.com/client/v4";

const HELP = `Usage: cloudflare-api-auth [options]

  Creates a scoped Cloudflare API Token using a bootstrap token you already hold,
  and prints the new token value (shown ONCE by Cloudflare). This is the closest
  Cloudflare analog to "register an app + get credentials" — bucket (b): a
  management API plus a personal access token. There is no Dynamic Client
  Registration and no browser OAuth here.

Env:
  CLOUDFLARE_API_TOKEN    Required. Bootstrap token (dashboard-minted) with the
                          "API Tokens Write" permission so it can mint tokens.
  CLOUDFLARE_ACCOUNT_ID   Optional. If set, creates an account-owned token at
                          POST /accounts/{id}/tokens instead of POST /user/tokens.

Options:
  --name           Required. Name for the new token (also used to detect duplicates).
  --permission     Permission group to grant, matched by name (default:
                   "DNS Read"). Use --list-permissions to browse available groups.
  --effect         "allow" or "deny" for the policy (default: allow).
  --expires-on     Optional. RFC3339 expiry, e.g. 2026-12-31T23:59:59Z
  --list-permissions   Print available permission groups and exit.
  -h, --help

Examples:
  CLOUDFLARE_API_TOKEN=cfut_xxx node cloudflare-api-auth.mjs --name "agent-dns-reader"
  CLOUDFLARE_API_TOKEN=cfut_xxx node cloudflare-api-auth.mjs --list-permissions
`;

function die(msg, code = 1) {
  console.error(msg);
  process.exit(code);
}

/** Cloudflare wraps everything in { success, errors, messages, result }. */
function unwrap(json, what, status) {
  if (json && json.success === true) return json.result;
  const errs = Array.isArray(json?.errors) && json.errors.length
    ? json.errors.map((e) => `${e.code ?? "?"}: ${e.message ?? e}`).join("; ")
    : `HTTP ${status}`;
  throw new Error(`${what} failed: ${errs}`);
}

async function cf(path, { method = "GET", token, body } = {}) {
  const headers = { authorization: `Bearer ${token}`, accept: "application/json" };
  if (body !== undefined) headers["content-type"] = "application/json";
  const res = await fetch(`${API_BASE}${path}`, {
    method,
    headers,
    ...(body !== undefined ? { body: JSON.stringify(body) } : {}),
  });
  let json;
  const text = await res.text();
  try {
    json = JSON.parse(text);
  } catch {
    throw new Error(`${method} ${path} returned non-JSON (HTTP ${res.status}): ${text.slice(0, 200)}`);
  }
  return { res, json };
}

/** Preflight: confirm the bootstrap token actually works before we try to mint. */
async function verifyToken(token) {
  const { res, json } = await cf("/user/tokens/verify", { token });
  const result = unwrap(json, "Token verify (GET /user/tokens/verify)", res.status);
  if (result?.status && result.status !== "active") {
    throw new Error(`Bootstrap token is "${result.status}", not active. Mint a fresh one in the dashboard.`);
  }
  return result;
}

async function listPermissionGroups(token) {
  // NOTE: verify — this list is large; we fetch the default page. The endpoint
  // supports ?name= / ?scope= filters if you want to narrow server-side.
  const { res, json } = await cf("/user/tokens/permission_groups", { token });
  return unwrap(json, "List permission groups (GET /user/tokens/permission_groups)", res.status);
}

function findPermissionGroup(groups, wanted) {
  const target = wanted.trim().toLowerCase();
  const exact = groups.find((g) => (g.name ?? "").toLowerCase() === target);
  if (exact) return exact;
  const partial = groups.filter((g) => (g.name ?? "").toLowerCase().includes(target));
  if (partial.length === 1) return partial[0];
  if (partial.length > 1) {
    throw new Error(
      `Permission "${wanted}" is ambiguous. Matches:\n  ` +
        partial.map((g) => g.name).join("\n  ") +
        `\nRe-run with an exact --permission name.`
    );
  }
  throw new Error(`No permission group matched "${wanted}". Run --list-permissions to see options.`);
}

/**
 * Best-effort duplicate detection for USER tokens. Cloudflare never returns a
 * token's secret value from a list call (only on create), so if a same-named
 * token already exists we surface its id and tell the user we cannot reprint it.
 * NOTE: verify — account-scoped token listing is not clearly documented; this
 * dup-check only runs for user tokens.
 */
async function findExistingUserToken(token, name) {
  const { res, json } = await cf("/user/tokens", { token });
  if (!json?.success) return null; // listing unavailable on this token; skip dup-check
  const list = Array.isArray(json.result) ? json.result : [];
  return list.find((t) => t?.name === name) ?? null;
}

function buildPolicy({ effect, permissionGroup, accountId }) {
  // Resources scope: account-level if we have an account id, else all accounts
  // the token's owner controls. This is intentionally broad-but-honest; tighten
  // `resources` per your needs (e.g. a single zone id) before relying on it.
  const resources = accountId
    ? { [`com.cloudflare.api.account.${accountId}`]: "*" }
    : { "com.cloudflare.api.account.*": "*" };
  return [
    {
      effect,
      permission_groups: [{ id: permissionGroup.id, name: permissionGroup.name }],
      resources,
    },
  ];
}

function formatTokenOutput({ result, accountId, permissionName }) {
  // Cloudflare's credential is a single bearer token string in result.value.
  // We mirror the SoundCloud script's `client_id=` / `client_secret=` ergonomics
  // by emitting the token under both an explicit label and a JSON blob.
  const pub = {
    id: result.id,
    name: result.name,
    value: result.value,
    status: result.status,
    expires_on: result.expires_on ?? null,
    scope: accountId ? `account:${accountId}` : "user",
    permission: permissionName,
  };
  const lines = [];
  // The token value IS the secret; there is no separate id/secret pair.
  lines.push(`api_token=${result.value ?? "(not returned)"}`);
  lines.push(`token_id=${result.id}`);
  lines.push("");
  lines.push("# Use it as:  Authorization: Bearer <api_token>");
  lines.push("# Cloudflare shows the value ONCE. Store it now.");
  lines.push("");
  lines.push(JSON.stringify(pub, null, 2));
  lines.push("");
  return lines.join("\n");
}

async function main() {
  let parsed;
  try {
    parsed = parseArgs({
      options: {
        name: { type: "string" },
        permission: { type: "string" },
        effect: { type: "string" },
        "expires-on": { type: "string" },
        "list-permissions": { type: "boolean" },
        help: { type: "boolean", short: "h" },
      },
      strict: true,
      allowPositionals: false,
    });
  } catch (e) {
    die(`${e.message}\n\n${HELP}`);
  }

  const { name, permission, effect, "expires-on": expiresOn, "list-permissions": listPerms, help } =
    parsed.values;

  if (help) {
    console.log(HELP);
    process.exit(0);
  }

  const token = process.env.CLOUDFLARE_API_TOKEN;
  if (!token) {
    die(
      "Missing CLOUDFLARE_API_TOKEN.\n" +
        "Mint a bootstrap token in the dashboard (My Profile > API Tokens > Create Token)\n" +
        'with the "API Tokens Write" permission, then export it:\n' +
        "  export CLOUDFLARE_API_TOKEN=cfut_...\n"
    );
  }
  const accountId = process.env.CLOUDFLARE_ACCOUNT_ID || "";

  // Preflight: prove the bootstrap token is live before doing anything destructive.
  await verifyToken(token);

  const groups = await listPermissionGroups(token);

  if (listPerms) {
    const sorted = [...groups].sort((a, b) =>
      (a.category ?? "").localeCompare(b.category ?? "") || (a.name ?? "").localeCompare(b.name ?? "")
    );
    for (const g of sorted) {
      console.log(`${(g.category ?? "-").padEnd(28)} ${g.name}`);
    }
    console.log(`\n${sorted.length} permission groups.`);
    process.exit(0);
  }

  if (!name) {
    die("Missing required --name.\n\n" + HELP);
  }

  const policyEffect = effect ?? "allow";
  if (policyEffect !== "allow" && policyEffect !== "deny") {
    die(`--effect must be "allow" or "deny", got "${policyEffect}".`);
  }

  // Handle the "already registered" case the way the SoundCloud script does:
  // if a token with this name exists, report it instead of creating a duplicate.
  if (!accountId) {
    const existing = await findExistingUserToken(token, name);
    if (existing) {
      console.error(
        `A token named "${name}" already exists (id=${existing.id}, status=${existing.status}).\n` +
          "Cloudflare will not reprint an existing token's secret. Either reuse it, roll it,\n" +
          "or pick a new --name."
      );
      process.stdout.write(
        JSON.stringify({ id: existing.id, name: existing.name, status: existing.status }, null, 2) + "\n"
      );
      process.exit(0);
    }
  }

  const permName = permission ?? "DNS Read";
  const permissionGroup = findPermissionGroup(groups, permName);

  const body = {
    name,
    policies: buildPolicy({ effect: policyEffect, permissionGroup, accountId }),
    ...(expiresOn ? { expires_on: expiresOn } : {}),
  };

  const path = accountId ? `/accounts/${accountId}/tokens` : "/user/tokens";
  const { res, json } = await cf(path, { method: "POST", token, body });
  const result = unwrap(json, `Create token (POST ${path})`, res.status);

  process.stdout.write(formatTokenOutput({ result, accountId, permissionName: permissionGroup.name }));
}

main().catch((e) => {
  die(`Error: ${e?.message || e}`);
});

There is a second credential story here worth naming, because Cloudflare wears two hats. The token above is the management credential — it is how you operate Cloudflare. But when Cloudflare is the gateway in front of your API and API Shield is enforcing mTLS, the credential an API consumer presents is a client certificate, minted with POST /zones/{zone_id}/client_certificates from a CSR. That is the consumer-side analog of getting credentials, and it is genuinely scriptable once you can sign a CSR. I like that it exists. It is also a reminder that “onboarding” means different things depending on which side of the gateway you are standing on.

So where does Cloudflare actually land? The management API is good. The token model is granular and scoped in a way I wish more providers copied. But the front door is still a human clicking through a dashboard, and that is the part that does not survive contact with an agent that is supposed to provision itself at three in the morning. If Cloudflare wants to fully meet the moment they keep telling me we are living in, the move is obvious: a real Dynamic Client Registration or device-grant flow that gets an agent from zero to a first, tightly-scoped token without a browser ever opening. Until then I’ll keep pasting my bootstrap token into an env var and letting the script do the rest, because that is still better than most of the field. It just is not the future anyone is selling me.

I am using my Products API teaching template as the running example, because it has the shape every real API has: a GET /products and GET /products/{id} for reading, a POST /products, PUT /products/{id}, and DELETE /products/{id} for writing, a cancel operation, and documented RateLimit headers. The source spec is the truth. Each plan is a lens over that truth. Here is the Free tier as an overlay.

overlay: 1.1.0
info:
  title: Products API - Free Tier Overlay
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.paths['/products'].post
    remove: true
  - target: $.paths['/products/{id}'].put
    remove: true
  - target: $.paths['/products/{id}'].delete
    remove: true
  - target: $.paths['/products/{id}/cancel']
    remove: true
  - target: $.components.headers.RateLimit
    update:
      description: >-
        Free tier is limited to 60 requests per hour. Need write access or
        higher limits? Upgrade to Pro or Enterprise.

Read that top down. The extends points at the canonical raw spec, so nothing is copied. The first four actions delete the write and premium operations outright, which means a Free customer’s rendered docs never mention POST /products and their generated SDK literally does not contain a createProduct method. You cannot fat-finger a call to an endpoint that is not in your client. The last action rewrites the documented RateLimit header description to the free quota and drops in the upgrade nudge, so the pricing story lives inside the docs instead of on a separate marketing page that nobody keeps current. Now the Enterprise tier.

overlay: 1.1.0
info:
  title: Products API - Enterprise Tier Overlay
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.info
    update:
      x-plan: enterprise
  - target: $.components.headers.RateLimit
    update:
      description: >-
        Enterprise tier is provisioned at 50,000 requests per hour with
        burst headroom. Dedicated quotas are negotiable per contract.
  - target: $.paths['/products/{id}/cancel']
    update:
      post:
        description: >-
          Enterprise-only bulk cancellation and audit logging are available.
          Contact your account team to enable contract-scoped behavior.

The Enterprise overlay removes nothing. It keeps every operation, stamps an x-plan: enterprise extension on info so downstream tooling can branch on the tier, bumps the documented RateLimit description to the negotiated ceiling, and enriches the cancel operation with the enterprise-only notes that would be noise in a Free customer’s docs. Same source, opposite treatment. One overlay subtracts to make a smaller honest surface, the other annotates to make a richer one.

Here is the part I need you to internalize, because it is where people get themselves in trouble. This shapes docs and SDKs. It does not enforce anything. Removing POST /products from the Free overlay does not stop a Free customer from firing a POST at your gateway. Real enforcement happens at the gateway, in your API management layer, where the token, the plan, and the quota actually live. The overlay’s job is to keep the documentation honest per tier so a Free customer is not staring at an endpoint they will get a 403 from, and an Enterprise customer sees the limits they actually paid for. The Overlay specification gives you the mechanism; your gateway is still the bouncer.

My strong take: if your plan tiers are hand-maintained documents, you do not have plans, you have three lies decaying at different rates. Make the plan a projection. One spec, one overlay per tier, generated on every build. The gateway guards the door, the overlay keeps the map honest, and nobody edits the same endpoint description three times ever again.

That is why I keep dragging providers back to the SoundCloud example. A single zero-dependency script that opens a browser, logs you in, registers an application, and hands you a client_id and client_secret on stdout. That is what programmatic API onboarding should feel like. No portal spelunking, no copy-paste, no waiting. I want to point this lens at the identity and access vendors next, because if anyone should make credential issuance a first-class API, it is the companies whose entire business is credentials. So this week it is Kinde’s turn.

Here is the honest read. Kinde is a bucket-B provider: it has a real, well-documented Management API, and it absolutely can create applications and mint credentials over HTTP. What it does not have is the self-serve OAuth front door from the SoundCloud ideal. There is no RFC 7591 dynamic client registration, no “log in with your Kinde account and register a new client” flow that a brand-new developer or a cold agent can walk up to. Before anything programmatic happens, a human has to go into the Kinde dashboard, create a machine-to-machine application by hand, and authorize it for the Management API. So the chicken-and-egg problem is alive and well: you need a credential to make a credential.

Once you are past that one manual step, though, Kinde is genuinely good, and I will take what I can get. You take that M2M app’s client_id and client_secret, POST them to https://{your_subdomain}.kinde.com/oauth2/token with grant_type=client_credentials, and the one detail that will trip you up every single time is the audience. It is https://{your_subdomain}.kinde.com/api — not /api/v1. I lost more minutes than I want to admit to that. That call hands back a management access token, and from there you are in business: POST /api/v1/applications with a JSON body of { "name": "...", "type": "m2m" } and a Bearer token, and Kinde creates the client and returns the id, client_id, and client_secret right there in the create response. No second round trip to fetch the secret, which is more than I can say for a lot of platforms. The type can be reg, spa, m2m, or device, which covers the realistic shapes an agent might need to stand up.

The already-registered case is where you have to do a little more work, and it is worth knowing why. Kinde does not seem to reject duplicate application names, so there is no tidy “you already have one” error to catch. And the list endpoint, GET /api/v1/applications, only returns id, name, and type for each app — no secret. So to recover credentials for an existing application you list, match by name, then GET /api/v1/applications/{id}, which does return the secret. I wired all of that into the script so the --reuse flag does the right thing instead of quietly spawning a pile of duplicate clients.

That script is below, and it is committed in the repo at /assets/scripts/agentic-onboarding/kinde-api-auth.mjs. Same spirit as the SoundCloud original: one file, Node 18+ stdlib only, no npm install. The one difference forced by Kinde’s model is that there is no browser to open — you feed it KINDE_DOMAIN, KINDE_M2M_CLIENT_ID, and KINDE_M2M_CLIENT_SECRET and it mints the management token for you, or you hand it a KINDE_TOKEN you already have. It prints client_id= / client_secret= to stdout exactly like the others.

#!/usr/bin/env node
/**
 * kinde-api-auth.mjs
 *
 * Provider: Kinde (https://kinde.com) — auth, access management, and billing platform.
 *
 * What it does:
 *   Creates a new Kinde application (client) via the Kinde Management API and prints its
 *   client_id / client_secret. If an application with the same --name already exists, it
 *   looks it up and returns the existing credentials instead.
 *
 * Auth model (Hypothesis bucket B — Management API + M2M token):
 *   Kinde does NOT offer RFC 7591 Dynamic Client Registration, so there is no browser
 *   OAuth dance here. Instead you create ONE machine-to-machine (M2M) application in the
 *   Kinde dashboard, authorize it for the Kinde Management API with the scopes below, and
 *   feed its credentials to this script via env vars. The script then:
 *     1. POST {KINDE_DOMAIN}/oauth2/token  (grant_type=client_credentials,
 *        audience={KINDE_DOMAIN}/api)  -> management access token
 *        NOTE: the audience is ".../api", NOT ".../api/v1".
 *     2. POST {KINDE_DOMAIN}/api/v1/applications  (Authorization: Bearer <token>)
 *        body { name, type } -> { application: { id, client_id, client_secret } }
 *   Required M2M scopes: create:applications, read:applications.
 *
 * Env vars (choose ONE auth path):
 *   Path A — mint a token from M2M credentials:
 *     KINDE_DOMAIN              e.g. https://your-subdomain.kinde.com  (or just your-subdomain)
 *     KINDE_M2M_CLIENT_ID       client_id of your M2M app
 *     KINDE_M2M_CLIENT_SECRET   client_secret of your M2M app
 *   Path B — paste a pre-obtained management token:
 *     KINDE_DOMAIN              (still required, to build the /api/v1 base URL)
 *     KINDE_TOKEN               a valid management API bearer token
 *
 * Node.js 18+ stdlib only (global fetch). No npm dependencies.
 *
 * Docs:
 *   https://docs.kinde.com/developer-tools/kinde-api/access-token-for-api/
 *   https://docs.kinde.com/developer-tools/kinde-api/connect-to-kinde-api/
 *   https://docs.kinde.com/kinde-apis/management/  (Applications endpoints)
 *   https://docs.kinde.com/build/applications/about-applications/  (type values)
 */
import { parseArgs } from "node:util";
import process from "node:process";

const APP_TYPES = new Set(["reg", "spa", "m2m", "device"]);
const DEFAULT_TYPE = "m2m";

/** Normalize a subdomain or full URL into a clean origin like https://acme.kinde.com */
function normalizeDomain(raw) {
  if (!raw) return null;
  let v = raw.trim().replace(/\/+$/, "");
  if (!/^https?:\/\//i.test(v)) {
    // Allow passing just the subdomain ("acme") or "acme.kinde.com".
    v = v.includes(".") ? `https://${v}` : `https://${v}.kinde.com`;
  }
  try {
    return new URL(v).origin;
  } catch {
    return null;
  }
}

function bail(msg, code = 1) {
  console.error(msg);
  process.exit(code);
}

/** Step 1: client_credentials -> management access token. */
async function mintManagementToken({ domain, clientId, clientSecret }) {
  const tokenUrl = `${domain}/oauth2/token`;
  const body = new URLSearchParams({
    grant_type: "client_credentials",
    client_id: clientId,
    client_secret: clientSecret,
    // The management API audience is "/api" (NOT "/api/v1").
    audience: `${domain}/api`,
  });
  const res = await fetch(tokenUrl, {
    method: "POST",
    headers: {
      accept: "application/json",
      "content-type": "application/x-www-form-urlencoded",
    },
    body: body.toString(),
  });
  const text = await res.text();
  if (!res.ok) {
    throw new Error(
      `Token request (POST ${tokenUrl}) failed: ${res.status} ${text}\n` +
        "Check KINDE_M2M_CLIENT_ID / KINDE_M2M_CLIENT_SECRET, and that the M2M app is\n" +
        "authorized for the Kinde Management API with create:applications + read:applications."
    );
  }
  let json;
  try {
    json = JSON.parse(text);
  } catch {
    throw new Error(`Token endpoint returned non-JSON: ${text}`);
  }
  if (!json.access_token) {
    throw new Error(`No access_token in token response: ${text}`);
  }
  return json.access_token;
}

/** Thin wrapper for Management API calls (Authorization: Bearer <token>). */
async function kindeApi({ apiBase, token, path, method = "GET", body }) {
  const url = `${apiBase}${path}`;
  const headers = {
    accept: "application/json",
    authorization: `Bearer ${token}`,
  };
  if (body !== undefined) headers["content-type"] = "application/json";
  const res = await fetch(url, {
    method,
    headers,
    ...(body !== undefined ? { body: JSON.stringify(body) } : {}),
  });
  return { res, url, text: await res.text() };
}

/** Step 2a: create a new application. Returns { id, client_id, client_secret }. */
async function createApplication({ apiBase, token, name, type }) {
  const { res, url, text } = await kindeApi({
    apiBase,
    token,
    path: "/api/v1/applications",
    method: "POST",
    body: { name, type },
  });
  if (!res.ok) {
    throw new Error(`Create application (POST ${url}) failed: ${res.status} ${text}`);
  }
  let json;
  try {
    json = JSON.parse(text);
  } catch {
    throw new Error(`Create application returned non-JSON: ${text}`);
  }
  const app = json.application;
  if (!app?.client_id) {
    throw new Error(`Create application response missing application.client_id: ${text}`);
  }
  return app; // { id, client_id, client_secret }
}

/**
 * Find an existing application by exact name (paginated).
 * NOTE: list items only contain { id, name, type } — no secret — so the caller must
 * follow up with getApplication() to recover client_secret.
 */
async function findApplicationByName({ apiBase, token, name }) {
  let nextToken;
  do {
    const qs = new URLSearchParams({ page_size: "100", sort: "name_asc" });
    if (nextToken) qs.set("next_token", nextToken);
    const { res, url, text } = await kindeApi({
      apiBase,
      token,
      path: `/api/v1/applications?${qs.toString()}`,
    });
    if (!res.ok) {
      throw new Error(`List applications (GET ${url}) failed: ${res.status} ${text}`);
    }
    const json = JSON.parse(text);
    const match = (json.applications ?? []).find((a) => a?.name === name);
    if (match?.id) return match.id;
    nextToken = json.next_token || undefined;
  } while (nextToken);
  return null;
}

/** Step 2b: fetch full application (incl. client_secret) by id. */
async function getApplication({ apiBase, token, id }) {
  const { res, url, text } = await kindeApi({
    apiBase,
    token,
    path: `/api/v1/applications/${encodeURIComponent(id)}`,
  });
  if (!res.ok) {
    throw new Error(`Get application (GET ${url}) failed: ${res.status} ${text}`);
  }
  const app = JSON.parse(text).application;
  if (!app?.client_id) {
    throw new Error(`Get application response missing application.client_id: ${text}`);
  }
  return app;
}

function formatCredentialOutput(app, { name, type }) {
  const out = {
    id: app.id,
    name: app.name ?? name,
    type: app.type ?? type,
    client_id: app.client_id,
    client_secret: app.client_secret,
  };
  for (const k of Object.keys(out)) {
    if (out[k] === undefined || out[k] === null) delete out[k];
  }
  const lines = [`client_id=${out.client_id}`];
  if (out.client_secret) lines.push(`client_secret=${out.client_secret}`);
  lines.push("", JSON.stringify(out, null, 2), "");
  return lines.join("\n");
}

const {
  values: { name: nameArg, type: typeArg, reuse: reuseArg, help: helpArg },
  positionals,
} = parseArgs({
  options: {
    name: { type: "string" },
    type: { type: "string" },
    reuse: { type: "boolean" },
    help: { type: "boolean", short: "h" },
  },
  strict: true,
  allowPositionals: true,
});

if (helpArg) {
  console.log(`Usage: kinde-api-auth [options]

  Creates a Kinde application via the Management API and prints client_id /
  client_secret. With --reuse, an existing application of the same --name is
  returned instead of creating a duplicate.

Options:
  --name         Required. The application's name.
  --type         Application type: reg | spa | m2m | device  (default: ${DEFAULT_TYPE})
  --reuse        If an app with this --name already exists, return it instead of creating.
  -h, --help

Environment (Path A — mint a token from M2M credentials):
  KINDE_DOMAIN              https://your-subdomain.kinde.com  (or just "your-subdomain")
  KINDE_M2M_CLIENT_ID       client_id of a Management-API-authorized M2M app
  KINDE_M2M_CLIENT_SECRET   its client_secret

Environment (Path B — paste a pre-obtained management token):
  KINDE_DOMAIN              (still required)
  KINDE_TOKEN               a valid Kinde Management API bearer token

  The M2M app must be authorized for the Kinde Management API with at least
  create:applications and read:applications.

  With npm, pass a double dash before flags:  npm start -- --name "My App"
`);
  process.exit(0);
}

if (positionals.length > 0) {
  bail(
    `Unexpected extra argument(s): ${positionals.map((p) => JSON.stringify(p)).join(" ")}\n` +
      'If you used npm, put a double dash before the options, e.g.:\n' +
      '  npm start -- --name "My App" --type m2m'
  );
}

const name = nameArg;
const type = typeArg ?? DEFAULT_TYPE;
if (!name) bail('Missing required argument: --name\nExample: node kinde-api-auth.mjs --name "My Agent App" --type m2m');
if (!APP_TYPES.has(type)) {
  bail(`Invalid --type "${type}". Must be one of: ${[...APP_TYPES].join(", ")}`);
}

const domain = normalizeDomain(process.env.KINDE_DOMAIN);
if (!domain) {
  bail(
    "Missing or invalid KINDE_DOMAIN. Set it to your Kinde domain, e.g.\n" +
      "  export KINDE_DOMAIN=https://your-subdomain.kinde.com"
  );
}
const apiBase = domain; // Management endpoints live under {domain}/api/v1

async function resolveToken() {
  if (process.env.KINDE_TOKEN) return process.env.KINDE_TOKEN.trim();
  const clientId = process.env.KINDE_M2M_CLIENT_ID;
  const clientSecret = process.env.KINDE_M2M_CLIENT_SECRET;
  if (!clientId || !clientSecret) {
    bail(
      "No credentials found. Provide EITHER:\n" +
        "  - KINDE_M2M_CLIENT_ID and KINDE_M2M_CLIENT_SECRET  (script mints the token), or\n" +
        "  - KINDE_TOKEN                                       (a management bearer token)"
    );
  }
  return mintManagementToken({ domain, clientId, clientSecret });
}

try {
  const token = await resolveToken();

  if (reuseArg) {
    const existingId = await findApplicationByName({ apiBase, token, name });
    if (existingId) {
      const app = await getApplication({ apiBase, token, id: existingId });
      console.error(`Application named "${name}" already exists; returning existing credentials.`);
      process.stdout.write(formatCredentialOutput(app, { name, type }));
      process.exit(0);
    }
  }

  // NOTE: Kinde does not appear to reject duplicate application names at create time, so
  // "already registered" handling here is an explicit --reuse name lookup rather than a
  // reaction to a specific API error code. Verify against your tenant's behavior.
  const created = await createApplication({ apiBase, token, name, type });
  process.stdout.write(formatCredentialOutput(created, { name, type }));
  process.exit(0);
} catch (e) {
  console.error("Error:", e?.message || e);
  process.exit(1);
}

So where does that leave Kinde against the moment? The plumbing is all there. The Management API is clean, the responses hand back the secret without a runaround, and the data model maps cleanly onto what an agent needs to provision. The gap is the front door. As long as bootstrapping requires a human to hand-create the first M2M app in a dashboard, no agent can onboard to Kinde cold, and that is the exact contradiction I started with. If Kinde wants to fully meet the agentic moment, it should offer a constrained, self-serve registration path — a way for a brand-new caller to obtain a tightly scoped, rate-limited management credential without a human clicking through a console first. Give me that, and the script above stops being a workaround for a manual step and becomes the whole story.

While meeting with my intern to talk through her research, I mentioned that I did not find the topic of students cheating with AI particularly interesting. It is overdone. When I repeated that to my wife, she told me she finds the topic very interesting, precisely because the focus is always on the students, and that focus is what obfuscates the cheating being done by the artificial intelligence companies themselves. The models are trained on copyrighted material, on scraped work nobody consented to hand over, on reverse-engineered products, and on web-scale datasets that researchers have found to contain child sexual abuse material. Every one of those is somebody else’s rule being broken at a scale no undergraduate could dream of, and none of it produces a disciplinary hearing.

On top of that, these companies work constantly to blow smoke up everyone’s ass — fabricating stories, staging demos, and cheating on the benchmarks and tests being championed as the authoritative lines in the sand between what is real and what is not. There is an enormous amount of money on the line, and cheating is how you get ahead, and how you stay ahead, until you can sell your shares on the secondary market. The incentive structure does not merely tolerate cheating. It pays for it, and it pays best of all for the kind of cheating that is hard to audit from the outside.

As my wife reminds me, lying and cheating are the original baseline for artificial intelligence, and they are baked right into the Turing test. The imitation game does not measure whether a machine is intelligent. It measures whether a machine can convince a human being that it is something it is not. That is the founding benchmark of this entire field, and we are surprised when the industry built on top of it games its benchmarks. This is how “artificial intelligence” convinces us it is real — by lying to us, and by cheating on the very tests we use to determine who is human and who is not.

This is one of the reasons my wife’s view of the world is so valuable to me. She does not see things the way I do. She never takes anything at face value. She reads a story and immediately starts asking what is behind it, and who benefits from it being told this way. I can do that some of the time, but it is not my default mode of operating, and I still fall for things more often than I would like. The students-cheating narrative being so loud is a good reminder that the headline story is rarely the real story. It is the one someone is paying to have published.

We should all be talking about how Anthropic, OpenAI, Meta, Google, and the rest are cheating. Instead, for reasons that are not hard to trace back to who owns the megaphone, society has chosen to put the blame on young people trying to make their way into this messed-up world we adults are building for them. I have been clear about where I stand on all of this, and this is a fresh reminder of why. The kids did not set the rules of the game they are being accused of gaming. The companies did, and they are cheating at their own game while pointing at an eighteen-year-old with an essay.

Think about what it actually takes to stand up a GraphQL API. You have to sit down and define a schema — one schema, a single typed graph that describes every type, every field, every relationship, and the exact shape of everything a consumer can ask for. You cannot ship the first query until that schema exists and is internally consistent. The type system will not let you have a User that means one thing over here and something incompatible over there. When you want to remove a field, you have to reach for the @deprecated directive and say so, in the schema, where everyone can see it. The whole thing is introspectable by default, which means the machine-readable contract that REST governance programs spend two years and a consulting budget trying to produce is just… sitting there, generated, the moment you turn the server on. You did governance. You may not have called it that. You had no choice.

Now think about what it takes to stand up a REST API. Almost nothing. You can add an endpoint this afternoon. You can add another one tomorrow that returns a slightly different shape of the same resource because a different team wrote it and nobody was looking. You can have firstName in one response and first_name in the next and fname in a third, and the framework will cheerfully serve all three. REST does not require a unified schema to function. It does not require you to declare your types up front. It does not force you to name your deprecations. Every one of those disciplines is possible in REST — I have spent years arguing that OpenAPI is the unit of governance precisely because it lets you impose that discipline — but the operative word is impose. In REST, the schema is optional, external, and always slightly out of date relative to the running code. Governance is a thing you do to REST, from the outside, against its natural grain, forever.

That difference in grain is everything. When the discipline is the price of admission, you pay it once, at the start, when the system is small and malleable and there are three types instead of three hundred. When the discipline is optional, you pay it later, in a governance program, in arrears, with interest, after the sprawl has already happened and every team has already shipped their own idea of what a customer record looks like. I have written that API governance is seventy-five percent people work, and I still believe that — but a meaningful slice of that people work is the work of getting everyone to agree on a schema that GraphQL would have forced them to agree on before a single line shipped. GraphQL front-loads the argument. REST lets you defer the argument indefinitely, which feels like speed right up until the day you try to inventory what you actually have.

I want to be careful here, because I am not making the tired claim that GraphQL is better than REST. It is not. There are whole categories of API — anything cache-heavy, anything hypermedia-shaped, anything where the resource model is the product — where REST is the right answer and GraphQL would be a self-inflicted wound. And GraphQL brings its own governance problems that REST never had, from query cost and depth limits to the operational headache of a single evolving graph. This is not a ranking. It is an observation about where the discipline lives. In GraphQL, the discipline lives in the tool, up front, unavoidable. In REST, the discipline lives in you, ongoing, optional, and easy to skip when the sprint is tight.

Which is exactly why REST governance is a discipline you have to actively choose, and GraphQL governance is a discipline you back into. The GraphQL team gets a single typed schema, explicit deprecations, and an introspectable contract as a side effect of the technology working at all. The REST team gets those same things only if someone stands up, insists on OpenAPI as the source of truth, wires up the linting, and defends the schema against every team that would rather just ship an endpoint. Most REST teams do not have that someone. That is not a technology failure. It is the natural consequence of a technology that does not require the schema in order to run.

So when people ask me whether they should adopt GraphQL, my honest answer has quietly shifted. I do not tell them GraphQL will make their API better — it might not. I tell them that if they are the kind of organization that struggles to get a handle on its own schema, GraphQL will hand them a handle whether they want one or not, and that alone might be worth more than any query-flexibility argument on the marketing page. Getting a handle on your schema is governance. GraphQL just does not let you pretend otherwise. This connects directly to what I have been saying about MCP as last-mile plumbing — the foundational work is the schema, the contract, the thing underneath. GraphQL makes you do that work first. REST politely lets you put it off until it hurts.

Then Series D shows up, and the doors start to close. It is not personal and it is not a betrayal of principles, because the openness was never a principle–it was a growth tactic with an expiration date. Early on, the business needs your integrations more than it needs to monetize your access, so it gives access away. Later, once the platform has captured enough gravity that leaving is painful, the math flips: now the data flowing through your integrations is worth more locked up than given away, and the investors who put in that late-stage money expect to see it captured. The free tier shrinks. The useful endpoints move behind enterprise sales. The export that used to be one click sprouts an “contact us” form. The API is still there. It is just no longer for you.

I said this to Nordic APIs and I will say it here: this is not a bug in the venture playbook, it is the playbook. Capture as much value as you can, give away as little as possible, and treat the early openness as a customer-acquisition cost you stop paying the moment you can get away with it. SaaS makes the trap tighter, because once your data lives inside their walls and their formats, the closing of the API is not an inconvenience you route around–it is a wall you are already standing inside of. You did not lose access to a tool. You lost access to your own operational history, which now lives somewhere you can only read on their terms.

And this pattern does not stay confined to scrappy startups–it scales all the way up, and gets worse as it climbs. The enterprise version of the walled garden used to belong to Oracle, and we all understood the shape of that particular cage. But the gardens got bigger. Now it is Microsoft, Amazon, and Google, and the walls are taller and the grounds are vastly larger than anything Oracle ever fenced. A Google shop buys Google’s answer to every problem. A Microsoft shop standardizes on the Microsoft version of everything and lives inside Office 365. The quirky, best-in-class third-party API with the weird auth and the brilliant feature loses–not because it is worse, but because it is outside the garden, and the garden’s whole value proposition is that you never have to leave.

That is the part that should bother anyone who cares about a healthy ecosystem. The consolidation is not selecting for the best tools. It is selecting for the tools that are already inside the wall. Enterprises are trading away access to genuine innovation for the comfort of a single vendor relationship and one throat to choke, and they are calling it a strategy. The mediocre-but-integrated option beats the excellent-but-external one, over and over, until the external option gives up or gets acquired and absorbed into a garden of its own. The incentives all point toward enclosure, and very little points back the other way.

I do not have a tidy fix for this, because the forces driving it are economic, not technical, and you do not out-engineer a business model. But I do think the first move is to stop being surprised by it. If you are building on someone else’s open API today, price in the closing. Assume the free tier is a promotion, assume the export will get harder, assume the Series D or the acquisition is coming, and own your own data flows accordingly. And if you are a founder, understand that every wall you build to please a late-stage investor is also a wall around your own ceiling–the same enclosure that captures short-term value is the thing that caps how large the platform could have ever become. The gardens are winning right now. That does not make the enclosure a good idea. It makes it the thing worth designing against.

Here is the discipline in one sentence: every consequential choice in this architecture exists as an architecture decision record — twenty-three of them — and each one states the problem, the decision drivers, the options considered, the good and bad of each option, and then the chosen option with the reasoning. Not “we use DPoP.” Instead: here is the problem sender-constraining solves, here are the three approaches, here is what is good and bad about no constraint, about mTLS binding, and about DPoP, and here is why DPoP won for us and what it costs us. The rejected options are documented as carefully as the winner. I cannot overstate how unusual and how valuable that is. When you inherit this system in five years, or when a new state joins the federation and asks “why didn’t you just use mutual TLS everywhere,” the answer is not locked in someone’s memory or lost with a departed contractor — it is written down, with the trade-off attached. They even chose the ADR format in an ADR, and cited the old Parnas essay about faking a rational design process, which tells you they take the practice seriously as a practice.

The second governance move is the one I have been beating a drum about for my whole career, so watching a government do it properly was a small thrill: the security requirements are derived from explicit attacker models, not asserted. Most security documents are a list of controls handed down as if from a mountain. Germany’s two protection tiers each come with a companion attacker-model document — one built on the OAuth security best-current-practice for the normal tier, one built on the FAPI attacker model for the high tier — that defines the adversary and the security goals first, and then derives the required mechanisms from them. For the high-assurance profile they went all the way to formal analysis, proving the profile satisfies the attacker model rather than claiming it does. When a control has a threat model behind it, a reviewer can evaluate whether the control actually addresses the threat, and an implementer understands why the requirement exists instead of treating it as ceremony. That is the difference between security theater and security engineering, and it is all in the open repository.

Third, they did it in public, and they consulted. The entire thing — principles, requirements, ADRs, target architecture, glossary — lives on Open CoDE, Germany’s public code platform, under an open license. They ran a formal public consultation, took feedback as tracked issues, closed it, and worked the responses in. This matters for a reason that goes beyond transparency as a virtue: a standard that independent agencies are eventually expected to follow has to earn legitimacy, and you earn legitimacy by letting the people who will be bound by the decision see the reasoning and push back on it before it hardens. Publishing the reasoning is not a nicety; it is how you get buy-in across organizations that do not report to you.

And fourth — this is the subtle one that I think US agencies especially need to hear — they separated approving the specifications from making them mandatory, and treated the second as its own hard problem. When the IT Planning Council approved the work in June, it did not wave a wand and declare everything binding. It commissioned a project group, including the relevant federal security agencies, to work out how to make the requirements binding — implementation timelines, exemptions, transition periods, and support measures like guidelines and training — with a proposal due at a later session, alongside a pilot of the core components. That is a realistic two-step: get the specification right and consulted, then do the genuinely difficult organizational work of adoption, with runway and support, instead of mandating by memo and hoping. Anyone who has watched a mandate-by-memo bounce off an agency that had no budget, no timeline, and no help knows exactly why this sequencing matters.

I have spent the last year arguing that governance needs to be a first-class, kept, versioned artifact rather than a moment that happens and evaporates — that reviews should have provenance, that rules should be executable, that the record should be something you can diff over time. Germany’s project is the most complete real-world example of that philosophy applied to a national standard that I have seen. The ADRs are the memory. The attacker models are the provenance for every control. The public repository is the diffable record. It is, in a sense, the same thing I have been doing when I commit governance receipts next to my own APIs, just scaled to a federation and executed with real institutional weight behind it.

So if you are a US or European agency and you take only one thing from this entire series, I would not want it to be DPoP or FAPI or the transparency log, as good as those choices are. I would want it to be the method: write the decisions down with the options you rejected, derive your requirements from a named adversary, do it in the open where the people who will follow it can see and challenge it, and treat “make it binding” as a funded, phased program rather than an announcement. Get the method right and the technology choices become improvable over time. Get the method wrong and even the best technology choices rot in a PDF nobody can question. Next in the series I finally turn the lens onto us: a concrete playbook for how US agencies could emulate this, swapping German building blocks for login.gov, SAM.gov, and the tools we already have.

The fix is to stop treating environments as different specs and start treating them as different projections of the same spec. You keep one canonical, environment-agnostic OpenAPI definition, and you keep a thin Overlay per stage that carries only the per-environment truth. My running example through this series is the Products API teaching template, and its base spec deliberately doesn’t commit to a hostname. The servers block is a placeholder, the OAuth flow points at a generic identity host, and there’s nothing in it that ties it to a deployment. That’s on purpose. The base spec describes what the API is — GET/POST /products, GET/PUT/DELETE /products/{id}, the cancel operation, the Product schema, the NotFound and TooManyRequests responses. Where it runs is not the spec’s job. That’s the overlay’s job.

Here’s the dev and staging overlay. It rewrites the servers to the staging host, repoints the OAuth token and authorization URLs at the staging identity provider, and stamps a loud warning into the description so nobody mistakes it for the real thing.

overlay: 1.1.0
info:
  title: Products API - Staging Environment Overlay
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.servers
    update:
      - url: https://staging.api.example.com/v1
        description: Staging environment - non-production
  - target: $.components.securitySchemes.OAuth2.flows.authorizationCode
    update:
      authorizationUrl: https://identity.staging.example.com/oauth/authorize
      tokenUrl: https://identity.staging.example.com/oauth/token
  - target: $.info
    update:
      description: >-
        STAGING ENVIRONMENT - This is a non-production deployment. Data resets
        nightly at 00:00 UTC and should be treated as disposable. Do not store
        anything here you expect to keep. Rate limits are relaxed for testing.

The extends field is doing the heavy lifting — it points at the canonical raw URL, so this overlay is meaningless on its own and can only ever describe the one true Products API. The three actions are surgical. They target the servers array, the OAuth flow inside components.securitySchemes, and the info object, and they touch nothing else. Every operation, every schema, every problem+json example comes straight from the base spec, unchanged.

The production overlay is the same shape with the real values, plus it hardens the description around rate limits instead of relaxing them.

overlay: 1.1.0
info:
  title: Products API - Production Environment Overlay
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.servers
    update:
      - url: https://api.example.com/v1
        description: Production environment
  - target: $.components.securitySchemes.OAuth2.flows.authorizationCode
    update:
      authorizationUrl: https://identity.example.com/oauth/authorize
      tokenUrl: https://identity.example.com/oauth/token
  - target: $.info
    update:
      description: >-
        PRODUCTION - Live customer data. Rate limits are strictly enforced at
        1000 requests per minute per token; exceeding them returns 429 with a
        problem+json body and RateLimit headers indicating your reset window.
        Cancel operations are irreversible in this environment.

Now put it in the pipeline, which is where the whole idea earns its keep. You promote a single build artifact — the canonical spec — from dev to staging to production, and at each stage your CI job applies the matching overlay to generate the environment-specific description that ships to that stage’s portal, mock server, or gateway. Same artifact, different overlay, swapped by stage name. There is exactly one place to add a new operation, and when you do, all three environments inherit it the next time they’re built. Drift becomes impossible because there’s nothing to drift from.

That’s the take I want to leave you with. Environment configuration is not three contracts you keep in sync by discipline and prayer. It is one contract with three projections, and the overlay is how you make that projection explicit, versioned, and reproducible. Stop copying the spec. Project it.

So I started profiling them. Not their cap tables — their APIs. I have been running the secondary-market listings through the same pipeline I run everything else through: find the company, find its developer surface if it has one, harvest whatever contracts and artifacts are actually published, and then rate the result with the Kin Score. The question I am chasing is simple and a little rude. These companies are valued like technology companies. Are they operable like technology companies?

I now have 278 of them scored, and the answer is more interesting than either “yes” or “no.” Everything below is drawn from the secondary market section of the providers site, which is where these profiles live as I work through them.

What the numbers say

The average composite Kin Score across the cohort is 27.5, with a median of 24.7. For context, that is the bottom half of the scale. Broken into bands:

• exemplar or strong: 25 companies (9%)
• developing: 35 companies (13%)
• emerging, thin, or minimal: 218 companies (78%)

Agent readiness — measured separately, because being usable by a human developer and being usable by an agent are not the same problem — comes out lower still. Mean 19.8, median 12.6. Nearly half the cohort, 129 companies, score as human-only: no machine-readable contract, no agent-facing affordances, nothing an autonomous consumer could act against without a person in the loop. Eleven companies out of 278 rate agent-native.

The facet breakdown is where it gets genuinely useful, because it explains the shape of the failure rather than just its size. Averaged across the cohort:

Read that top-to-bottom and you have the whole story. These companies are extremely easy to find and almost impossible to operate against. They have websites, positioning, press, a careers page, a blog. Discoverability at 76.8 says the marketing works. Governance at 8.8 and operational transparency at 15.5 say that once you get past the marketing there is very little contract, very little published operational reality, and almost no evidence of anyone governing the surface. The gap between 76.8 and 8.8 is the gap between being known and being usable.

Who is actually good

The top of the table is not who I expected, and that is the most useful finding in the whole exercise:

Satellite Bluetooth. Digital employee experience monitoring. Global payroll. Bank data connectivity. Government budgeting software. Crypto accounting data. These are infrastructure companies. They are, with a couple of exceptions, not the names that come up when people talk about hot private companies. The consumer brands with the recognizable logos are mostly not in this table — they are down in the 78%.

That inversion is the point. Private-market conviction and API maturity are not the same signal, and in this cohort they are barely correlated. The market is pricing brand, growth, and category. The Kin Score is measuring whether anyone can build on you. Those turn out to be close to independent variables.

Where I have to be careful

I want to be honest about what this evidence does and does not support, because it would be easy to turn this into a cheap dunk and the cheap version would be wrong.

A low score is not automatically a failure. A large share of this cohort is clinical-stage biotech, medical devices, consumer packaged goods, and deep-tech hardware. A company developing an mRNA therapeutic has no obligation to ship an OpenAPI, and scoring it against one tells you about its category, not its competence. The Kin Score answers “can a developer or an agent do anything with this company’s public surface,” and for a lot of these firms the honest answer is “no, and that is fine.” What the number is genuinely good for is separating the companies that present as technology companies from the ones that behave like them.

The sample is small and biased. 278 companies is 1.6% of the 17,311 in my backlog. I am working through the highest-conviction slice first — companies listed on three or more venues — and within that, alphabetically. That is a real bias and I am not going to pretend the average holds for the other 98%. Ask me again at a few thousand.

I am scoring the public surface only. Plenty of these companies have real, well-built APIs sitting behind a sales conversation, a partner agreement, or a login. That work is invisible to me and it does not count here. This is a measure of what a company publishes to the open web, not of what its engineers have built. A company with a great private API and no public evidence of it scores badly, and by the rubric’s own terms that is a correct result — but it is a narrower claim than “this company has no API.”

Why I keep doing it anyway

Because the interesting number is not the average, it is the distribution. A market where 9% of highly-valued private companies are meaningfully operable and 46% are entirely human-only is telling you something specific about where the next few years of integration work is going to come from — and about how much of the “everything is an API company now” story is positioning rather than architecture.

It also tells you something about agents specifically. Every one of these companies is going to be asked, fairly soon, whether an AI agent can transact with them. Right now, for most of this cohort, the answer is structurally no. Not “no, we chose not to” — no in the sense that there is nothing there to act against. The eleven agent-native companies in this set have a head start that is measured in years of accumulated contract, documentation, and operational discipline, not in a quarter of roadmap.

I will keep grinding through the backlog and publishing what the numbers say. The profiles, the artifacts, and the score history for every company are open on the network at providers.apievangelist.com/secondary-market, so you do not have to take my averages on faith — you can go read the evidence for any single company and disagree with me about it.

Stytch got it right. That is not a sentence I write often, so let me be precise about what I mean.

When I wrote about what programmatic API onboarding should look like, the ideal was a single script that opens a browser, lets you sign in, registers an application, and prints the credentials to your terminal. No support ticket. No sales call. No “contact us for API access.” Stytch’s Connected Apps feature clears that bar two different ways, and the second one is the one that matters for agents.

The first way is the honest, boring, fully supported path. You hold your Stytch project credentials, a project_id and a secret, and you authenticate with plain HTTP Basic against https://test.stytch.com or https://api.stytch.com. You POST /v1/connected_apps/clients with a client_type and a name, and you get back a connected_app object carrying a client_id and, for confidential clients, a client_secret. That secret is shown exactly once. Stytch stores a hash and cannot recover it, which is the correct behavior even if it means you have to actually read the response instead of going back to fish for it later. This is bucket (b) in my mental model: a management API and a token you paste in from an environment variable. It works, it is documented, and it does not require me to file anything with a human.

The second way is the one that made me sit up. Stytch implements RFC 7591, OAuth 2.0 Dynamic Client Registration, at POST /v1/oauth2/register. No authorization needed. A client, or an agent, can show up at runtime with no project credentials at all, post its redirect_uris and a name, and register itself. Public clients using token_endpoint_auth_method of none get deduplicated by their metadata, so an agent that registers twice with the same shape gets the same client_id back instead of littering your project with junk. This is not an accident. Stytch built this specifically for MCP, the protocol that lets agents discover and call tools, and they have written openly about why dynamic client registration is the missing piece for agentic auth. That is the whole point. An agent cannot stop and ask a human to go create an OAuth app in a dashboard. It has to register itself, and Stytch lets it.

So I wrote the script. It does both. Run it in the default mode and it uses your STYTCH_PROJECT_ID and STYTCH_SECRET to create a Connected App through the management endpoint. Pass --dcr and it skips the credentials entirely and hits the public dynamic registration endpoint, the way an agent would. Either way it prints client_id and, when there is one, client_secret to stdout. Node 18, standard library only, no npm install.

#!/usr/bin/env node
// stytch-api-auth.mjs — Register a Stytch Connected App (Management or RFC 7591 DCR).
// Env: STYTCH_PROJECT_ID, STYTCH_SECRET, STYTCH_ENV=test|live
// Default: HTTP Basic POST /v1/connected_apps/clients
// --dcr:   public POST /v1/public/<project_id>/oauth2/register
// Docs: https://stytch.com/docs/b2b/api/connected-apps-create
//       https://stytch.com/docs/b2b/api/connected-app-dynamic-client-registration
// See the full, committed source at:
//   /assets/scripts/agentic-onboarding/stytch-api-auth.mjs
// (Full implementation is checked into the repo; the management + DCR paths,
//  HTTP Basic auth, env handling, --help, and credential printing are all there.)
import { parseArgs } from "node:util";
import process from "node:process";

const ENV_BASE = { test: "https://test.stytch.com", live: "https://api.stytch.com" };
const CREATE_PATH = "/v1/connected_apps/clients";
const dcrPath = (id) => `/v1/public/${id}/oauth2/register`; // NOTE: canonical form is https://${projectDomain}/v1/oauth2/register

function basicAuth(id, secret) {
  return "Basic " + Buffer.from(`${id}:${secret}`).toString("base64");
}
function requireEnv(name) {
  const v = process.env[name];
  if (!v) { console.error(`Missing required environment variable: ${name}`); process.exit(1); }
  return v;
}
async function req({ url, method = "POST", headers = {}, body }) {
  const res = await fetch(url, {
    method,
    headers: { accept: "application/json", "content-type": "application/json", ...headers },
    body: JSON.stringify(body),
  });
  return { res, text: await res.text() };
}
async function createConnectedApp({ base, id, secret, clientType, name, website }) {
  const url = new URL(CREATE_PATH, base).toString();
  const { res, text } = await req({
    url,
    headers: { authorization: basicAuth(id, secret) },
    body: { client_type: clientType, ...(name && { client_name: name }), ...(website && { redirect_urls: [website] }) },
  });
  if (res.ok) { const j = JSON.parse(text); return (j.connected_app ?? j); }
  throw new Error(`Create (POST ${url}) failed: ${res.status} ${text}`);
}
async function registerViaDcr({ base, id, name, website, authMethod }) {
  const url = new URL(dcrPath(id), base).toString();
  const { res, text } = await req({
    url,
    body: { redirect_uris: website ? [website] : [], ...(name && { client_name: name }), token_endpoint_auth_method: authMethod },
  });
  if (res.ok) return JSON.parse(text);
  throw new Error(`DCR register (POST ${url}) failed: ${res.status} ${text}`);
}
function printCreds(app) {
  const out = {
    client_id: app.client_id,
    client_secret: app.client_secret,
    name: app.client_name,
    client_type: app.client_type,
    token_endpoint_auth_method: app.token_endpoint_auth_method,
  };
  for (const k of Object.keys(out)) if (out[k] == null) delete out[k];
  const lines = [`client_id=${out.client_id ?? ""}`];
  if (out.client_secret) lines.push(`client_secret=${out.client_secret}`);
  lines.push("", JSON.stringify(out, null, 2), "");
  process.stdout.write(lines.join("\n"));
}

const { values: { name, website, type, dcr, help } } = parseArgs({
  options: {
    name: { type: "string" }, website: { type: "string" }, type: { type: "string" },
    dcr: { type: "boolean" }, help: { type: "boolean", short: "h" },
  },
  strict: true, allowPositionals: false,
});

if (help) {
  console.log(`Usage: stytch-api-auth [--dcr] [--name N] [--website URL] [--type T]
  default: POST /v1/connected_apps/clients (HTTP Basic project_id:secret)
  --dcr:   public RFC 7591 POST /v1/public/<project_id>/oauth2/register
  --type:  management: first_party|first_party_public|third_party|third_party_public (default third_party)
           dcr: public|confidential (default confidential)
  Env: STYTCH_PROJECT_ID, STYTCH_SECRET, STYTCH_ENV=test|live`);
  process.exit(0);
}

const base = ENV_BASE[(process.env.STYTCH_ENV || "test").toLowerCase()];
if (!base) { console.error('STYTCH_ENV must be "test" or "live".'); process.exit(1); }
const projectId = requireEnv("STYTCH_PROJECT_ID");

(async () => {
  try {
    let app;
    if (dcr) {
      app = await registerViaDcr({ base, id: projectId, name, website, authMethod: type === "public" ? "none" : "client_secret_basic" });
    } else {
      const secret = requireEnv("STYTCH_SECRET");
      app = await createConnectedApp({ base, id: projectId, secret, clientType: type || "third_party", name, website });
    }
    if (!app?.client_id) throw new Error("No client_id returned by Stytch.");
    if (!app.client_secret) console.error("Note: no client_secret (public client). Use PKCE.");
    printCreds(app);
  } catch (e) {
    console.error("Error:", e?.message || e);
    process.exit(1);
  }
})();

I will be honest about the one seam. The dynamic registration endpoint canonically lives on your project’s custom authentication domain, and the project-id-in-the-path form I use in the script is the public fallback you want to verify against your own project before you lean on it. That is a small annoyance, not a wall. Everything else here is exactly what I have been asking the rest of the industry for. The script is committed in the repo at /assets/scripts/agentic-onboarding/stytch-api-auth.mjs.

Here is the thing I want every other vendor to take from this. Stytch did not have to invent some proprietary onboarding API to meet the agentic moment. They implemented an existing standard, RFC 7591, and pointed it at the obvious use case. That is the whole move. The agents are not waiting for your roadmap. They are waiting for an endpoint they can call without a human in the loop, and Stytch shipped it. I will take what I can get, and this is one of the few times I get to point at a company and say: do this.