Point an agent at a raw HTML page and ask it for "the price" and it has to
guess. Is it the <span class="a-price-whole">? The one three divs over
with a strikethrough on it that's actually the list price, not the sale
price? The markup doesn't say. A structured API response does — it's a
price key, sitting next to listPrice and discount, already correct.
That difference is the entire argument for pulling data through an API
instead of a scraper, and it's worth making concrete rather than asserting
it as a given.
What does an agent actually have to do with raw HTML?
Three things, every single time, for every site: find the right element (a selector that happens to work today), interpret what it means (is this number the price, the rating, a review count that looks like a price?), and handle the case where none of that holds (the element's missing, renamed, or the whole page redesigned overnight). None of that is a one-time cost. A selector that works against today's markup is a bet that the markup doesn't change before your next run.
An agent reading a Mindcase response skips all three. price is a price.
rating is a rating. There's no selector to write and nothing to
re-verify after a source site's next deploy, because parsing already
happened upstream, once, and the same field name means the same thing on
every future call.
What does a real response actually give you instead?
Not just flat labels — nested structure where the underlying page has
structure. Pull a listing from Amazon Products and
variants is already an array (each size or color as its own row-shaped
entry, not a wall of text you'd have to split yourself), keySpecs is
already a structured spec table, and reviewTopics is already grouped by
theme rather than being 1,000 raw review strings you'd have to cluster on
your own. A page redesign that moves the spec table from a grid to an
accordion changes nothing about how you read keySpecs — the API already
did that translation.
This is the part raw HTML fundamentally can't offer: the page's visual layout and its data structure are two different things, and only one of them is stable. A scraper depends on the layout. An API depends on the data.
How much structure are we actually talking about?
More than a handful of top-level labels, and it varies a lot by how much the underlying page actually holds. A few real examples, with their actual field counts, not rounded:
- Google Maps Places — 55 fields per place:
address components broken into
street,city,state,postalCodeseparately (not one string you'd have to parse), plusopeningHours,popularTimes,liveOccupancyPercent, andreviewBreakdownas its own structured object. - Amazon Products — 36 fields:
variants,keySpecs, andreviewTopicsas nested structures on top of the flat fields likeprice,rating, andavailability. - TikTok Posts — 27 fields, including
isAdandisSponsoredas their own booleans — the exact distinction you'd otherwise have to infer from a "Sponsored" label that may or may not be in the DOM depending on the client that rendered the page. - Yelp Business — 25 fields, with
reviewHighlightsandpopularDishesalready extracted as their own lists rather than buried in review text. - Instagram Profiles — 25 fields, splitting
a business account's address into
businessStreet,businessCity,businessLatitude, andbusinessLongitudeindividually.
None of these are edge cases picked to make the point look better than it is — they're the standard response shape for each of those endpoints, every time you call them.
Where does "structured" still require judgment?
It removes the parsing problem, not the reasoning problem. isAd tells you
a TikTok post is sponsored; it doesn't tell you whether that matters for
whatever you're building. reviewTopics groups Amazon reviews by theme;
it doesn't tell you which theme is the one worth acting on. An agent still
has to decide what the fields mean for its task — that's real work, and no
API removes it. What a structured response removes is the version of that
work that has nothing to do with your actual task: figuring out which
<div> the number lives in this week.
Which endpoint should you use for which job?
| Endpoint | Fields | Price | Best for |
|---|---|---|---|
| Google Maps Places | 55 | $0.004 / place | Local business data with genuinely deep structure (hours, occupancy, attributes) |
| Amazon Products | 36 | $0.0015 / product | Product data with nested variants and spec tables |
| TikTok Posts | 27 | $0.002 / post | Engagement data where ad/sponsored status is a named field, not a visual label |
| Yelp Business | 25 | $0.0005 / business | Review data pre-grouped into highlights and popular items |
| Instagram Profiles | 25 | $0.002 / profile | Business account data with address fields already split out |
FAQ
No — it means the cleanup work is deciding what the fields mean for your task, not recovering the fields themselves from markup. You still filter, still judge relevance, still combine fields across a pull. You just don't spend that effort re-locating data a page redesign already moved.
No — field counts vary a lot by how much structure the underlying page actually has. A source with a rich detail page, like Google Maps or Amazon, returns dozens of fields. A source with a narrow purpose, like a single ad-library lookup, returns far fewer. Check an endpoint's own page or skills.md for its real field list rather than assuming.
Nothing, in the normal case — the field names in the response don't change because Mindcase's own parsing absorbed the redesign, not your code. That's the actual value being described here, not a side benefit.
Only tools that do real structured extraction, not raw HTML or a rendered DOM dump, return this. The distinction in this post is API-with-real-fields vs. HTML-you-parse-yourself — not specific to any one vendor.