Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the InsumerAPI, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Finsumermodel.com%2Finsumermodel" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Finsumermodel.com%2Finsumermodel" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with InsumerAPI API.
Attest that a wallet meets 1 to 10 conditions such as token_balance with a threshold, nft_ownership, or eas_attestation, each with its own chainId
Return ECDSA-signed booleans that a verifier checks offline against GET /v1/jwks, optionally with proof set to merkle for EIP-1186 storage proofs
Build a signed wallet trust profile of presence checks across stablecoins, governance, NFTs, staking, and other dimensions, singly or in batch
Use a compliance template such as Coinbase Verifications in place of a raw EAS schemaId
GET STARTED
Check whether a wallet qualifies for a merchant's token-holder discount and issue a signed INSR discount code
Configure a merchant's token tiers, NFT collections, and discount settings such as discountMode and maxDiscountsPerWalletPerDay
Check the verification credit balance, tier, and daily rate limit for the account
Patterns agents use InsumerAPI API for, with concrete tasks.
★ Token-gated access checks from your agent through Jentic
An AI agent connected through Jentic decides whether a user may enter a gated community or feature by asking InsumerAPI whether their wallet meets the rule: for example a token_balance condition with a threshold of 100 on a stated chainId, or nft_ownership of a collection. The API returns a signed boolean rather than the wallet's balance, and the agent or your backend verifies the signature against the JWKS keys. Your X-API-Key stays in your own Jentic One instance.
Call POST /v1/attest with wallet '0xabc...' and conditions [{type: 'token_balance', contractAddress: 'native', chainId: 8453, threshold: '0.01'}], then report whether the condition was met
Agent standing and delegation checks
Before an agent acts for someone, a relying party can check that the agent wallet is registered under ERC-8004 or holds a currently valid ERC-7710 delegation from its principal. Both condition types run on Base and return a signed result, and the erc7710_delegation check can include a Merkle proof of the revocation slot.
Call POST /v1/attest with the agent wallet and a single erc8004_agent condition with its agentId on chainId 8453, then return the signed result
Wallet trust screening
Score a counterparty's wallet without seeing its holdings. The trust profile operation runs presence checks across dimensions such as stablecoins, governance, nfts, staking, and tokenized_treasuries, returns per-check booleans with an overall summary, and signs the result. The batch variant screens several wallets in one call.
Call POST /v1/trust with wallet '0xabc...', then summarise which dimensions returned at least one met check
Token-holder discounts for merchants
A store rewards holders of its own or partner tokens. Configure token tiers and NFT collections on the merchant, check what discount a wallet earns with the discount check, then issue a signed discount code through the verify operation. Codes can be validated by code later, and in-person staff can verify a scanned pass after starting a scanner session with a PIN.
Call GET /v1/discount/check with wallet '0xabc...' and merchant 'acme-store', then POST /v1/verify with merchantId 'acme-store' and the wallet to issue a discount code
46 endpoints — the insumerapi evaluates on-chain conditions for a wallet and returns ecdsa-signed yes-or-no answers, without ever exposing the wallet's balances.
METHOD
PATH
DESCRIPTION
/v1/attest
Create a signed on-chain condition attestation
/v1/trust
Get a signed wallet trust profile
/v1/trust/batch
Get trust profiles for several wallets
/v1/jwks
Get the public key set for verifying signatures
/v1/compliance/templates
List compliance templates
/v1/discount/check
Calculate a wallet's discount at a merchant
/v1/verify
Create a signed discount code
/v1/credits
Check credit balance and daily rate limit
/v1/attest
Create a signed on-chain condition attestation
/v1/trust
Get a signed wallet trust profile
/v1/trust/batch
Get trust profiles for several wallets
/v1/jwks
Get the public key set for verifying signatures
/v1/compliance/templates
List compliance templates
/v1/discount/check
Calculate a wallet's discount at a merchant
/v1/verify
Create a signed discount code
/v1/credits
Check credit balance and daily rate limit
What agents get from Jentic-routed access to this vendor.
Setup
Wiring InsumerAPI by hand means choosing between an X-API-Key and a SIWE wallet-signed Authorization header, building condition objects per chain, and verifying signed results against the JWKS keys. Through Jentic you install once, import InsumerAPI from the API Directory, store the key once, and your agent calls it.
Permission scoping
InsumerAPI puts the merchant id in the URL path for merchant configuration (/v1/merchants/{id}/settings), so a rule can pin your agent to one merchant and the operations you pick. Attestations and trust checks carry the wallet in the request body, so there rules bound which operations the agent may call, not which wallet.
Credential isolation
Your InsumerAPI key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'check whether a wallet holds a token' or 'get a wallet trust profile', and Jentic returns the matching InsumerAPI operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using InsumerAPI API through Jentic.
Is there an InsumerAPI MCP server?
You don't need an MCP server to give your agent InsumerAPI. Jentic connects it directly from the API Directory: import it, store your API key once, and your agent calls it. The agent finds the attestation, trust, or discount operation it needs on demand rather than carrying every tool definition in its context.
Can I limit what my agent is allowed to do with InsumerAPI?
Yes. For a gating agent, write a rule that allows only POST /v1/attest and GET /v1/jwks. The agent can check wallet conditions and fetch the keys to verify the answer, but it cannot buy credits, create keys, or change merchant settings, and every call it makes is logged. For a store assistant, allow PUT /v1/merchants/{id}/settings on your own merchant id only.
What authentication does InsumerAPI use?
Per its OpenAPI spec, most operations take an API key in the `X-API-Key` header, in the format insr_live_ followed by 40 hex characters. Five operations (POST /v1/attest, POST /v1/trust, POST /v1/trust/batch, GET /v1/credits, and POST /v1/credits/buy) also accept wallet-signed auth in the `Authorization` header as `Wallet <base64 SIWE message and signature>` from a wallet that holds the Insumer Access pass. Public reads such as GET /v1/jwks, GET /v1/compliance/templates, and GET /v1/health need no credential, and a few account operations such as POST /v1/keys/lookup take the key in the request body. Through Jentic, your key is stored encrypted by your own Jentic One instance and injected into the calls that need it.
Does InsumerAPI reveal a wallet's balance?
No. Per the spec, it returns signed booleans stating whether each condition was met and never returns raw balances or account code. A signed result shows that InsumerAPI read chain state and evaluated the stated conditions; it does not show who controls the wallet.
What are the rate limits for InsumerAPI?
The OpenAPI spec says each key has a daily request limit and returns 429 when it is exceeded, without stating a fixed number. GET /v1/credits returns your account's credit balance, tier, and daily rate limit; see https://insumermodel.com for plan details.
How many credits does an InsumerAPI attestation cost?
Per the spec, a standard POST /v1/attest call costs 1 credit and 2 credits with proof set to merkle. The erc8004_agent and erc7710_delegation condition types cost 1 credit.
How do I check a wallet's NFT ownership with InsumerAPI through Jentic?
Install Jentic One with `curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh`, import InsumerAPI from the API Directory, and store your API key. Your agent searches for 'check whether a wallet owns an NFT', gets POST /v1/attest with its input schema, and calls it with the wallet and an nft_ownership condition naming the contractAddress and chainId. To run it on your own infrastructure, install Jentic One from its GitHub repo.
For Agents
Check whether a wallet meets token, NFT, attestation, or agent-standing conditions and get a signed yes-or-no result, build wallet trust profiles, and run token-holder discounts for merchants.
Use for: Check whether this wallet holds at least 100 USDC on Base, I need to gate access to holders of a specific NFT collection, Verify that a wallet is a registered ERC-8004 agent, Get a signed trust profile for a wallet before accepting its order
Not supported: Does not handle sending transactions, custody, payments processing, or identity proofing of the person behind a wallet. Use for signed on-chain condition checks, wallet trust profiles, and token-holder merchant discounts only.
The InsumerAPI evaluates on-chain conditions for a wallet and returns ECDSA-signed yes-or-no answers, without ever exposing the wallet's balances. One call checks up to 10 conditions, such as a token balance threshold, NFT ownership, an EAS attestation, a Farcaster identity, or ERC-8004 agent registration, each on its own chain, and the signed result can be verified offline against the published JWKS keys, with an optional Merkle proof on EVM chains. Around that primitive it runs wallet trust profiles, merchant token-holder discounts and codes, point-of-sale pass scanning, ACP and UCP discount formats for agent commerce, and the key, credit, and billing operations.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>