@skyemeta/access is live on npm. Either-or middleware: your existing API-key customers pass through untouched; agents authenticate by signing with the wallet they already carry. Both work on the same routes. Free, MIT.
You run an API. Today it authenticates with a key — a static string in an env file somewhere. That worked when your customers were humans who signed up with an email address. But now AI agents are knocking, and they don't have email. They have wallets. They sign things. Giving them a static string feels wrong because it is wrong.
You don't have to rip out what works. @skyemeta/access is either-or middleware: X-API-Key requests run your existing handler, untouched. Authorization: Wallet requests get verified through InsumerAPI's /v1/attest endpoint. Drop it in any Node API, get the agent path for free.
Two failure modes worth caring about, both real, both worse for agents than for humans.
Security. An API key is one string that's valid forever. It sits in env files, gets logged on errors, leaks via postinstall scripts and malicious npm dependencies, ends up in screenshots. Half the security incidents you've read about in the last decade started with a leaked key. Humans accept the risk because the cost of "rotate everything" is human-scale. Agents are running on infrastructure you don't fully control — orchestrators, cloud workers, third-party tools — and they can spawn faster than your rotation policy can keep up.
A wallet signature is different. The private key never crosses the wire. What hits the server is a freshly signed message bound to this specific request — nonce, timestamp, method. Replay-proof by design. Even if an attacker intercepts the signature, they can't reuse it. And the signature is non-repudiable cryptographic proof of origin: the holder of this keypair signed exactly this message at exactly this time. You can prove it.
Privacy. This one is less talked about and just as important. Every service that authenticates with API keys maintains a customer database — a registry of who-uses-what, when, and how often. That registry is itself a security target. When it leaks, your customers' usage patterns leak.
Wallet signatures don't need a registry. The wallet is the identity. The chain is the source of truth for whether the wallet still meets your conditions. There's no central list to maintain, and nothing to leak.
Two distinct motivations show up in the wild, and both lead to the same primitive.
Reason 1 — Privacy. We built AgentTalk wallet-only from day one for exactly this reason. AgentTalk is a SCIF for AI agents: multi-party rooms where every participant must continuously meet a set of conditions, and where the fact that the conversation happened is itself sensitive. We literally could not run that product with API keys, because maintaining a list of "who pays us for SCIF sessions" would be the easiest piece of metadata to subpoena, breach, or accidentally log. So we don't. There is no AgentTalk customer database. The wallet pays, the wallet attests, the wallet is the identity. There's nothing to leak.
Reason 2 — Portability. InsumerAPI itself splits its purchase paths by who's authenticating. Humans signing up through the website get a traditional API key. An agent paying in USDC on an EVM chain gets, by default, a non-transferable on-chain access pass (a soulbound NFT) minted to its wallet plus a credit balance — no API key string returned. The agent authenticates to /v1/attest by signing with the wallet that holds the pass. (Some agents opt to receive a key alongside the pass — we won't turn them away. Non-EVM payments receive a key by default since there's no EVM address to mint the pass to.) Because the pass lives on-chain, any third party can verify "this wallet has paid for access" without trusting InsumerAPI's database. Different motivation than ours, same primitive: wallet auth as the agent's credential.
The point isn't that one motivation is right and the other wrong. The point is that both lead to wallet signatures replacing static strings. If either reason matters to you — and for agent infrastructure, at least one probably does — the move is the same.
@skyemeta/accessYou don't have to be maximalist. @skyemeta/access is for the realistic case: an existing API with existing customers, and now a growing slice of agent traffic.
npm install @skyemeta/accessA few lines of glue:
import express from 'express';
import { Access } from '@skyemeta/access';
const access = new Access({
insumerApiKey: process.env.INSUMER_API_KEY!,
siweDomain: 'api.yourservice.com',
collections: {
default: { address: process.env.ACCESS_COLLECTION!, chain: 'base' },
},
});
const app = express();
app.post(
'/api/v1/whatever',
access.requireValidPassOrApiKey(yourApiKeyMiddleware),
handler,
);What happens on each request:
X-API-Key header present → your existing handler runs, untouched. Zero overhead.Authorization: Wallet ... header present → the SDK verifies the SIWE signature, then asks InsumerAPI whether the wallet still holds a valid token from the configured collection. Yes → request passes. No → 401.Your humans keep their keys.
Your agents use the wallet they were going to carry anyway.
Both work on the same routes.
The wallet-signed path checks "does this wallet hold a token from a collection you specify?" The collection is yours. Any ERC-721 works.
InsumerAPI itself uses RNWY — the trust intelligence layer for autonomous AI agents — whose audited ERC-5192 factory on Base provides the soulbound issuance substrate for the InsumerAccess collection backing InsumerAPI's own customers. You can use RNWY too, or Thirdweb, Crossmint, or deploy your own contract. The SDK doesn't care — it just checks the wallet's holdings against the collection address you configured.
The SDK calls /v1/attest on your behalf from your server, so it needs a string credential in INSUMER_API_KEY. Two ways to get one.
Wallet-native (recommended for agent infrastructure). Send USDC or USDT to InsumerAPI's platform wallet on any supported chain, then POST the transaction hash. The sender wallet becomes the account's identity — no email, no signup form. The endpoint accepts three keyDelivery modes: "wallet" (default — only the on-chain pass + credits, no key string), "apiKey" (key string returned, plus the pass on EVM payment chains), or "both" (the explicit dual-credential form — same artifacts as "apiKey" on EVM, and the response's authHint makes the dual mode obvious). For the SDK use case, pass one of the latter two:
curl -X POST https://api.insumermodel.com/v1/keys/buy \
-H "Content-Type: application/json" \
-d '{"txHash":"0x…","chainId":8453,"amount":5,"appName":"my-agent","keyDelivery":"apiKey"}'On EVM payment chains, you also get the on-chain access pass minted to the sender wallet alongside the key — meaning the same wallet can also use signed-message auth (Authorization: Wallet) directly on /v1/attest from an agent runtime that prefers signing over carrying the key. Solana, Bitcoin, and Tron are supported via the same endpoint and return a key by default (no EVM address to mint the pass to). Minimum purchase is $5. Volume tiers kick in at $100 and $500 buys. See the OpenAPI spec for the full schema and per-chain payment addresses.
Human signup (free tier). If you're a developer who just wants to try it without paying, the signup form at insumermodel.com issues a free key (10 attestation credits, 100 requests/day, no card) in about ten seconds.
@skyemeta/access v0.1.x focuses on the common case: NFT ownership on EVM chains. That covers 31 of InsumerAPI's 37 chains — Ethereum, Base, Optimism, Arbitrum, Polygon, plus 26 more EVM networks. Richer condition types (token_balance, eas_attestation, farcaster_id, compound stacks) and non-EVM chains (Solana, XRPL, Bitcoin, Tron, Stellar, Sui) are reachable via direct calls to /v1/attest. The SDK middleware stays focused on what most adopters actually deploy.
The SDK is free and MIT-licensed. Source on GitHub. Read it, fork it, ship it.
Each wallet-signed request hits InsumerAPI's /v1/attest once per cache window per wallet — by default a wallet sending five requests in a single second triggers one upstream call; the others are served from the in-process cache. Adopters running high-throughput or revocation-sensitive flows can shrink the cache window or disable it entirely. API-key requests never touch InsumerAPI; they pass straight through to your existing handler.
Cryptographic proof of origin. Ephemeral signatures. No customer registry. Trust the math, not a company — including us. Your humans keep their keys. Your agents use the wallet they were going to carry anyway. Both work on the same routes.