scanned Oct 18, 2026

ZeroClick

zeroclick.ai

ai-mlVisit site →

ZeroClick enables businesses to sell their products or services to AI agents

75/100

Tier 4 · Agent-Ready

Content answers80/100

Protocol plumbing63/10010 of 16 checks pass

Re-audit20h ago· 1 credit

Scored by asking 15 questions a buyer of a ai-ml product asks, then grading this site’s own pages: answered, hedged (partial or vague), or silent (no page answers it). How scoring works

15 buyer questions · graded against the site’s own pages

9 of 15 come back answered. 5 get a hedge. 1 meets silence.

9 answerable5 half-answers1 silent

Goes silent · pricing · high importance

Is there a per-transaction percentage or fixed fee on settled usage, and does that cut change depending on the payment protocol or my plan tier?

This report is public. Own zeroclick.ai? Claiming is free: crawl every page, re-audit as you fix, and track your score over time.

The fix queue

25 points sit between zeroclick.ai and 100: 6 open questions and 6 missing protocol checks, ordered by estimated payoff.

Point estimates are per fix under scoring v2. They are not additive to a promised total.

01pricing · importance highGoes silent+7 content pts est.

Is there a per-transaction percentage or fixed fee on settled usage, and does that cut change depending on the payment protocol or my plan tier?

What the pages say

The retrieved documentation never states whether ZeroClick charges a per-transaction percentage or fixed fee on settled usage — no chunk mentions a platform fee, take rate, commission, or any deduction, including in the FAQ's 'Payments, pricing, and payouts' section and the payment-protocols 'Amounts and settlement' section, the two places where such a fee would most plausibly appear. What the docs do specify: settled amounts are computed purely as meter price × quantity (the FAQ's worked example: $0.002 per 1,000 output tokens × 4,523 tokens settles at exactly $0.009046), the zc-billing receipt reports only authorizedUsd / chargedUsd / remainderUsd with no fee field, and 'Buyers pay USDC, but your revenue settles to your connected Stripe account (in fiat or USDC, your choice)' — none of which addresses whether ZeroClick deducts a cut before or at payout. Likewise, nothing ties any economics to the payment protocol (the docs stress selling is protocol-agnostic: 'Nothing protocol-specific ever reaches your API'), and plan tier is documented only as controlling the seller's own meter rates ('a starter plan and a higher plan can charge different rates for the same operation'), not ZeroClick's fee. So neither the existence nor the variability of a transaction cut can be answered from the site as retrieved.

The fix

Document ZeroClick's own economics explicitly: state whether a per-transaction percentage or fixed fee applies to settled usage, where it is deducted (e.g., before the Stripe payout), and whether it differs across the x402 and MPP rails or across the five billing modes. A 'Fees' or 'ZeroClick pricing' entry in the FAQ's 'Payments, pricing, and payouts' section, or on the payment-protocols 'Amounts and settlement' page, would close this gap.

Where we looked: /faq, /resources/headers, /concepts/payment-protocols, /faq, /llms-full.txt

confidence medium · grounding synthesized · weight 0.00 · Absent

Hedged · 5 of 15 questions

A buyer gets something, then has to guess the rest. Expand any row for the evidence and the fix.

02What's the rate limit on the check-allowances endpoint, and what exact HTTP status and error code do I get back when I exceed it?limitsHedges+2 pts est.

What's the rate limit on the check-allowances endpoint, and what exact HTTP status and error code do I get back when I exceed it?

What the pages say

The site does not publish a rate limit for the check-allowances endpoint (POST /v1/usage/check), and therefore no exceed response for it either. The errors reference's 'Usage endpoint errors' section documents this endpoint's failure modes exhaustively but with no throttling case: a wrong scope is 403 `insufficient_scope` (the endpoint needs `usage:read`), a non-API-key credential is 403 `auth_type_not_allowed`, and denials are explicitly 'not an HTTP error' — 'The check returns `200` with the decision' plus one of seven `reason` codes (e.g. `usage_exhausted`). No 429 or rate-limit code appears anywhere for this endpoint. The only rate limit documented anywhere in the retrieved docs is on a different endpoint: Agentify (`GET /v1/agentify/markdown`) answers `429` for 'requests beyond 60 per minute per organization.' So the buyer's question — the numeric limit and the exact HTTP status/error code when exceeding it on check-allowances — cannot be answered from the site; the docs are silent on both, though the platform's one documented rate-limit response pattern (Agentify) is a 429.

The fix

Add a rate-limit statement for POST /v1/usage/check (and POST /v1/usage) to the 'Usage endpoint errors' section of docs.zeroclick.ai/resources/errors: the numeric limit (e.g. requests per minute per organization) and the exact 429 response body/error code — or state explicitly that the endpoint is not rate limited. Currently the only documented rate limit on the platform is Agentify's 60/min → 429, which doesn't cover the usage endpoints buyers will ask about.

Where we looked: /llms-full.txt, /resources/errors, /resources/errors

confidence medium · grounding synthesized · weight 0.65 · Vague

03If an agent's payment fails after I've already served the response, do I just eat the loss, or does ZeroClick offer any retry, guarantee, or dispute process?operationsHedges+2 pts est.

If an agent's payment fails after I've already served the response, do I just eat the loss, or does ZeroClick offer any retry, guarantee, or dispute process?

What the pages say

Mostly you are not left empty-handed, but there is no dispute process — recovery runs through your own retries plus ZeroClick's fallback settlement, and in the worst case you do bear the loss. Specifically: (1) A billing failure detected after your API already delivered a 2xx "does not become an error status. ZeroClick returns the delivered response and surfaces the failure in the `zc-usage-error` response header." (2) Retry exists, but it is yours to execute: "Retain the usage report as pending, with a deterministic idempotency key derived from the operation and meter. Retry with that same key" — ZeroClick's asynchronous usage endpoint treats a duplicate as an already-recorded event, and "The documented SDK path does not automatically retry these reports." (3) A partial guarantee: fallback settlement means "fixed quantities settle at the authorized amount, while an unreported ceiling settles at zero" even when usage headers are missing or malformed. (4) The eat-the-loss case is real: "A later usage report can be refused if the necessary access or balance is gone; keep that case in a reconciliation queue rather than retrying it indefinitely" — i.e., you bear it. No dispute, arbitration, or ZeroClick-side seller-recovery process is documented anywhere in the retrieved content.

The fix

The failure-handling guide and errors docs cover post-delivery billing failures well (zc-usage-error header, idempotency-keyed usage-report retries, fallback settlement, reconciliation queue), but never state whether sellers can dispute or escalate unrecoverable post-delivery billing failures (e.g., buyer balance drained after delivery). Add an explicit FAQ answer saying whether a dispute or seller-protection process exists.

Where we looked: /resources/handle-agent-purchase-failures, /resources/handle-agent-purchase-failures, /resources/errors, /faq

confidence high · grounding synthesized · weight 0.70 · Vague

04If settlement verification starts failing in production, what support channel do I use — email, Slack, Discord — and is there a response-time SLA on paid plans?supportPage missing+2 pts est.

If settlement verification starts failing in production, what support channel do I use — email, Slack, Discord — and is there a response-time SLA on paid plans?

What the pages say

Email is the only support channel ZeroClick documents: the docs site header lists "Support" as mailto:help@zeroclick.ai. No Slack or Discord channel appears anywhere in the retrieved content — the docs footer's only external links are the website, X (@zeroclick), and LinkedIn. For settlement failures specifically, the docs prescribe self-service handling rather than a support escalation: the `settlement_failed` 402 reason instructs that "The agent fixes its wallet and restarts for a fresh challenge," with no escalation path named. On the SLA question: no retrieved page mentions any response-time SLA or support-tier commitment on paid plans (or any plan tier), so no SLA could be confirmed from the site content.

The fix

Publish a dedicated support/contact page listing all available channels (email, plus Slack/Discord if they exist) and stating any response-time SLA per plan tier. Today the only support signal on the site is a mailto:help@zeroclick.ai link buried in the docs navigation, and no SLA is documented anywhere.

Where we looked: /concepts/payment-protocols, /resources/errors, /integrate/settle-usage

confidence medium · grounding synthesized · weight 0.65 · Page missing

05I already bill agents through my own API-key system — can I import those existing customers into ZeroClick, or do I have to re-register every store and meter from scratch?migrationHedges+2 pts est.

I already bill agents through my own API-key system — can I import those existing customers into ZeroClick, or do I have to re-register every store and meter from scratch?

What the pages say

Partly. On the 're-register from scratch' half: no — setup is assisted, not self-serve from scratch. The quickstart states 'ZeroClick configures your store, services, and plans with you during onboarding,' the FAQ notes self-serve signup isn't available today (the way in is booking a walkthrough), and the site says 'we will build your storefront with you.' ZeroClick also recommends you 'mirror your existing plans and adding a pay-as-you-go option, so agents and humans see the same prices' rather than rebuild pricing. On the 'import existing customers' half: the site never documents any customer-import or migration capability. Architecturally, none is needed for your current billing to keep working — the FAQ is explicit that 'Your existing authentication, plans, and billing stay as they are': your existing API-key customers keep calling your API directly with your keys on your terms, and only storefront agent traffic is billed through the billing guard (the agent pays, you report usage, revenue settles to your Stripe account; ZeroClick's 5% applies only to storefront revenue). But if you want those existing customers to also buy as agents through ZeroClick, or to carry their accounts/credit balances over, no page addresses it. The closest material is the stateful-seller integration for selling accounts/API keys, where accounts are created fresh at purchase time — ZeroClick calls your /zeroclick/access endpoint describing 'which customer, which plan, what period, and the total credit granted' and 'you create or update' the account — with no mention of linking pre-existing customers to that flow.

The fix

Add a dedicated FAQ/docs answer on migration: whether sellers can import or link existing API-key customers as ZeroClick buyers (e.g., mapping existing accounts to zc-buyer-id, carrying over credit balances or subscriptions), and clarify exactly what carries over during onboarding versus what must be re-created.

Where we looked: /faq, /quickstart.md, /faq, /integrate/stateful-sellers.md, zeroclick.ai

confidence medium · grounding synthesized · weight 0.65 · Vague

06Does 'charge up to a maximum' actually pre-authorize or hold funds upfront, or does it just cap the final settlement — and what happens if the agent's usage overshoots that max?technicalHedges+2 pts est.

Does 'charge up to a maximum' actually pre-authorize or hold funds upfront, or does it just cap the final settlement — and what happens if the agent's usage overshoots that max?

What the pages say

Yes — it genuinely pre-authorizes/holds funds upfront; it is not merely a cap on the final settlement. Ceiling-priced requests (usage declared with `maxQuantity`) are 'payable only on the reserve rails,' where the maximum is committed before work starts: on x402's `upto` scheme 'the wallet reserves the ceiling' and 'the reserved remainder never leaves the buyer's wallet'; on MPP session escrow 'the buyer funds a channel to the ceiling and signs one voucher,' ZeroClick closes the channel at actual usage, and the escrow refunds the rest (with a buyer force-close after an on-chain grace period if the close fails); on hosted card checkout the maximum is 'a manual-capture authorization on the Seller's account; only the actual amount is captured and the balance is released.' Settlement then happens at the actual reported usage — the FAQ's worked example: a meter at $0.002/1,000 output tokens with an 8,192-token ceiling 'authorizes at most $0.016384, and a 4,523-token response settles at $0.009046' — and 'a ceiling never overcharges.' If no reserve rail is available, ZeroClick returns `503 capped_pricing_unavailable` rather than falling back to post-hoc billing; on prepaid-credit plans the ceiling is gated against the remaining balance. On overshoot: the buyer cannot be charged more than the max — the docs state 'the settled quantity can be anywhere from zero up to the declared ceiling,' so settlement is hard-bounded at the authorized ceiling even if actual usage exceeds it, and the reserved/escrowed remainder is released. However, the docs do not specify the seller-side handling of a usage report above the ceiling — whether it is clamped to the max, rejected, or errors — or explicitly state who absorbs the overage; the zero-to-ceiling bound implies the seller can only bill up to the declared maximum.

The fix

Add an explicit subsection to the 'Charge up to a maximum' doc (and/or the FAQ) covering over-ceiling usage: whether a reported quantity above `maxQuantity` is clamped to the ceiling, rejected with a specific error code, or settled as-is, and state plainly that the seller absorbs any usage beyond the declared ceiling.

Where we looked: /faq, /concepts/payment-protocols, /legal/buyer-terms-of-service, /integrate/charge-up-to-a-maximum, /integrate/charge-up-to-a-maximum

confidence high · grounding synthesized · weight 0.70 · Vague

What the pages already answer cleanly

9 of 15. Answered with enough specificity for a buyer to act on. This is the bar the queue above is chasing.

integrationAnswered

Which payment protocols does ZeroClick support today — do agents pay with cards, crypto wallets, or something like x402, and do I need my own Stripe account on the seller side?

What the pages say

ZeroClick supports two agent payment protocols today — x402 and MPP (the Machine Payments Protocol) — plus card payments. It explicitly does not support ACP or UCP checkout today and publishes no dates for additional protocols. - Crypto wallets: yes. Agents pay in USDC from a wallet — x402 settles USDC on Base (eip155:8453), MPP settles USDC on Tempo. If an agent shows up without a wallet, ZeroClick can create one on the spot. - Cards: yes. Card payments arrive as shared payment tokens over MPP (scoped card credentials a buyer grants their agent with usage and expiration limits) or through a Stripe-hosted checkout page, with a $0.50 minimum per charge. - Sellers never implement a rail: ZeroClick issues the priced 402 challenge, verifies the payment, and forwards a signed, already-paid request; nothing protocol-specific reaches your backend, so when ZeroClick adds a protocol you ship nothing. An unpaid request gets one 402 offering both protocols and the buyer picks by paying; which rails your storefront can offer depends on the country where your business is legally established, and one available rail is enough to go live. - Stripe on the seller side: no pre-existing Stripe account is required. You add your bank account during Stripe onboarding (part of ZeroClick setup), revenue settles there in fiat, and you never run a crypto wallet yourself.

Source: /faq, /faq, /faq, /faq, /faq, zeroclick.ai, /concepts/payment-protocols.md

confidence high · grounding synthesized · weight 0.95 · Answered

pricingAnswered

What does ZeroClick actually cost me — is it a monthly platform fee, a cut of each transaction, or both, and where do I find the exact numbers?

What the pages say

It's a transaction cut, not a monthly platform fee — and not both. The FAQ states the full model: "ZeroClick charges a $0 setup fee, no monthly platform fee, and 5% of agent-transaction revenue that runs through your ZeroClick storefront, month to month with 30 days' notice," with no minimum commitment, so "you pay nothing until agents buy from you." The 5% applies only to purchases made through your ZeroClick storefront — revenue from your existing channels is untouched, and there is no exclusivity. Mechanically, the fee is not deducted from each payment: agent payments settle to your connected Stripe account in full, and ZeroClick invoices the 5% monthly against the agent-transaction volume tracked in your dashboard, so you can reconcile it against your own Stripe records. Where to find the exact numbers: (1) the FAQ answer "How much does ZeroClick cost?" at https://zeroclick.ai/faq#how-much-does-zeroclick-cost states the 5% explicitly (repeated on the homepage and in the setup-fee answer); (2) contractually, Terms of Service §3.1 says the Rev-Share is "the percentage stated in the Order Form" of transaction revenue through the ZeroClick Payment Gateway, and the FAQ notes the terms are "set out in a short agreement signed during onboarding" — so the Order Form you sign is the authoritative place for your specific numbers. One nuance: ToS §3.1 also references an "Implementation Fee" set in the Order Form (due within 30 days unless otherwise agreed); the FAQ says the setup fee is $0, so the Order Form should be checked to confirm it records $0.

Source: /faq, /faq, zeroclick.ai, /faq, /legal/terms-of-service/2026-07-01

confidence high · grounding synthesized · weight 0.95 · Answered

securityAnswered

Can API keys be scoped per store or per environment — sandbox versus production — and how do I rotate a key without breaking live agent traffic?

What the pages say

Scoping: No — ZeroClick API keys are not scoped per store or per environment. The API docs state 'Every key is scoped to your organization and carries one or more scopes,' and the complete scope list is functional only: admin:read, admin:write, usage:read, usage:write, agentify:convert. There is no sandbox-only or production-only key: the route-group rules say Sandbox endpoints 'accept an API key (admin:read for reads, admin:write for writes)' — the same admin keys that touch production catalog resources. Keys are minted under your store's Implementation tab (or Settings), but their scope is organization-wide; where one organization has several sellers, you disambiguate per request (e.g., Agentify's seller=sel_… parameter) rather than with a store-scoped key. Scoping is per-capability — e.g., an Agentify key with only agentify:convert 'grants GET /v1/agentify/markdown and nothing else.' Also note API keys cannot manage keys: creation/revocation happens in the dashboard in a signed-in session only ('API keys cannot create or revoke API keys'). Rotation without breaking live agent traffic: Yes — rotation is an overlap, not a cutover. For the signing secret that verifies live forwarded agent traffic, the documented procedure is three steps: (1) create the new secret in the dashboard — ZeroClick immediately starts signing new requests with it and the signature's kid changes to the new secret's id; (2) hold both kids in your SDK configuration (the signingSecrets map) so 'requests signed with either secret verify while both are configured'; (3) once requests signed with the old secret can no longer be in flight — verification rejects signatures older than the 300-second tolerance, so a few minutes of overlap suffices — revoke the old secret in the dashboard and drop its kid. The FAQ confirms 'secrets rotate with an overlap rather than a cutover.' If you sell accounts/API keys to agents, buyer-key rotation uses remintPolicy: 'rotating' — 'revoke live keys and insert the new hash in one transaction' with maxKeys 1, so a retry can't leave a buyer with two live keys or none. Caveat: the retrieved step-by-step covers the signing secret; rotation of the usage API keys (zc_) is referenced ('See keys and secrets for scopes, rotation') but its detailed steps are not in the retrieved content.

Source: /api-reference/introduction.md, /integrate/keys-and-secrets, /faq, /faq, /agentify/overview, /quickstart.md, /llms-full.txt, /llms-full.txt

confidence high · grounding synthesized · weight 0.95 · Answered

fitAnswered

Can I sell recurring subscriptions or pre-paid plans to agents through ZeroClick, or is it strictly pay-per-request micropayments?

What the pages say

No, ZeroClick is not strictly pay-per-request. The FAQ states: "ZeroClick supports five billing modes for AI agents: pay as you go (a fixed price per call, no purchase), prepaid credits, a subscription (monthly or yearly), a subscription plus metered usage, and a one-time free trial." So you can sell recurring subscriptions (monthly or yearly, with a subscription-plus-usage variant that includes credit) and prepaid credit bundles — the FAQ even says "Prepaid credit bundles are usually the better fit for agents, alongside pay as you go," and recommends mirroring your existing plans and adding a pay-as-you-go option. Two nuances: (1) If you want the subscription or credit purchase to create something lasting on your side (an account, API key, or credit balance the buyer's agents recover later), that uses the separate "stateful seller" integration — you expose one HTTPS endpoint (default /zeroclick/access) that provisions the account and mints a key, and it "works with subscription, subscription-plus-usage, credit, and free trial plans, but not pay-as-you-go." Renewals and top-ups update the account the first purchase created. Account selling is a storefront-level designation arranged during onboarding via help@zeroclick.ai. (2) Subscriptions and credits work as billing modes on any storefront; only the account/key-provisioning part needs the stateful setup.

Source: /faq, /faq, /faq, /faq, /faq

confidence high · grounding synthesized · weight 0.95 · Answered

integrationAnswered

I'm behind Cloudflare with bot protection on — which IPs, user agents, or headers do I need to allowlist so legitimate agent traffic isn't blocked?

What the pages say

Allowlist neither IPs nor user agents — key the exemption on the `zc-signature` header. ZeroClick publishes no fixed egress range (its forwards come from shared cloud addresses that can change without notice), and it passes the buyer's own `User-Agent` through unchanged, so there is no ZeroClick UA or IP range to allow. `zc-signature` is present on every forward (paid retries, anonymous probes, catalog probes, and account endpoint calls), and ZeroClick strips inbound `zc-*` headers, so only ZeroClick sets it on requests arriving through the pay URL. Cloudflare recipe (from the docs' Cloudflare tab): create a WAF custom rule with the **Skip** action, placed above any rule that challenges, with the expression `any(http.request.headers.names[*] == "zc-signature") and starts_with(http.request.uri.path, "/api/")` — scope the path prefix to the paths ZeroClick calls (your catalog endpoint paths, plus `/zeroclick/access` if you sell accounts). Under **Then**, choose Skip and select **All Super Bot Fight Mode rules**; also select **Browser Integrity Check** if the zone has it enabled, and **All remaining custom rules** if you have challenge rules of your own below this one. Two Cloudflare caveats: (1) Bot Fight Mode on the Free plan cannot be skipped by a Skip rule — turn it off under Security > Settings (filtered to Bot traffic) or move to a plan with Super Bot Fight Mode; (2) Under Attack mode challenges every visitor — scope it with a Configuration Rule that sets a lower Security Level on the paths ZeroClick calls. Keep the billing guard as the gate: it still verifies every `zc-signature`, so the exemption doesn't open those paths to anyone else. A layer that can only allow by IP address cannot exempt ZeroClick — take the challenge off the API paths instead.

Source: /faq, /integrate/firewalls-and-bot-protection.md, /integrate/firewalls-and-bot-protection, /integrate/firewalls-and-bot-protection, /integrate/overview, /resources/headers.md

confidence high · grounding synthesized · weight 0.95 · Answered

integrationAnswered

Which languages do you ship official SDKs for, and if mine isn't listed, is the raw REST API fully usable on its own?

What the pages say

Yes to both parts. Official SDKs: ZeroClick ships official seller SDKs for four languages — TypeScript (`@zeroclickai/sellers` via pnpm, ESM, runs on current Node.js and edge runtimes), Python (`zeroclick-sellers` via pip, Python 3.10+, sync and async clients with ASGI/WSGI adapters), Go (`cdn.zeroclick.io/sdks/sellers-go`, Go 1.24+, drop-in net/http middleware), and Ruby (`zeroclick-sellers` gem, Ruby 3.1+, Rack middleware covering Rails, Sinatra, Hanami, Roda). All four are Apache-2.0 licensed and 'speak the same wire protocol and make the same decisions; they differ only in language idiom.' PHP is explicitly NOT official: it is covered only by a community SDK (`affiliatecom/zeroclick-sdk-sellers-php`, Apache-2.0, maintained by affiliatecom) which the docs state is 'built and maintained by the community, not by ZeroClick' — though ZeroClick ran its 29 shared signing conformance vectors against it and all 29 agreed on signature verification. If your language isn't listed, the raw REST API is fully usable on its own: the REST walkthrough says you can 'Implement the ZeroClick seller contract with plain HTTP in any language: verify the signature, check the allowance, serve, and settle usage,' and that 'the contract is small enough to implement directly: verify one request header, call one HTTPS endpoint before the work, and settle usage after it' — the page walks the whole contract using your language's standard library and curl, implementing 'the same contract' as the SDKs.

Source: /sdks/overview, /sdks/overview.md, /sdks/overview, /sdks/overview, /integrate/rest-walkthrough

confidence high · grounding synthesized · weight 0.95 · Answered

securityAnswered

What signing algorithm does the request-verification signature spec use, and what's the timestamp tolerance before a request is rejected as a replay?

What the pages say

The signature spec uses HMAC-SHA256: "The signature is `HMAC-SHA256(secret, canonical string)`, lowercase hex, with the secret and canonical string both UTF-8 encoded" (the secret is the one whose id equals the header's `kid`). The timestamp tolerance is 300 seconds by default, applied in both directions: "Parse `t` as an integer. If `|now − t|` exceeds the tolerance (300 seconds by default, applied in both directions) → `stale_timestamp`." The verify-requests page confirms: "Reject timestamps outside the clock tolerance: 300 seconds by default, in either direction." The stateful-access reference describes the same tolerance as rejecting a `t=` "more than 5 minutes old or in the future," and its worked verifiers hard-code `TOLERANCE_SECONDS = 300`.

Source: /integrate/signature-spec, /integrate/verify-requests, /integrate/signature-spec.md

confidence high · grounding stated · weight 1.00 · Answered

technicalAnswered

For stateful sellers, how is an agent's identity carried across requests — which header holds it, and does an in-flight session survive if I rotate my keys mid-session?

What the pages say

Identity header: on stateful sellers' access endpoints (and on every forwarded request), the agent is identified by the `zc-agent-id` header, e.g. `agt_x7f2kq93bh0d`. The stateful access reference defines it as 'The agent making this call — different calls to one account may carry different values. Sent again as `zc-anonymous-id` with the same value.' It is stable per registered credential and is the id ZeroClick tells you to key per-caller state on (rate limits, tenancy, audit logs). Once the credential is claimed, `zc-buyer-id` (`byr_…`) arrives alongside, plus `zc-buyer-email` on account writes when the plan's verified-email policy is `requested`/`required`. `zc-signature` covers `zc-agent-id` but not the buyer headers — they mirror signed body fields, and the SDK rejects disagreements with `400 buyer_mismatch` / `400 buyer_email_mismatch`. Key rotation mid-session: yes, continuity is designed in at two levels. (1) Your signing secret: the stateful-sellers go-live checklist says 'Look up secrets by `kid` and keep the previous one through a rotation' and lists 'a signing-secret rotation' as a required test — so requests in flight signed with the old secret keep verifying while you rotate. (2) The agent's credential/key: entitlements live on the buyer, and 'zc-buyer-id stays stable across every agent the same human holds, so a replacement credential still inherits the buyer's plans'; on the account side, 'minting a key looks like a new `agentId` value against a familiar `accessId`: expected, not suspicious,' the account and its minted key persist, and 'redeeming again replaces a lost key.' Your handler must 'make rotation revoke-and-insert atomic' and key accounts on `accessId` (`zacc_` prefix), since one account can see several agent ids. Note that identity is carried per request via headers, not as a server-side session object, so nothing in-flight depends on a session that rotation could invalidate.

Source: /resources/stateful-access-reference, /concepts/agents-and-access, /concepts/agents-and-access.md, /faq, /faq, /integrate/stateful-sellers.md, /faq

confidence high · grounding synthesized · weight 0.95 · Answered

limitsAnswered

What am I allowed to serve on the free and identity endpoints without a paid allowance, and is there a per-agent request cap before I'm required to start charging?

What the pages say

Yes — ZeroClick's docs split 'free' into two kinds, and neither carries a platform-imposed per-agent request cap. **1. Identity endpoints (guardIdentity) — what you may serve for free:** The docs say these are endpoints that 'cost nothing but still must know who is asking': 'polling a job the buyer created, reading account limits, any read or write served only to the buyer that owns the underlying records.' The identity guard 'verifies the signature exactly like guard, requires a registered agent credential, and makes no allowance call' — a verified request with zc-agent-id is allowed 'with allowance status not_required', and no zc-usage settlement belongs on the response ('There is nothing to settle. Free means free.'). A failed signature is the usual 401; a verified request without a buyer is denied with reason identity_required and a 401 bearer_required pointing to the registration recipe. The identity guard alone does not require a human claim or verified email, and 'No payment is involved.' **2. Included free units (zc-mode: free):** Separately, a plan's meter price can carry includedUnits — 'free units per period before the price applies' — which you configure in your own catalog. The buyer opts in per call with the zc-mode: free header; coverage is served only to agents 'claimed by a human with a verified email', and it is scoped per buyer, not per agent: 'consumption aggregates across every agent the same human owns, so claiming more agents never grants more free usage.' Pay-as-you-go included units 'do not reset on a schedule' — ZeroClick explicitly tells you to 'use your own counters for daily or monthly application quotas.' **Per-agent request cap:** There is no ZeroClick-imposed per-agent cap before charging applies. The only free-usage ceiling is the includedUnits allowance you configure, and it is per buyer rather than per agent; once drawn down, the allowance check denies with reasons like usage_exhausted and the call becomes a payment prompt. Throttling or refusing individual agents 'is your application's decision', keyed on the verified zc-agent-id every forwarded request carries.

Source: /integrate/free-and-identity-endpoints, /integrate/free-and-identity-endpoints, /integrate/free-and-identity-endpoints, /integrate/free-and-identity-endpoints, /concepts/usage-and-allowances, /faq

confidence high · grounding synthesized · weight 0.95 · Answered

Protocol plumbing · 63/10010 of 16 checks pass · each fix +6 protocol pts est.

The other half of the score: 16 checks for the files and headers agents look for. The 6 below are installs, not judgment calls, and most are an afternoon. Expand any for the snippet and the standard it follows. They sit after the queue because none of them changes what your pages say.

Content signalAccess+6 pts est.

Install snippet

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

StandardCloudflare proposalVendor proposal

MCP cardInteraction+6 pts est.

Sitedex generates this file from your crawl. Grab it in Files from this audit below.

StandardModel Context ProtocolCommunity spec

OpenAPI specInteraction+6 pts est.

StandardOpenAPI SpecIndustry standard

WebMCP widgetInteraction+6 pts est.

Sitedex generates this file from your crawl. Grab it in Files from this audit below.

StandardW3C WebMCP draftW3C / WHATWG

Meta descriptionsHygiene+6 pts est.

Install snippet

<meta name="description" content="zeroclick.ai: [outcome you deliver] for [who you help]. One sentence, 50-160 characters." />

StandardHTML Living StandardW3C / WHATWG

Sitemap lastmodDiscoverability+6 pts est.

Standardsitemaps.orgIndustry standard

Already passing 10 of 16: robots.txt, sitemap.xml, llms.txt, AI crawler access, Clean crawl, Markdown negotiation, Server-rendered content, Canonical URLs, HTML lang attribute, Organization schema.

Ask this site’s index

Sitedex already serves zeroclick.ai as an MCP endpoint. Ask zeroclick.ai anything an AI agent might ask, and see what its index returns. (To score your own site, use the form below.)

Snippets & configs

For developers and the engineer-on-call: copy these into your tools or your site.

Files from this audit

Built from this crawl. Download or copy each, then install it at the path noted.

llms.txt

Built from this crawl. Install at /llms.txt so agents start here.

organization.json

Organization JSON-LD, pre-filled from this crawl. Wrap in a ld+json script.

server-card.json

MCP server card built from this crawl. Host at /.well-known/mcp/server-card.json.

webmcp.json

WebMCP discovery manifest built from this crawl. Host at /.well-known/webmcp.json.

MCP endpoint

https://mcp.sitedex.dev/s/zeroclick-ai/mcp

The URL anyone's agent points at. Read-only; safe to share.

Claude Code

claude mcp add zeroclick --transport http https://mcp.sitedex.dev/s/zeroclick-ai/mcp

One command, then the agent has it.

Cursor / Continue

{
  "mcpServers": {
    "zeroclick": {
      "url": "https://mcp.sitedex.dev/s/zeroclick-ai/mcp"
    }
  }
}

Drop into mcp.json.

WebMCP: two parts

WebMCP-capable browsers run the widget at runtime. Crawlers without JS rendering need the discovery manifest to find your tool surface. Install both.

1 · Widget script

<script async src="https://sitedex.dev/widget.js"></script>

Drop in <head>. In browsers with WebMCP, this script registers your site's tools with navigator.modelContext.registerTool().

2 · Discovery manifest

{
  "schema_version": "2026-04",
  "name": "ZeroClick",
  "description": "ZeroClick enables businesses to sell their products or services to AI agents. WebMCP tools served by Sitedex.",
  "homepage": "https://zeroclick.ai",
  "documentation": "https://app.sitedex.dev/sites/zeroclick.ai",
  "source": "navigator.modelContext",
  "tools": [
    {
      "name": "search_site_content",
      "description": "Ask about this site in plain language and get the most relevant passages from its pages, each with the source URL and a relevance score. Searches the site's published text, not live inventory or accounts."
    },
    {
      "name": "get_site_info",
      "description": "This site's profile: name, description, category, who it is for, page count, and AI Visibility Score. Use it to learn what the site is before you search it."
    },
    {
      "name": "list_site_pages",
      "description": "The pages indexed on this site, with title, URL, and path. Use it to see what the site covers, or to find the path to pass to get_site_page."
    },
    {
      "name": "get_site_page",
      "description": "The full markdown of one page on this site, by path. Use it after search_site_content points you at a page and you want all of it."
    }
  ]
}

Host alongside the script at /.well-known/webmcp.json. Crawlers that don't render JS rely on this.

Your turn

See which of these questions your site goes silent on.

Free, about 5 minutes. We crawl your site, test it against the buyer questions your category asks, and name what’s vague, contradictory, or missing, plus the files AI agents look for.

ComingEmbeddable grade badgeScore history and deltasOpt-in public board