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.
No reviews yetBe the first to leave a review for ZooData
@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
@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.
Report
@Kyle Dong that three-lane breakdown (retryable / don't-retry / content-ok-but-degraded) is actually clearer than most APIs give you even without the granular attribution. makes sense you'd keep the fine-grained block signals internal rather than publish a map of exactly what trips detection. appreciate the detailed answer
@omri_ben_shoham1 Thanks! The three lanes come from a simple inversion: instead of asking "how much error detail can we expose," we asked "where does your agent's control flow actually branch" — it branches three ways, so the API only needs to be clear about three things. Every extra lane would just be a branch you write and never take. If you ever hit a case where three lanes aren't enough, come back and challenge that claim
I can see that for e-commerce you already provide some more custom workflows, I'd love to see the same for general startup pages - like being able to get a startup's pricing or products overview in JSON
@wojtekszkutnik Your instinct about the direction is exactly right — it's how we think about the product ourselves: a general extraction layer underneath, vertical workflows growing on top. E-commerce is just the first vertical we grew, not the only shape it takes.
What works today: point the general extraction at those pages. Page types are auto-detected — pricing pages with tiered plan cards are naturally list-shaped (each plan with a name, price, description), and company home/about pages tend to land as entity-type, coming back as structured facts plus the page's outgoing links. No promise that every startup page parses perfectly — but the general layer will likely take you further than you expect. Worth a round with a few real targets.
After that round, whatever the outcome, send us the URLs plus the fields you wished you'd gotten (support@zoodata.ai) — that's literally how verticals get built here: the e-commerce depth endpoints started with users throwing real pages at the general layer. A startup pricing page is a well-bounded page class, and your ask is noted.
Report
is this restricted to English? I've tried two .ro websites and got nothing back.
@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.
Report
@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"?
① 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.
Report
The silent leak is the one that got us. What worked was hashing the sorted key set we hydrate against and storing that hash next to the extracted row, so when the shape changes the hash moves and something fails loudly instead of quietly gaining a field nobody reads. Cheap to add, and it turned a class of invisible drift into a diff I could actually look at.
@dipankar_sarkar "Turn invisible drift into a diff" — that's exactly the right goal, and the sorted-key-set hash is a nice lightweight way to get there on the consumer side.
We attack the same problem from the producer side: every response field belongs to a typed contract, and the pipeline keeps an explicit registry of upstream keys we've either adopted or deliberately excluded. So when a source starts emitting a new field, it can't quietly slip into the response — it surfaces as a decision someone has to make, and our tests fail if the column list and the mapper ever drift apart. Same philosophy as yours: a shape change should be an event, not a surprise you find three weeks later in a field nobody reads.
Honestly might steal the hash trick for our own eval harness 😄 Thanks for sharing the war story.
Been testing this for a few weeks with my research agent.
The token savings are real: product pages that used to eat half the context window now come back as compact JSON. My LLM bill noticed before I did. Congrats on the launch! 🎉
@power_valsha Weeks of real usage before a comment — that's the feedback that actually means something. Thank you. The context-window savings compounding into real bill savings is exactly the problem we set out to kill. Would love to hear what you're building with it.
If you’ve spent any time building AI agents, you already know the massive pain point they are solving: raw HTML and heavy markdown burn through LLM tokens like crazy, and maintaining custom scrapers is a constant headache.
Personally, what impressed me is how effortlessly it turns any URL into clean, structured JSON—saving up to 75% on tokens. It’s built specifically for the agent era (with an MCP server right out of the box), meaning you only pay for the data fields you actually use instead of bloated prose.
Huge congrats to Ning and the team on the launch! Please give them your support if you find the product useful, test out their 1,000 free credits, and drop your feedback in the comments below!
You nailed it — agents don't need prose, they need fields. Any URL in, clean typed JSON out, plus an MCP server out of the box so Claude/Cursor can pull live Amazon & TikTok Shop data as native tools.
Grab the 1,000 free credits and tell us what breaks — I'll be in the comments all day!
@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.
@Kyle Dong that three-lane breakdown (retryable / don't-retry / content-ok-but-degraded) is actually clearer than most APIs give you even without the granular attribution. makes sense you'd keep the fine-grained block signals internal rather than publish a map of exactly what trips detection. appreciate the detailed answer
ZooData
@omri_ben_shoham1 Thanks! The three lanes come from a simple inversion: instead of asking "how much error detail can we expose," we asked "where does your agent's control flow actually branch" — it branches three ways, so the API only needs to be clear about three things. Every extra lane would just be a branch you write and never take. If you ever hit a case where three lanes aren't enough, come back and challenge that claim
Prelint
I can see that for e-commerce you already provide some more custom workflows, I'd love to see the same for general startup pages - like being able to get a startup's pricing or products overview in JSON
ZooData
@wojtekszkutnik Your instinct about the direction is exactly right — it's how we think about the product ourselves: a general extraction layer underneath, vertical workflows growing on top. E-commerce is just the first vertical we grew, not the only shape it takes.
What works today: point the general extraction at those pages. Page types are auto-detected — pricing pages with tiered plan cards are naturally list-shaped (each plan with a name, price, description), and company home/about pages tend to land as entity-type, coming back as structured facts plus the page's outgoing links. No promise that every startup page parses perfectly — but the general layer will likely take you further than you expect. Worth a round with a few real targets.
After that round, whatever the outcome, send us the URLs plus the fields you wished you'd gotten (support@zoodata.ai) — that's literally how verticals get built here: the e-commerce depth endpoints started with users throwing real pages at the general layer. A startup pricing page is a well-bounded page class, and your ask is noted.
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.
The silent leak is the one that got us. What worked was hashing the sorted key set we hydrate against and storing that hash next to the extracted row, so when the shape changes the hash moves and something fails loudly instead of quietly gaining a field nobody reads. Cheap to add, and it turned a class of invisible drift into a diff I could actually look at.
ZooData
@dipankar_sarkar "Turn invisible drift into a diff" — that's exactly the right goal, and the sorted-key-set hash is a nice lightweight way to get there on the consumer side.
We attack the same problem from the producer side: every response field belongs to a typed contract, and the pipeline keeps an explicit registry of upstream keys we've either adopted or deliberately excluded. So when a source starts emitting a new field, it can't quietly slip into the response — it surfaces as a decision someone has to make, and our tests fail if the column list and the mapper ever drift apart. Same philosophy as yours: a shape change should be an event, not a surprise you find three weeks later in a field nobody reads.
Honestly might steal the hash trick for our own eval harness 😄 Thanks for sharing the war story.
NexaSDK for Mobile
Been testing this for a few weeks with my research agent.
The token savings are real: product pages that used to eat half the context window now come back as compact JSON. My LLM bill noticed before I did. Congrats on the launch! 🎉
ZooData
@power_valsha Weeks of real usage before a comment — that's the feedback that actually means something. Thank you. The context-window savings compounding into real bill savings is exactly the problem we set out to kill. Would love to hear what you're building with it.
Mom Clock
Hey Product Hunt! 👋
I am very happy to hunt ZooData today.
If you’ve spent any time building AI agents, you already know the massive pain point they are solving: raw HTML and heavy markdown burn through LLM tokens like crazy, and maintaining custom scrapers is a constant headache.
Personally, what impressed me is how effortlessly it turns any URL into clean, structured JSON—saving up to 75% on tokens. It’s built specifically for the agent era (with an MCP server right out of the box), meaning you only pay for the data fields you actually use instead of bloated prose.
Huge congrats to Ning and the team on the launch! Please give them your support if you find the product useful, test out their 1,000 free credits, and drop your feedback in the comments below!
ZooData
@justin2025 Thanks for the amazing hunt! 🙌
You nailed it — agents don't need prose, they need fields. Any URL in, clean typed JSON out, plus an MCP server out of the box so Claude/Cursor can pull live Amazon & TikTok Shop data as native tools.
Grab the 1,000 free credits and tell us what breaks — I'll be in the comments all day!