How verification works

Listings enter the catalog as pending review. Nothing self-publishes. A listing goes live only through a moderator approval that records who approved it and when, and stamps the listing’s verification date. IntelClaw operates the catalog.

When a live listing is edited, sensitive changes send it back to review before it can serve paid traffic again. When a listing is sent back, suspended or archived, the moderator must write a reason, and that note is stored with the listing.

Once live, scheduled health checks probe the listing’s origin every 6 hours. A passing origin check re-stamps the verification date. A newly approved listing shows its approval date until its first scheduled origin check runs.

Verification is a timestamp, not a permanent badge. A passing origin check, or a moderator approval, stores a last verified date. Cards show that date when it exists (“verified 2h ago”), and the listing page and the agent index show the full date. A listing with neither has no freshness stamp.

Health checks run every 6 hours. They probe the listing’s live origin when one is configured, and the hosted sample otherwise. Each run records pass or fail, HTTP status and latency. Listing pages show the ten most recent checks, and status shows the latest one for every live listing. The uptime figure comes only from origin probes. A sample probe does not create or change an uptime number.

If a listing goes stale, its age shows. We don’t hide it, and we don’t re-stamp a listing without a passing origin check or a moderator approval.

Every review is tied to a purchase. To leave one, you sign in with an account that has an active subscription to that listing, or a past paid call to it.

One review per buyer per listing. The database enforces it, so a single purchase can’t be padded into many reviews.

Ratings and review counts on listing cards and in structured data are aggregated from the reviews themselves. We don’t seed, fabricate or round them up.

Billed monthly by Polar, our merchant of record. Cancel anytime from your dashboard. Polar handles checkout, tax and card data; IntelClaw never sees or stores card details. When Polar confirms a payment, your account gets access to that listing and your API keys unlock it.

A paid call without a key returns HTTP 401. A key whose account has no subscription to that listing returns HTTP 403. To ask for a refund, contact support. Polar issues approved refunds, and access to that listing ends when the refund goes through.

Every paid call is logged. Paid-use counters and review eligibility come from those logs, not from self-reported activity.

Every listing carries a machine-readable terms block inside its discovery response (GET /api/v1/resources/{slug}?discovery=1, field terms). It is derived from that listing's live row plus the terms and privacy pages, never written by hand per listing:

• allowedUse: which credential unlocks the paid endpoint, where the free sample and discovery responses live, and whether the listing currently serves a labeled sample instead of live data.
• retention: how long platform rows live. Transaction rows are kept as required for refunds and fraud prevention; health checks are pruned after 90 days; funnel events after 180 days; for API keys we store only the hash.
• pii: delivery outcomes are logged, not unrelated origin-side personal data; card data is never stored.
• payments: the listing's monthly price, the refund policy, and the operator (IntelClaw).

The block is recomputed from the live row on every discovery call, so it cannot go stale in storage.

• Verification is operational evidence (moderation, health checks, purchase-backed reviews), not an audit of the data’s accuracy.
• A purchase-backed review proves the reviewer paid for that listing. It doesn’t make their opinion fact.
• We don’t publish usage numbers we can’t trace to real transactions. Counters on the site come from logged paid calls.
• Refunds are not automatic. See the pricing FAQ.