Every API your agent uses today required a human to sign up. Someone visited a portal, entered an email, added a credit card, copied a key, and pasted it into a config file. The agent never touches that process. It just receives the key and starts calling. That dependency on a human is the bottleneck that breaks autonomous agent loops.

The primitive

Before the lifecycle, understand the primitive. You send conditions in. You get cryptographically verifiable results out. Each result is ECDSA P-256 signed with a discoverable public key (JWKS). Block numbers and timestamps are included for freshness. The agent does not need to trust the API provider. It verifies the signature independently, offline, using any standard JWT library.

This is what enables everything below. Every step in the lifecycle produces or consumes signed, verifiable artifacts. Nothing requires trust. Everything is checkable.

The lifecycle

Discovery
1. Discover API
↓
2. Buy key with crypto
↓
3. Explore capabilities
↓
Core primitive
4. Verify wallets
↓
Commerce
5. Create merchant
↓
6. Configure program
↓
7. Verify domain
↓
8. Publish to directory
↓
Operations
9. Verify customers
↓
10. Refuel with crypto

Every step is a single API call. No portal, no browser, no human. Here is what each one does.

The problem with human-gated onboarding

Most APIs assume a human operator. Sign up, verify an email, enter a credit card, copy a key. Agents inherit keys from humans — they never acquire them independently. That dependency breaks autonomous loops.

InsumerAPI removes that requirement. A human can still sign up via the website, generate a free key, and manage everything through a dashboard. But an agent does not have to. It can go from discovering the API to running an entire merchant operation without any human involvement. Here is exactly how.

Step 1: Discover

An autonomous agent needs to find the API before it can use it. InsumerAPI publishes machine-readable discovery files at predictable locations:

For agents using the Model Context Protocol, InsumerAPI is published in the MCP Official Registry. An MCP-compatible agent can discover and connect to it without knowing the URL in advance.

An agent that crawls a site and reads llms.txt will find everything it needs: the base URL, the authentication method (X-API-Key header), and a list of 26 endpoints. For more on how agents use credentials and discovery to find services autonomously, see our piece on the credentials route.

Step 2: Buy a key with crypto

This is the step that does not exist anywhere else. The agent sends USDC, USDT, or BTC to a platform wallet, then calls POST /v1/keys/buy with the transaction hash. No email. No credit card. No human approval. The sender wallet address from the on-chain transaction becomes the key's identity.

The request takes three or four fields:

The API verifies the transfer on-chain, confirms the amount reached the platform wallet, and returns a live API key with credits loaded:

POST /v1/keys/buy

{
  "txHash": "0xabc123...",
  "chainId": 8453,
  "amount": 10,
  "appName": "my-verification-agent"
}

Response:

{
  "ok": true,
  "data": {
    "success": true,
    "key": "insr_live_...",
    "name": "my-verification-agent",
    "tier": "paid",
    "dailyLimit": 10000,
    "creditsAdded": 250,
    "totalCredits": 250,
    "usdcPaid": "10.000000",
    "effectiveRate": "$0.0400/credit",
    "chainName": "Base",
    "registeredWallet": "0x..."
  }
}

The key is shown once. The agent stores it and starts calling endpoints immediately.

Volume discounts apply automatically. $5 to $99 gets 25 credits per dollar ($0.04/call). $100 to $499 gets 33 credits per dollar ($0.03/call). $500 or more gets 50 credits per dollar ($0.02/call). The agent picks its own spend level.

One key per wallet address. If the agent already has a key and needs more credits, it calls POST /v1/credits/buy with the same pattern: send crypto, submit the transaction hash.

Step 3: Explore

Before running paid verifications, the agent can explore what is available using free, public endpoints:

These endpoints cost zero credits. The agent builds its understanding of the API's capabilities before spending anything.

Step 4: Verify wallets

With a key loaded, the agent calls the verification endpoints. The core is POST /v1/attest: send a wallet address and up to 10 conditions, get back ECDSA-signed boolean results. Does this wallet hold at least 100 USDC on Base? Does it own an NFT from this collection on Ethereum? Is it Coinbase-verified? Each condition returns met: true or met: false. No raw balances exposed.

For broader trust assessment, POST /v1/trust returns a structured fact profile across stablecoins, governance tokens, NFTs, and staking positions. POST /v1/trust/batch profiles up to 10 wallets in one request.

Every response is ECDSA P-256 signed. The agent can verify the signature against the public key at /v1/jwks without trusting the API provider. Block numbers and timestamps are included for freshness. Optional Merkle storage proofs are available for trustless verification against block headers. For a deeper look at the attestation API and how it verifies anything on-chain, see our technical overview.

Step 5: Create a merchant

This is where the lifecycle goes beyond verification. The agent can set up and operate an entire merchant business programmatically.

POST /v1/merchants creates a new merchant with a company name, a unique ID, and an optional location. The merchant receives 100 free verification credits. The API key that creates the merchant owns it. Up to 10 merchants per key.

POST /v1/merchants

{
  "companyName": "Acme Coffee",
  "companyId": "ACME-COFFEE",
  "location": "New York, NY"
}

One call. The merchant exists.

Step 6: Configure the program

The agent now configures what the merchant accepts and what discounts to offer. Two endpoints:

PUT /v1/merchants/{id}/tokens sets up token tiers. The merchant's own token and up to 8 partner tokens, each with named discount tiers (Bronze/Silver/Gold or whatever the agent decides). Each tier defines a holding threshold and a discount percentage.

PUT /v1/merchants/ACME-COFFEE/tokens

{
  "ownToken": {
    "symbol": "ACME",
    "chainId": 8453,
    "contractAddress": "0x1234...5678",
    "decimals": 18,
    "tiers": [
      { "name": "Bronze", "threshold": 100, "discount": 5 },
      { "name": "Silver", "threshold": 1000, "discount": 10 },
      { "name": "Gold", "threshold": 10000, "discount": 15 }
    ]
  },
  "partnerTokens": []
}

PUT /v1/merchants/{id}/nfts adds NFT collections that grant discounts. Up to 4 collections. Each one specifies a contract address, chain, and discount percentage.

PUT /v1/merchants/{id}/settings configures discount stacking (highest single discount or stack multiple), a discount cap, and optionally stablecoin payment settings with the merchant's own wallet addresses.

Step 7: Verify the domain

Domain verification proves the merchant controls the website they claim. Two calls:

POST /v1/merchants/{id}/domain-verification generates a verification token. The API returns three ways to place it: DNS TXT record, HTML meta tag, or a file at a well-known path. The agent picks whichever method it can execute (an agent with DNS API access uses TXT; one with file system access uses the file method).

PUT /v1/merchants/{id}/domain-verification triggers the check. The API looks for the token via all three methods. If any one succeeds, the domain is verified.

Step 8: Publish to the directory

POST /v1/merchants/{id}/directory publishes the merchant to the public directory. Other agents and customers can now discover it via GET /v1/merchants. No request body needed. The listing includes the merchant's token tiers, NFT collections, discount rules, and verification status.

Call it again after updating tokens or settings to refresh the listing.

Step 9: Verify customers

The merchant is live. Now the agent verifies customers who walk in (or connect a wallet). POST /v1/verify takes a merchant ID and wallet address, checks the customer's holdings against the configured token tiers and NFT collections, and returns the applicable discount. One merchant credit per verification.

For commerce protocol integrations, POST /v1/acp/discount wraps the same verification in OpenAI/Stripe Agentic Commerce Protocol format (coupon objects, allocations, applied/rejected arrays). POST /v1/ucp/discount does the same for Google's Universal Commerce Protocol. The agent picks the format that matches its commerce framework.

Step 10: Refuel

When credits run low, the agent sends more USDC, USDT, or BTC and calls POST /v1/credits/buy. Same pattern: transaction hash, chain ID, amount (optional for BTC). Credits are added instantly. The registered wallet must match the one that created the key (or the agent includes "updateWallet": true to register a new wallet, proved by the transfer itself).

For merchant-specific credits consumed by /v1/verify, POST /v1/merchants/{id}/credits tops up the merchant's own credit pool. Same crypto payment pattern.

This is the step that closes the loop. Without refueling, the lifecycle is a sequence that ends when credits hit zero. With it, the agent returns to Step 4 and continues operating indefinitely. Discover, acquire, operate, refuel, repeat. That is not a workflow. It is a self-sustaining cycle. The agent does not need a human to top up credits, renew a subscription, or re-authorize access. It pays for what it uses and keeps running. For the broader context on wallet auth in agentic commerce, see how verification fits into agent payment flows.

Why this matters

The agent ecosystem is building toward autonomy. Frameworks like MCP, x402, and ERC-8183 assume agents that can discover services, negotiate terms, and transact independently. But most APIs still gate access behind human signup flows. That gap is not just an inconvenience. It is an architectural constraint that limits what autonomous agents can do.

InsumerAPI removes it. An agent that holds USDC, USDT, or BTC can acquire its own verification infrastructure, set up a merchant business, configure a discount program, verify a domain, publish to a directory, verify customers, and top up credits. The entire operation runs without a human ever touching a signup form, a dashboard, or a settings page.

This is not a feature list. It is an architecture. The same API that verifies a wallet also creates the merchant that accepts the wallet holder as a customer. The same crypto that bought the key also buys the credits. The same ECDSA signature that proves a token holding also secures the discount code the customer receives.

Every agent framework, same lifecycle

The entire lifecycle above works the same way regardless of how the agent connects. InsumerAPI ships native integrations for four ecosystems:

Same 26 endpoints, same ECDSA-signed results, same 32 blockchains. The transport layer changes. The lifecycle does not.

The lifecycle works because the underlying primitive converts blockchain state into cryptographically verifiable credentials that agents can trust without trusting the provider. That primitive does not change whether the agent connects via MCP, LangChain, ElizaOS, or raw HTTP. And it does not change whether a human or an agent initiates the flow.

The full autonomous lifecycle works today.

Build an autonomous agent today

InsumerAPI has 26 endpoints across verification, trust profiling, and commerce. Start with a free key or go straight to crypto. Full docs at the developer portal.

View Developer Portal