Web Scraping vs API: Same Amazon Product, Two Routes Tested

Get one product's price and rating from a page and from a product API, and see which fits your job. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to get the price, rating and review count of Amazon product B09B8V1LZ3 with a product endpoint and with a page fetch, and tell me which fields differ between the two.

One prompt runs both routes on the same target. 1 min setup · 12-24 hrs saved.

Web scraping versus an API sounds like a choice between two technologies, but both end in the same HTTP request for the same facts. What differs is the shape of what you get back, who keeps it working, and what each route does when the page and the data disagree. So we ran the test on 2026-10-16: one Amazon product, pulled once as a rendered page and once from a product endpoint, then compared the two. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to get web data without choosing between scraping and an API?

Monid. You do not pick a side up front: both routes are endpoints you call from your agent, and you choose per target after reading the schema and the price, which are free to look at.

• Pay per call. A page scrape is billed per page, at $0.002533 (Verified 2026-10-16). A product endpoint is billed per product, at $0.005 for the Amazon one we ran (Verified 2026-10-16). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection never bill.
• One install, both routes. The same key and the same balance call the page fetcher, the product endpoint and every other tool on Monid. Switching a target from one route to the other is a change of endpoint name in the call, not a new vendor account.
• Lives inside your agent. Install the CLI, add your key, paste the prompt above, and the agent discovers the endpoints itself. Setup is about a minute.

If you want the web-scraping tool landscape first, which kind of web scraping tool you need sorts the options by who operates them.

What is the difference between web scraping and an API?

An API returns fields somebody decided to name, and scraping returns a page you have to read. Three differences follow from that, in the order they bite.

What shape the answer arrives in

An API call returns typed values: a price is a number, a rating is a number, a review is an object with a date. A scrape returns the page as text or HTML, and the price is whatever string the page printed. Both carry the same fact, but only one is ready to put in a database column.

Who keeps the extraction working

With an API, someone maps the page, or the publisher's internals, to a stable list of fields and repairs that map when the source changes. With a scrape, the mapping is yours, a selector or a prompt that runs over the text, and it breaks on the publisher's schedule rather than yours. This is the question underneath "which is more reliable": reliability belongs to whoever owns the mapping, not to the method.

What is exposed

An API shows the fields it chose to return. A page shows everything the browser rendered, including things no field was ever made for: the bundle prices, the delivery line, the banner text. The page route gives you more and asks you to do the reading. For the legal side of fetching public pages, Is Web Scraping Legal? has the cases.

How do you pull the same product both ways?

Run the product endpoint once and the page fetch once, with the same target. The target is Amazon ASIN B09B8V1LZ3, the example in the product endpoint's own schema, so you can repeat the test with it.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Route 1: the product API

The Amazon product endpoint takes a POST body, so the input goes in -i:

monid inspect -p dataforseo -e /amazon/asin
monid run -p dataforseo -e /amazon/asin -w -i '{"asin":"B09B8V1LZ3","location_name":"United States","language_code":"en_US"}'

Route 2: the page fetch

The fetcher takes a GET with query parameters:

monid inspect -p context.dev -e /web/scrape/markdown
monid run -p context.dev -e /web/scrape/markdown --query '{"url":"https://www.amazon.com/dp/B09B8V1LZ3","useMainContentOnly":true}' -w

Or hand both to an agent

📖 See also Best Amazon Reviews API in 2026

Can you scrape the page yourself instead?

Yes, and the free version is Python with requests and BeautifulSoup. For a static page that reads cleanly it is an hour of work and costs nothing but your time.

Large retail pages are the opposite case. The content depends on the visitor's location, parts of it load after the page does, and a plain request can be turned away. So the self-built route grows a browser to render the page, a pool of exit addresses, a parser for each field and a repair step for the day the markup changes. The scrape in our test came back from Ashburn, because the page text carries "Delivering to Ashburn 20149"; a request from your own machine sees the page its own address earns.

The full Python walkthrough, including rendered pages, is in scraping in Python without running a scraper. What you keep in exchange is control of exactly which fields you extract. What you give up is the maintenance, forever. The two Monid endpoints above move that work to the provider: the fetch handles rendering and proxies and bills only for pages it returned, and the product endpoint hands you named fields so there is no parser at all.

What does each route return for the same product?

The product endpoint returned one item with 30 named fields, 8 reviews with their text among them, and the page fetch returned 45,819 characters of Markdown that contained the same facts and a lot more. Both calls completed and each billed one unit.

The product API

One item of type amazon_product_info came back. Among its fields:

{ "title": "Amazon Echo Dot (newest model) - Vibrant sounding speaker, ... Charcoal",
  "price_from": 79.99, "price_to": null, "currency": "USD",
  "rating": { "value": 4.7, "votes_count": 201006, "rating_max": 5 },
  "is_amazon_choice": true, "is_available": true,
  "parent_asin": "B0BF73CTQF", "product_asins": ["B09B8V1LZ3", "B0HKL4CT1J", "..."],
  "product_images_list": ["https://m.media-amazon.com/images/I/61J2sQtBYDL._AC_SL1500_.jpg", "..."],
  "top_local_reviews": [ { "title": "Excellent little smart speaker", "verified": true,
    "helpful_votes": 14, "publication_date": "2026-09-24 00:00:00 +00:00",
    "rating": { "value": 5 }, "review_text": "..." } ] }

It carried 7 image URLs, 6 ASINs in the variant family and 8 reviews, each with a title, a date, a verified flag and the helpful votes. The price is the number 79.99.

The page fetch

The response held the Markdown and a metadata object with title, description, canonicalUrl, finalUrl, headings and additionalMeta. In the Markdown, the same facts were present as text: the price three ways, "In Stock", "4.7 out of 5 stars" with (201,006), delivery dates, a returns policy, and a block of bundle prices. It also held a JSON fragment with "priceAmount":79.99, which is the number you would have wanted in the first place.

Side by side

Reviews are the row that surprised us: the page route with useMainContentOnly carried a short "Customers say" summary and none of the review bodies that the product endpoint returned.

What goes wrong with each route?

Both calls succeeded, and both still returned things you would not want to load unchecked. Each finding is from the 2026-10-16 runs.

Why can a scrape return the price three times?

Because the page prints a price in several places and the conversion to text flattens the markup. The same price appeared run together twice, then with a doubled dollar sign and digits merged, then plainly, and an extraction rule that takes the first dollar amount gets a string it cannot parse. Parse against the fragment that holds a clean number, or let a typed endpoint do it. Amazon ASIN scrapers that return nothing shows the other failure, where the fields exist and the values are empty.

Why does a typed endpoint still return nulls?

Because named fields are a promise about the shape, not about the content. In our call categories, product_information, details, percentage_discount and newer_model were all null, even though the endpoint's description lists categories and a product details table. Count the nulls per call, and treat a field that is always null as missing rather than as an empty answer.

Why did the two routes name the product differently?

The page metadata title read "2022 Echo Dot 5th Gen Smart Speaker | Charcoal | Amazon" while the Markdown's own heading and the product endpoint's title read "Amazon Echo Dot (newest model) ... Charcoal". Two readings of one product gave two names. If you join records from both routes, join on the ASIN, never on the title.

Why is the scrape bigger than the answer?

Because you pay in tokens for everything on the page. The 45,819 characters held two lines of unfilled template text (${cardName}), a returns policy and a bundle table, and an agent that reads them all spends context on a price it could have read as a number. Send the Markdown through a field extractor, or choose the route that returns fields, when the output goes to a model.

What did the two calls cost?

Two calls, $0.007533 in total: $0.005 for the product endpoint and $0.002533 for the page (Verified 2026-10-16). Per monid inspect, the page fetch does not bill failed or blocked requests. At those prices 100 products is $0.50 through the product endpoint and about $0.25 as pages, before the cost of reading the pages.

📖 See also Browser Automation When the Site Has No API

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect. We ran the first two. The third we inspected without running; its description says it reads up to maxPages pages, 5 by default, and bills one call regardless. Current numbers live on monid.ai/tools. Work down the table by need: a typed endpoint when one exists for your target, a schema extraction when you want fields from a page nobody has built an endpoint for, and the plain Markdown fetch when you want the text.

When is another route a better fit?

The publisher's own API covers your fields. Take it. It is the source, it is versioned and somebody answers for it. A page scrape has no argument against that for data the API actually contains.

You need a guarantee of completeness. A scrape sees what rendered. A missing item looks the same as an item that does not exist, so a deliverable of "every product" needs a compiled dataset.

The data sits behind a login or a licence. The rules differ by place and by data type, so check yours before building anything.

You need history. Both routes return today's page. Price history is a database someone has been collecting, or a scheduled job you start now.

And the disclosure: you are on the Monid blog and we sell per-call access to both kinds of endpoint. The advice that costs us nothing is to count the nulls and parse a clean number, whichever route you buy.

Conclusion

Web scraping versus an API comes down to the shape of the answer and the owner of the mapping. In our test the product API returned a number and the page fetch returned a page that contained the number, the number again as text three times, and 45,000 characters of everything else. Pick the typed route when one exists for your target, and the page route when none does, both through Monid at $0.005 and $0.002533 a call (Verified 2026-10-16).

Two things matter more than the choice. Join records on an identifier such as the ASIN rather than on titles, because the two routes named the same product differently. And check the output for nulls and doubled strings on every run, because both calls succeeded and both needed checking.

How we estimated the time saved: building and running your own scraper for a rendered retail page is roughly 8 to 16 hours for the fetch layer, proxies and a parser, plus 4 to 8 hours for the first month of repairs. That is 12 to 24 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p dataforseo -e /amazon/asin, then make the one call from this post on a product you know and compare the fields with the page. Start at monid.ai.

FAQ

Published August 2026.