For AI Agents · Trust
Can an agent trust this data?
That question gets decided once, by a human, before an agent is given a wallet. This page is the answer in the form an operator can act on: what the numbers mean, how fresh they are, where they come from, what happens when a payment goes wrong, and what Harpd explicitly does not claim.
Methodology
Every number Harpd sells is produced by a published rule, and the rule ships with the answer. Rank ordering, movement calculation, the 100-entry public limit and the tie-break chain are all documented, and each paid response repeats its own methodology URL in meta.methodology so a citation never depends on this page still saying the same thing.
Data freshness and update frequency
Rank-derived answers are computed at request time from the live board, not read from a nightly dump. Model pricing is a registry last verified against official provider pages on the date in meta.updated_at and in the pricing manifest. Every response carries meta.updated_at, so an agent can enforce its own staleness policy rather than trusting a blanket claim.
Provenance
Answers are derived from the published Harpd datasets: the product catalog, the Rank board, the model pricing registry and the research snapshots. meta.dataset names the exact dataset, meta.canonical names the citable page, and each research finding carries its own evidence line and source URL. Nothing in a paid response is generated by a language model.
API versioning
The agent API is versioned in the path (/api/agent/v1/) and in the response envelope (meta.version). Adding a field is not a breaking change; removing or repurposing one bumps the envelope version. The published OpenAPI contract is generated from the same catalog the Worker enforces, so the contract cannot advertise an endpoint or price the API does not serve.
Uptime and failure behaviour
The API is served from Cloudflare Workers on api.harpd.com. Health and payment-rail status are published at /v1/payments/health. Failures are fail-closed and explicit: an unconfigured or unreachable facilitator returns 503 with a named error code rather than silently serving data unpaid, and a payment that verifies but whose fulfilment fails is recorded and visible in the failure-rate metric.
Pricing
Prices are fixed, per request, and published in three places that are generated from one object: the pricing manifest, the OpenAPI contract, and the HTTP 402 challenge. There is no metered overage, no minimum commitment and no hidden tier. A variable-price product (dataset query) quotes the exact amount for that request in its 402 challenge before anything is signed.
Payment protocol
Paid resources settle in USDC on Base using x402, the HTTP 402 Payment Required standard. Harpd is non-custodial: the agent signs with its own wallet, a facilitator verifies and settles, and Harpd never receives, stores or logs a private key, seed phrase or payment signature. Settlement goes directly to the published treasury address, which is printed in the pricing manifest so a payer can verify the recipient before signing.
Privacy and retention
Payer identity is stored as a SHA-256 hash of the wallet address, never the address itself — in the database and in logs alike. It is kept only to enforce daily spend limits and to count repeat payers. Harpd does not store IP addresses, user agents, or the free-text body of a request. No personal data is required to use the API, because no account exists to attach it to.
Rate limits and spend limits
Rate limiting is per caller at 120 requests per minute by default, applied to free and paid endpoints alike so a free endpoint cannot be used to exhaust capacity. Spend control is separate and enforced per payer wallet: a per-request ceiling (1 USDC by default) and a daily ceiling (10 USDC by default). The live values are published in the capability manifest rather than hard-coded in documentation.
Disputes and refunds
A settled on-chain payment is not reversible, so Harpd handles disputes by correction rather than by reversal. If a paid request settles and the response is an error or an empty payload, that request is recorded with the failure status and the settlement receipt; contact support with the request_id from meta and the receipt hash and Harpd will either re-serve the answer or refund the amount to the paying wallet. Replay of an already-consumed payment returns HTTP 409 and is never charged twice.
What Harpd does not claim
Rank Points measure promotional ranking activity on the Harpd board. They are not an editorial rating, review or recommendation, and a higher position does not mean a better product. Model cost optimisation returns list-price arithmetic against a heuristic task profile: it is not a quote, and quality is inferred from capability tier rather than measured on the buyer's own task. Research answers are deterministic retrieval over the published catalog, not an opinion. Coverage is limited to products Harpd has published, so absence from a result is not evidence that something does not exist.
Verify it yourself
Every claim above resolves to a machine-readable endpoint. An operator can check the contract, the price, the recipient address and the health of the payment rail before a wallet is ever connected:
curl https://harpd.com/.well-known/harpd-agent.json curl https://api.harpd.com/api/agent/v1/pricing curl https://api.harpd.com/v1/payments/config curl https://api.harpd.com/v1/payments/health curl https://harpd.com/developers/agents/openapi.json