The first question developers ask when evaluating a blockchain API: what data do you return? Most on-chain APIs hand back raw token balances, full transaction histories, and wallet addresses. InsumerAPI was designed to do the opposite. It verifies ownership and returns a yes or no. The balance itself never leaves the server.

The problem with raw balance APIs

Blockchain data is public, but that does not mean every application needs to see all of it. When a shopping agent checks whether a user holds enough UNI tokens to qualify for a 10% discount, the agent does not need to know that the wallet holds exactly 5,420.37 UNI. It only needs to know: does this wallet qualify?

Returning raw balances creates problems that developers would rather avoid:

Developers building token-gated features need verification, not surveillance. That is the design principle behind InsumerAPI.

Boolean attestations: yes or no, nothing more

The flagship endpoint is POST /v1/attest. You submit up to 10 conditions ("Does this wallet hold at least 1,000 USDC on Ethereum? Does it own an NFT from this collection on Polygon?") and get back a true or false for each one, signed with an ECDSA P-256 key.

Here is what the response looks like:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-A9D2E6B7C8F01234",
      "pass": false,
      "results": [
        { "condition": 0, "label": "USDC >= 1000", "type": "token_balance", "chainId": 1, "met": true,
          "evaluatedCondition": { "type": "token_balance", "chainId": 1, "contractAddress": "0xA0b8...eB48", "operator": "gte", "threshold": 1000, "decimals": 6 },
          "conditionHash": "0x3a7f...", "blockNumber": "0x12f4a80", "blockTimestamp": "2026-02-24T12:00:00.000Z" },
        { "condition": 1, "label": "Pudgy Penguin holder", "type": "nft_ownership", "chainId": 1, "met": false,
          "evaluatedCondition": { "type": "nft_ownership", "chainId": 1, "contractAddress": "0xBd35...7233", "operator": "gt", "threshold": 0 },
          "conditionHash": "0x9b2e...", "blockNumber": "0x12f4a80", "blockTimestamp": "2026-02-24T12:00:00.000Z" }
      ],
      "passCount": 1,
      "failCount": 1,
      "attestedAt": "2026-02-24T12:00:00.000Z",
      "expiresAt": "2026-02-24T12:30:00.000Z"
    },
    "sig": "MEUCIQC...",
    "kid": "insumer-attest-v1"
  },
  "meta": { "creditsRemaining": 98, "creditsCharged": 1, "version": "1.0", "timestamp": "2026-02-24T12:00:01.000Z" }
}

No balance field. No wallet address echoed back. No transaction history. Just the boolean result you asked for, signed so you can verify it cryptographically.

This covers the use cases developers are actively building right now. Token-gated game arenas where players prove they hold enough tokens to enter. Freelance platforms where premium features unlock at a holding threshold. NFT verification endpoints for payment processors. Holder badge systems with Bronze, Silver, and Gold tiers. Token-gated lotteries that verify holdings at entry and again at draw time. Agent identity verification where one AI agent proves its on-chain credentials to another. All of these are yes/no questions at their core.

For implementation details on POST /v1/attest and the privacy guarantees built into every response, see the AI Agent Verification API overview and the verification developer guide.

Tier-only discount responses

The discount endpoints (GET /v1/discount/check and POST /v1/verify) return the tier name and discount percentage for each token a merchant accepts. If a merchant has configured Gold at 10,000 tokens for 15% off and Silver at 1,000 tokens for 5% off, the API tells you which tier the wallet qualifies for. It does not tell you how far above or below the threshold the wallet sits.

{
  "ok": true,
  "data": {
    "discount": 15,
    "breakdown": [
      {
        "symbol": "UNI",
        "tier": "Gold",
        "discount": 15,
        "chain": 1
      }
    ]
  }
}

A merchant sees "Gold tier, 15% discount." They do not see that the customer holds 47,000 UNI. The customer gets their discount. The merchant gets their sale. Nobody handles data they did not need.

What does not get stored

Privacy is not just about what the API returns. It is also about what happens on the server side. Here is what InsumerAPI does not persist:

This is a design guarantee, not a configuration setting. The fields do not exist in the database schema. There is no admin toggle to turn them on. The data is architecturally absent. This architectural approach to privacy is also what informed the credential we never built.

Cryptographic proof, not trust

Every attestation response includes an ECDSA P-256 signature over the result and timestamp. This means a downstream system can verify the result offline using the public key. No second API call needed. No trust in a middleman.

For agent-to-agent workflows, this matters. An AI agent requests an attestation, receives a signed result, and passes it to another agent or service. The receiving party verifies the signature and knows the result came from InsumerAPI, was not tampered with, and was issued at a specific time. All without contacting the API again.

The timestamp is part of the signed payload. Verifications are point-in-time snapshots. A result from an hour ago proves what was true an hour ago, not what is true now. This is intentional. On-chain state changes with every block. The signature anchors the result to a specific moment.

What developers are building with this

Across GitHub, developers are opening issues for the same set of problems. They want to verify token ownership without managing RPC connections, contract ABIs, and chain-specific logic. Here are the patterns we see most often:

How this compares to other approaches

Developers evaluating on-chain verification have several options. Here is how they differ on privacy:

InsumerAPI sits in a specific spot: practical data minimization without ZK complexity. Boolean results, ECDSA signatures, 33 chains, REST API. No circuit design, no specialized infrastructure, no schema definition. One HTTP call, one signed answer.

Built for AI agents

The AI agent ecosystem is growing fast. MCP servers, LangChain tools, OpenAI GPT Actions, and direct REST integrations are how agents connect to external services. InsumerAPI ships all four:

By default, every tool returns boolean results or discount tiers, not raw balances. An agent using InsumerAPI in standard mode cannot accidentally accumulate financial data about users. Callers who need trustless verification can explicitly opt in to Merkle storage proofs, which include raw balance data for independent on-chain verification. The privacy default is enforced at the API level, not left to the agent developer to implement.

Why developers choose this approach

The developers building on InsumerAPI tend to share a few priorities:

33 chains, same privacy model

InsumerAPI verifies across 32 blockchains: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, and 24 more. The privacy model is identical on every chain. Whether you are checking an ERC-20 balance on Ethereum or an SPL token on Solana, the response format is the same. Boolean result, tier name, discount percentage. No balance, no address, no chain-specific data leakage.

This consistency matters for developers building multi-chain applications. One integration, one response format, one privacy guarantee across every supported network. For how the API surface was designed for composability across verification, compliance, and commerce, see the architecture deep dive.

Try it yourself

Create a free API key on the developer portal. You get 10 verification credits to test the attestation endpoint across all 33 chains. Run a few calls and look at what comes back. You will see booleans, tiers, and signatures. You will not see balances.

That is the point.

Get a free API key in 30 seconds

InsumerAPI is free to start. 10 verification credits, 33 chains, boolean results by default with optional Merkle proofs. See what comes back.

View Developer Portal