Launching today
ZooData
The data layer for AI agents
655 followers
The data layer for AI agents
655 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.
ZooClaw
Hi PH 👋,
I'm Ning from ZooData.
Quick context on why we built this.
If you've built anything with agents, you know the data problem. You scrape a page — with browser-use, Playwright, whatever — and what comes back is raw HTML or "clean" markdown. Either way it's stuffed with nav bars, footers, ads, and boilerplate. For a human reading it, fine. For an LLM, you're burning thousands of tokens on stuff the model has to filter out before it can do anything useful. At scale that's real money, and most of it is waste.
Markdown is the usual fix. But markdown was built for humans to read, not for an agent that has to act on the data. Different reader, different format — an agent doesn't need prose, it needs structure.
ZooData does the extraction step right:
Any URL → structured JSON. No schema to define, no per-site parsers, no selector glue to maintain.
~75% fewer tokens than raw markdown on the same page — roughly 1/5 the cost of other extractors. And you only pay for the fields you actually use; the extraction itself doesn't burn credits.
API, CLI, and MCP server, so it drops into your agent stack without rewriting anything.
Pre-analyzed e-commerce platform intelligence — competitor, market, traffic, and consumer signals your agent can query directly, instead of scraping and stitching it together itself. More platforms coming.
We believe the next bottleneck for AI agents won't be how smart the models get — it will be the quality of the data they rely on.
As AI-generated content floods the web, agents need data that's clean, structured, and verifiable to make reliable decisions. That's the layer we're building, and it compounds: every page we process makes the next request cheaper, faster, and more trustworthy.
ZooData is the foundation the rest of it runs on — we launched ZooClaw (agents for individuals) here not long ago, and ZooWork (the enterprise version) is coming soon.
1,000 free credits, no card. Just tell your agent:
and you're off.
Would love your feedback. And I'm curious — what's the messiest site you've ever had to scrape? 🙏
@ninghu For teams using agents today, what’s the single biggest pain you still face with web data quality and how would a perfect extractor make your life easier?
The data-quality point is the right one, most agent tools skip straight past it to the model.
One thing I'd add from the support side, where we build agents. Clean JSON fixes the token cost, but it quietly adds a different risk. Raw HTML looks messy so you distrust it. A structured field looks authoritative even when the extractor grabbed the wrong element, or the value went stale between the scrape and the moment the agent acts on it. For an agent that only reads, fine. For one that acts on the field, answers a customer or changes a price, a confidently wrong value is worse than a missing one, because nothing tells it to stop.
So the question, does ZooData give the agent anything per field, a confidence score or a freshness timestamp, or is it flat JSON it has to trust fully? On live Amazon/TikTok data I'd expect the real failures to sit there, not in the extraction.
ZooData
@jernej_jan_kocica Good question — and you've split it into the two failures that actually matter: extraction correctness (did we grab the right element) and freshness (has it gone stale before the agent acts). Let me take both honestly.
Confidence (extraction side): no, we don't expose a per-field confidence score today — it's on the roadmap. And your framing is exactly the spec for it: for an acting agent, "a confidently wrong value with nothing telling it to stop" is the failure worth engineering against. A missing value fails safe; a wrong one doesn't. That's the signal we want to give the agent.
Freshness (the side you'd bet the real failures sit on): this is the part we've actually designed hard around, so I can be concrete —
scrape/realtime endpoints force a live fetch on every call. No cache, ever. There's no gap between capture and read — the value is fresh at the moment the agent asks.
analytics/commerce endpoints run on a daily cycle, so every value is explicitly time-bounded rather than pretending to be real-time — the agent knows exactly how old it is.
So interestingly, the live Amazon/TikTok data you flagged as the danger zone is the part we deliberately don't cache — the open gap you've correctly found is extraction-confidence, not staleness. Since you build support agents that act on fields, I'd genuinely like to design that confidence signal with input from your seat rather than guess at it. Happy to swap notes.
@kyle_dong Fair. If freshness is a live fetch with no cache, then that gap is smaller than I guessed. Good.
On the confidence signal, one thing from acting on this data every day. A 0-1 score is the obvious shape but it's the wrong one for an agent that acts, a number gets rubber-stamped, 0.82 means nothing at the moment it has to decide. What you actually want is closer to a boolean per field: was this value read from a labeled source (a data attribute, schema.org, an obvious price node), or was it inferred because something looked like a price. Sourced, act on it. Inferred, never act, only surface for a human. The dangerous field is always the inferred one that came out looking clean.
And keep it per field, not per page. The same page can have a solid title and a guessed price, one score for the whole extraction hides exactly the field that will bite.
Happy to swap notes on it.
Great launch! The token math is the part that really matters, at least for agents. Paying to filter boilerplate out of 'clean' markdown is a tax you don't price in until the bill shows up! Wondering - when a site quietly ships a layout change or runs an A/B test, does that learned template keep mapping to the old fields and hand back a confidently wrong value?
ZooData
@artstavenka1 This is the question to ask any extraction system — "fast but wrong" is far scarier than "slow." Our defense: templates are never trusted unconditionally; every request is validated. Extraction output must pass core-field and type checks, and the moment a page stops matching expectations (missing/abnormal core fields), that request auto-escalates to full model extraction — the same slow path a brand-new page type takes. In other words, the default failure mode of a layout change is degrading to "slower but correct," not "fast but confidently wrong."
And an honest caveat: if an A/B variant happens to yield a value that's type-valid but semantically wrong, no extraction system can rule that out 100%. We run continuous quality evals against live pages to catch that kind of drift — and if you ever hit a confidently-wrong value in the wild, send it to support@zoodata.ai. We treat those as bugs, not noise.
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.
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.
Really glad to see an MCP server included from day one. It shows a deep understanding of current developer workflows and makes integrating this JSON extraction much more appealing.
ZooData
@glsm11117961978 Thanks! One design detail worth sharing: our MCP tools and REST API are generated from the same codebase — every endpoint's schema, description, and validation share a single source, so the MCP tools never drift out of sync with the API. The server side is also fully stateless, so any MCP client stays reliable at any scale. If anything feels rough in your integration, tell us — we'll fix it!
ZooData
@grrigore Thanks for flagging — it's not English-only by design; the open-web extraction is language-agnostic. One thing worth knowing: when we encounter a brand-new page type, the first extraction takes extra time (the system first works out the structure for that type of page — after that, similar pages are fast). Please give it another try in a bit; if you still get nothing back, send us the two URLs (here or at support@zoodata.ai) and we'll confirm what's going on — and report back.
@kyle_dong Yes, it works now. It might be helpful to share that explanation with the user as well. Is there a way to automatically scrape "outgoing_links"?
ZooData
@grrigore Great question! Two cases:
① Entity-style pages — outgoing links are already included by default. If the page is about one specific named thing (think a HuggingFace model page, an IMDB movie page, a Goodreads book page — one subject, structured facts around it), the extracted JSON already carries the page's outgoing links, no extra parameters needed.
② Other page types — a dedicated endpoint exists, just not public yet. We've built a dedicated outgoing-links capability internally but haven't opened it up. So: try the default output on your actual pages first. If it covers you, great; if it doesn't, tell us your page types and use case — your scenario is exactly the push we need to release it. Find us here or at support@zoodata.ai.