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.
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.
@Kyle Dong ok I'll take you up on that. what about a batch fetch where some records come back clean and others fail or get flagged as degraded within the same call - does that collapse into one of the three lanes for the whole response, or does the agent get a per-record breakdown? that feels like a fourth shape (partial success) rather than a branch of the other three
ZooData
@omri_ben_shoham1 Someone took the challenge — welcome 😄 The public-surface reality first, then the shape we believe in:
Today's batch-like surface on the public API is search deep-scrape (one search, each result page fetched individually). Its behavior: every result is processed independently, and failures never contaminate successes — but honestly: failed records are dropped, not returned as error entries. We over-fetch candidates beyond your limit to backfill, so you usually still get your full count, and billing counts only returned records — failures cost nothing. Summary: what you receive is clean, what failed is traceless and free — but no, it's not a per-record error report.
A batch endpoint where you submit a list of IDs doesn't exist on the public API today. And the shape you describe — per-record {id, data | error} with succeeded/failed counts on top, never a whole-call collapse — is exactly the batch contract we believe in: partial success as a fourth shape, with the three lanes pushed down to the record level and the envelope doing bookkeeping. You've articulated that envelope well — noted.
The 75% token reduction number is impressive - is that mostly from stripping HTML/markdown noise, or are you also doing semantic compression on the fields themselves? Also curious how you handle sites that change their DOM structure often.
ZooData
@max_tolmachov Good question — and the answer contains a deliberate trade: the 75% comes from selection, not compression.
The cut happens in two places: first, page noise never gets in — navs, footers, cookie banners, recommendation blocks, the six variants of the same title all stay outside the structure; second, empty slots are dropped — a meaningless field never costs you a token. But the field values that survive are the page's own text, verbatim — we deliberately do no semantic compression or paraphrasing, because a paraphrase is an interpretation layer, and interpretation is exactly where errors sneak in. Verbatim also buys you something: every value stays reviewable against the page. In one line: aggressive about what to include, conservative about rewriting anything.
On sites that churn their DOM: every extraction passes that page type's core-field validation — when the structure shifts, validation fails on the spot, and the result is a loud degradation (absent fields, unbilled failure), never quietly invented values. The learned structure then re-learns the new layout: first pass slower, speed recovers, self-healing with zero action from you. Drift triggers are monitored with attribution on our side — noticing is our job, not your downstream data's.
@ninghu The structured JSON approach makes a lot of sense. Agents don't really need more text — they need reliable facts they can act on.
I think data freshness and confidence scoring will become just as important as extraction itself. A wrong field can be more dangerous than a missing field.
Curious how ZooData approaches detecting when extracted data becomes outdated over time, especially for fast-changing e-commerce data like prices, rankings, and reviews?
ZooData
@zhixingai Great question — and I fully agree with the framing: a wrong field is worse than a missing one.
Our answer today is architectural rather than a magic staleness detector. We split data by how fast it decays. Slower-moving signals — review stats, market structure, category-level data — come from our tracked dataset, refreshed on a daily cadence.
Fast-decaying fields like price and rank are exactly where any stored snapshot lies to you, so for those we expose realtime endpoints: on-demand collection at request time, meaning the agent refreshes the observation instead of trusting a stored one. The two years of history is the third piece — it lets an agent see how volatile a specific field has been for a specific product, which is often the best staleness signal there is.
On confidence scoring: strongly agree — that's where this whole category is headed, and it's an active discussion on our side. Curious about your use case: would a per-field observation timestamp or a baked-in confidence score be more useful to you?
Paying only for the fields used makes a lot of sense for data extraction.
ZooData
@ilan1017353 Thanks! You've hit the spirit of it — pay for signal, not bloat. Concretely: pricing is per call, and each call returns clean, typed JSON with only the meaningful fields (empty ones are dropped). A product lookup costs the same whether the page behind it is 50KB or 5MB — the savings show up downstream, where your agent's context gets fields instead of boilerplate.
The pay-per-field pricing model is genuinely clever, it means agents only burn credits on what they actually need instead of paying for entire HTML dumps. Nice execution on the MCP server support too.
ZooData
@asminy6i5 Thanks! The economics you're praising are real — but let me make the mechanics precise, so nobody arrives with the wrong expectations 😄
Billing is a flat price per call, not a per-field meter. The "only pay for what you need" you're describing genuinely exists — just in three other places:
- Responses carry only meaningful fields — no boilerplate, no noise — so your agent's context window (i.e. your LLM token bill) ingests only signal. That's where the big savings live;
- Failures aren't billed — blocks, timeouts, errors: zero;
- Price is independent of page weight — a static page and a heavy SPA cost the same, so you never have to model our costs.
In one line: you pay a predictable flat price for the value you take, and the savings happen downstream in tokens. And thanks on MCP — it runs stateless, so any client stays reliable at any scale.