ZooData

The data layer for AI agents

Developer Tools

Artificial Intelligence

E-Commerce

Visit WebsiteSee on Product HuntTwitter ⧉

Boundary hydration against the known key set is exactly the fix, and the bonus is our static types stop lying: once every key is present the declared shape and the runtime object finally agree. One thing that bites later though, if you add a field to a page_type down the road my hydration set silently goes stale and I'm back to drift with no signal. So whatever field set you publish, stamp a version on it and I'll pin to that.

data layer is the real bottleneck for agents rn 🙌 clean json instead of raw html is exactly it. nice one!

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

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.

@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

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?

@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

Totally fair not to fake a null you can't stand behind. My pain sat one level below the semantics: `price` showing up in one response and vanishing from the next meant every field access in our agent needed a guard, since parsing code leans on a stable shape. If each page type always emitted its full key set with the value simply absent, that alone fixes the shape, and the sourced-vs-not flag you floated with Jernej could carry the did-we-check honesty on top. Does the fixed-per-page-type schema you mentioned to hazy already give me that stable key set, or can fields still drop out per call?

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.

the auto-escalate-to-full-model-extraction when core fields fail validation is a smart fallback. if a site is mid A/B rollout and flips between old/new layout per request, does that thrash the escalation path back and forth before the new template locks in, or is there a cooldown so you're not eating full-model cost on every call during the rollout window?

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?

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?

The 75% token reduction claim makes sense structurally but I'm curious how it holds on pages where the most valuable data is buried in dynamic elements that only render after JavaScript executes , things like live pricing widgets, inventory counters, or seller ratings that load asynchronously. Is the JSON output pulling from the fully rendered DOM or the initial HTML response, because for e-commerce intelligence that difference is where the real data quality gap tends to sit.

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?

@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?

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?

The 'any URL to structured JSON, pay only for the fields you use' angle is what makes this actually fit an agent loop instead of burning tokens filtering markdown. When I specify the fields, is that a per-request schema I define, so the same URL can return different shapes for different agents, or a fixed schema inferred per domain? And on JS-heavy pages that lazy-load content, does extraction run against the fully rendered DOM or the initial HTML?

One thing about dropping empty fields to save tokens: it makes the JSON shape shift from call to call. Our agent code ended up defaulting every field access because a missing `price` could mean the page had none or the extractor whiffed, and there's no way to tell which downstream. A stable schema with explicit nulls, or echoing back the resolved schema per page type, would fix that. Are you leaning stable-schema or minimal-payload long term?