API Reference

Boolean attestation. Checks token balances, NFT ownership, EAS attestations, Farcaster identity, arbitrary boolean view calls, dimensionless ratio rules, account code, and agent standing across 37 chains. Returns ECDSA P-256 signed result with a post-quantum signature (pqSig/pqKid). Up to 10 conditions per request. Full docs →

Returns the JWKS (JSON Web Key Set) containing the ECDSA P-256 public key used to sign attestation and trust responses and the ML-DSA-65 post-quantum key as RFC 9964 AKP entries appended after the EC entries. 24-hour cache. Also available as a static file at /.well-known/jwks.json.

No parameters. Returns { keys: [{ kty: "EC", crv, x, y, kid, alg, use }, ..., { kty: "AKP", alg: "ML-DSA-65", pub, kid, use }] }

Responses sign under one of three key IDs over the same P-256 key: insumer-attest-v1 (legacy keys), insumer-attest-v2 (new keys, domain-separated), and insumer-trust-v2 (trust profiles). Select the key by the kid on the response; never hardcode one. The two AKP entries that follow, insumer-attest-pq1 and insumer-trust-pq1, hold the ML-DSA-65 key for the post-quantum signature (pqSig/pqKid); resolve them by the pqKid on the response. See the signing spec.

Lists all available compliance templates with their condition configurations. Full docs →

No parameters. Returns data.templates, keyed by name, each with provider, description, chainId and chainName: coinbase_verified_account, coinbase_verified_country, coinbase_one (Base), gitcoin_passport_score, gitcoin_passport_active (Optimism).

Generates an ECDSA-signed wallet trust profile with curated presence checks across up to 14 dimensions: stablecoins (52), governance (8), nfts (3), staking (5), institutional_stablecoins (8), tokenized_treasuries (16), stablecoin_deposits (39), wrapped_bitcoin (12), names (2), account (10: contract code and EIP-7702 delegation present, on Ethereum, Base, Arbitrum, Optimism and Polygon), 155 base checks across 27 chains, plus optional solana (14), xrpl (3), bitcoin (1) and tron (3) dimensions. Up to 176 checks across 29 chains. Dimensions come back in a fixed order, the same for every wallet. conditionSetVersion is "2026-10-08" on every key version and names the check list that was run. 3 credits per call. Full docs →

Batch trust profiles for up to 10 wallets in a single request, each profile signed separately. 3 credits per wallet. Partial success supported.

Check wallet state against the store's conditions and generate a discount code in OpenAI/Stripe ACP format. Cost, errors and the hourly limit are the same as /v1/verify. Full docs →

Check wallet state against the store's conditions and generate a discount code in Google UCP format. Cost, errors and the hourly limit are the same as /v1/verify.

Validate a discount code. Public endpoint, no API key required. Returns code status, merchant, discount percentage, and expiry.

Invalid codes return reason: "not_found" | "expired" | "already_used"

Verify wallet token/NFT holdings against a merchant's configured requirements and return a discount code if eligible. A code that carries a discount costs one credit from the API key that owns the store; a 0% result is free, and a caller using another key is not charged. 402 when the owner key has no credits left (only for a code that carries a discount); 403 when the store has no active owner API key; Paid discount codes requested with a key other than the store's owner are subject to an hourly limit (429; the message says when to try again). The result is signed first; the credit is taken and the code is stored together after that, and a coupon is created only once the code exists. A result that cannot be signed, or a code that cannot be stored, answers 503 in the standard error envelope with no credit used and no code created. A read that does not complete answers 503 rpc_failure. Both are safe to retry.

Verify an on-chain USDC payment and mark a discount code as used. Confirms the transaction on-chain before accepting.

Check if a wallet is eligible for a discount at a specific merchant without generating a code. Answers 503 rpc_failure when a read does not complete: nothing is concluded about the wallet, so retry. A frozen XRPL trust line earns no tier.

List all published merchants in the directory. Returns merchant name, ID, location, accepted tokens, and discount tiers.

Get full details for a specific merchant including accepted tokens, NFTs, discount configuration, and business info.

List all tokens supported across the platform with contract addresses, chain IDs, decimals, and logos.

Create a new merchant programmatically. The API key that creates it owns it and pays one credit for each code or tap at the store that carries a discount (a 0% result is free) and for every in-store scan; the store has no balance of its own. A key can create a limited number of merchants (429 past it). Full docs →

Generate a verification token for proving domain ownership. Supports DNS TXT record, HTML meta tag, or verification file. Each POST regenerates the token.

Check all three verification methods (DNS TXT, meta tag, file) for the previously requested domain. Rate limited per merchant (429 says when to retry).

Configure which tokens the merchant accepts and the minimum balance required for discounts.

Configure which NFT collections the merchant accepts for discounts.

Update discount stacking mode, cap, the store’s terms for wallets sent without a walletProof, and USDC payment settings. All fields optional.

Kept for compatibility. Buys credits with USDC, USDT or BTC into the regular balance of the API key that owns the merchant, the same balance that pays for the store's codes, scans and taps. Flat $0.04 per credit (25 credits per $1) at every purchase size. POST /v1/credits/buy is the normal way to top up and carries the volume tiers. See wallet addresses →

Sender verification: The first purchase registers the sender wallet to the API key. Subsequent purchases must come from the same sender. To change the registered wallet, include "updateWallet": true; the verified transfer proves ownership.

Publish (or refresh) the merchant's listing in the public directory. No request body needed to publish. Send { "listed": false } to unpublish (delist). Partner-provisioned merchants (created with an externalId) must pass domain verification before they can publish.

Get the setup completion status for a merchant. Shows which steps are done: domain verified, tokens configured, published, etc.

Record that a managing white-label partner verified an org's domain in its own branded flow, so the org can publish to the directory without seeing an Insumer-branded challenge. Sets verification.status=verified with method=partner. Restricted to designated white-label partner keys: self-serve keys get 403 and must use the domain-verification challenge flow above.

Submit a token or NFT collection to the public registry as pending for human approval. API key required (free: no credits charged). Idempotent per chain + address. A submission is held as pending until approved; some are added at once (the response says which: pending, active). Returns a flat envelope (no data wrapper).

Add a scanner PIN ({ name?, pin }, 4–8 digits; a merchant can hold a limited number of scanners) or remove one ({ remove: scannerId }). Owner key only. PINs are stored salted + hashed and never returned.

List a merchant's scanners (id and name only; PINs are never exposed). Owner key only.

Validate a scanner PIN and return the merchant config for a login-less branded scanner. Owner key only. Repeated failed PIN attempts are limited per merchant (429).

Verify a scanned pass and compute the discount. InsumerAPI verifies the ECDSA signature on the scanned QR, enforces 65-second freshness, then computes the discount against the merchant config. A bad signature is rejected with no discount. Metered on the partner key.

Check your current credit balance and plan tier.

No parameters. Returns apiKeyCredits, tier, and dailyLimit.

Buy a new API key with USDC, USDT, or BTC. Agent-friendly: no email or prior authentication needed. The sender wallet from the transaction becomes the key's identity. See wallet addresses and volume discounts →

How it works: Send USDC, USDT, or BTC to the platform wallet on any supported chain, then call this endpoint with the transaction hash. The on-chain transfer is verified (BTC requires 1 confirmation), a new API key is created, and credits are added at volume-discount rates. USDC and USDT are accepted at face value; BTC is converted to USD at the market rate. One key per wallet. Use POST /v1/credits/buy to top up an existing key.

Response fields: On EVM purchases an Insumer Access pass (non-transferable ERC-721 on Base) is minted to the sender wallet; details are in the passMint block. The response also carries authMethod ("wallet" | "apiKey" | "both") indicating which credentials were delivered, and on the wallet path a human-readable authHint. The key field is conditionally present: omitted by default when the pass mints, returned when keyDelivery is "apiKey"/"both", and returned regardless on non-EVM purchases (Solana, BTC, Tron) or when the pass mint defers, so no buyer is left without a usable credential.

Purchase additional verification credits using USDC, USDT, or BTC on supported chains. See wallet addresses and volume discounts →

Auth: Accepts X-API-Key or Authorization: Wallet (SIWE envelope from a wallet that holds the Insumer Access pass). Wallet-auth callers let an SBT-holding agent top up without ever handling an API key. See Authentication →

Sender verification: The first purchase registers the sender wallet to the API key. Subsequent purchases must come from the same sender. To change the registered wallet, include "updateWallet": true; the verified transfer proves ownership. Wallet-auth callers: updateWallet is ignored. The SIWE signer is already bound to the registered wallet and the soulbound Insumer Access pass cannot follow a rotation, so honouring the rewrite would silently lock the caller out on the next sign-in. To rotate, use X-API-Key auth.