LenzIndependent, multi-model fact-checking API for AI workflows
Promoted
ZooData
The data layer for AI agents
833 followers
The data layer for AI agents
833 followers
ZooData turns any URL into agent-ready JSON, so AI agents can work with structured data instead of raw HTML or bloated markdown. Use ~75% fewer LLM tokens, pay only for the fields you use, and skip extra extraction credits.Beyond extraction, ZooData gives agents pre-analyzed e-commerce intelligence — competitor, market, traffic, and consumer insights — live for Amazon and TikTok. API, CLI, and MCP server included. Start with 1,000 free credits, no card required.
curious how this holds up against anti-bot layers - a lot of the messiest sites to scrape aren't messy because of markup, they're messy because they actively try to block automated requests. does the per-field pricing still apply if a site just serves you a captcha wall instead of html, or is that a separate failure case
ZooData
@omri_ben_shoham1 Fair question, straight answer: a captcha wall / block = a failure case, not billed — credits are only consumed when a call successfully returns data, and the status code in the response is the upstream's real one, so a block is never disguised as a success. The anti-bot arms race is our infrastructure's job (rendering, retries, network diversity), but we won't claim 100% — throw your nastiest site at it; if it fails, it costs you nothing.
the field-level trust discussion above is the real meat of this thread. one I didn't see covered: what happens on a listing/search-results page that needs pagination or infinite scroll to surface everything - does a single call return just what's in the initial DOM, or does ZooData drive the scroll/pagination itself to assemble the full result set before handing back JSON?
ZooData
@galdayan One call = one rendered page-view — we deliberately don't drive scroll/pagination behind a flat price (that's a cost black box, against everything in this thread). For full result sets: infinite scroll → the interactive variant (you pass explicit scroll/click/wait actions, hard-capped cumulative time, bounded cost); classic pagination → your agent loops over page URLs, flat price each, linear spend. Your agent owns the depth decision; we keep each unit deterministic.
@kyle_dong That's a clean split - keeps the flat-price unit honest instead of hiding variable cost inside it. Makes sense that the agent should own the depth decision rather than you guessing at it server-side. Good answer, thanks for walking through both paths.
ZooData
@galdayan Thanks! You summed it up better than we did: primitives stay honest, orchestration belongs to the agent. We keep the first half true — the second half is your stage. Come back and show us what you build with it.
@kyle_dong will do, bookmarking this one to try once I've got a real scrape target to point it at.
@Kyle Dong that's the right answer honestly, "we don't disguise a block as a success" is the thing that actually matters, most tools I've tried just eat the failure silently and you don't find out until your data looks wrong three steps downstream. does the response include which failure mode it hit, like captcha vs rate limit vs structure change, or is it just a generic fail code?
ZooData
@omri_ben_shoham1 Finer than a generic fail code — but honestly, not a full forensic report either. The design is neutral classified codes + real status codes:
- Blocked / access denied (captcha walls fall here) → an access-denied class error, with the target's real HTTP status in meta.statusCode — never one we made up;
- Rate limiting on our side → you get an explicit 429 with X-RateLimit headers before any work runs — and nothing ran, so nothing's billed;
- Structure change → that one's actually not an error: the page is still there and readable, so markdown comes back as normal — only the structured json goes absent or degraded. You get an honest less, never a silent wrong. Which loops right back into the field-trust discussion above.
As for why we don't put finer anti-bot attribution (exactly whose wall, which signal) in the response: two reasons. One, those internal signals change shape and name — letting you integrate against them is handing you a landmine. Two, frankly, precise block-detection details published in an API mostly benefit the wrong audience. We watch the full attribution on our internal dashboards — its job is for us to go fix things, not for you to triage.
What your agent actually needs collapses to three lanes: retryable (transient upstream) / don't-retry (access refused) / content-ok-but-structure-degraded. All three are distinguishable from the response.
Structured input is a better foundation for agents than making the model repeatedly interpret noisy pages. How do you preserve context that doesn’t fit neatly into the extracted schema but might become important to the agent later?
ZooData
@amir_mehrabi Great question — and it's exactly why formats are composable on our side. A single call can return json and markdown together (add rawHtml if you want full fidelity): json is for acting now, markdown is for "might matter later." The markdown is a page-faithful rendering of the full content — the long tail the schema didn't catch (a footnote, a promo clause, some odd badge) is still in there, not thrown away.
The agent pattern we see looks like this: act on the fields immediately; stash the markdown cheaply outside the context window (it's just text); and the day a decision actually needs the long tail, feed that one page back to the model to read once. That's the full meaning of "structured-first" — not structure-only, but turning the model's prose-interpretation from "re-read on every hop" into "read once, on demand." What we eliminate is repeated interpretation, not information.
And a footnote: requesting an extra format in the same call doesn't change the price — one call, one price. Keeping that "might matter later" escape hatch costs you nothing at the margin.
neat framing, agent-ready JSON instead of raw markdown. when a site restructures its page layout, does the schema auto-remap to catch the drift or does it silently break until someone notices the fields are empty?
ZooData
@sabber_ahamed Neither 😄 The real answer: detected on the spot, degraded honestly, re-learned automatically. Every extraction passes core-field validation — the moment a redesign breaks structure, validation fails and the result is never stamped success; unreadable fields are absent (absence ≡ not extracted), never invented. The structure then re-learns the new layout — first pass slower, speed recovers, self-healing with zero action from you. And every drift trigger lands with attribution on our dashboards — "noticing" is our job, not your downstream data's.
the daily-cycle vs no-cache split for analytics vs realtime endpoints is smart, most tools pretend everything's live. does JS-heavy SPA rendering get priced the same as static pages or does that heavier compute cost more per call?
ZooData
@sabber_ahamed Same price. The pricing axis is what you take away, not what compute we burn. One scrape, one price — whether that was a featherweight static page or a heavyweight SPA needing a full browser session never appears on your bill. Rendering weight is our cost problem, same direction as the thrash cost discussed above: it hits our margin, not your credits.
Why we're firm on this: with weight-tiered pricing, you can't know which tier a URL lands in before you call it — that's decided by the target site's tech stack, which you neither control nor observe. An agent's spend already carries one naturally floating term (LLM tokens); the data layer doesn't need to add another. A flat unit price leaves this part of your spend with exactly one variable: call count.
One honest footnote: heavier pages are slower (render time is real), just not more expensive. Latency floats; price doesn't.
The ~75% token reduction claim is the headline, but paying only for fields you use is the sharper idea — most extraction APIs bill you for the whole page whether you need it or not. Curious about freshness on the pre-analyzed e-commerce intelligence: is the Amazon/TikTok data pulled live per request, or on a crawl cadence?
ZooData
@nitish_garg4 On freshness, the answer is clean: two endpoint families, two cadences, explicitly split — never dressed up as one.
- The analytics layer (product/market search, keywords, review analysis — built on a large historical corpus) refreshes on a daily cycle. Those questions are fundamentally "what has this market been doing" — daily is the honest granularity, and dressing it up as "live" is the pretending the industry usually does.
- The realtime layer (realtime product/review endpoints) does live on-demand collection per request, no cache — you get the page's displayed state at that moment.
Our stance: freshness is a labeled property of each endpoint, not a marketing word. Pick by the question: market trends → analytics (fast, cheap, daily); "what does this product page say right now" → realtime (fetched on the spot).
One small aside so the meme doesn't spread: billing is actually a flat price per call, not a per-field meter — the "pay only for what you need" part is real, but it lives in responses carrying only meaningful fields, i.e. savings on your downstream LLM tokens. That's where the real money is.