MercadoLibre Scraper

Pull product listings off MercadoLibre with the prices intact: what a thing costs now, what it cost before the discount, and how deep the discount is. Works across every MercadoLibre site, including Brazil's Mercado Livre.

Give it a category or deals URL and you get back one row per product card.

Countries covered

Argentina, Brazil, Mexico, Colombia, Chile, Uruguay, Peru, Venezuela, Ecuador, Bolivia, Paraguay, Costa Rica, Panama and the Dominican Republic. Each row carries the site code (MLA, MLB, MLM, MCO and so on) and the country, so a run across several markets stays sorted afterwards.

What each product gives you

• title and item_id, MercadoLibre's own stable product id
• price as a number, plus currency_symbol
• original_price when the card shows a struck-through price, and discount as the label displayed, such as 40% OFF
• url to the product page and image_url
• badge for cards flagged as bestsellers or promotions
• shipping and installments where the card shows them

MercadoLibre does not print a seller name, a star rating or a review count on category cards, so this Actor does not return those three. They exist only on the product detail page, which is a separate fetch per product.

• source_url, so every row traces back to the page it came from

The three things this gets right that are easy to get wrong

The discounted price is not the first price in the page. On a discounted card MercadoLibre renders the old price first, struck through, and the current price after it. Reading the first amount you find gives you the pre-discount figure labelled as the price, which is wrong in the most damaging possible way: it looks completely plausible. Current and previous prices are read from their own elements and reported separately.

Thousands separators are not the same everywhere. Argentina and Brazil write two hundred thousand as 207.999. Mexico writes one thousand two hundred and ninety-nine as 1,299.00. Apply either country's rule to the other's number and you are off by a factor of a thousand. Each value is inspected for which convention it uses rather than assumed, so a multi-country run comes back comparable.

A page with no products is not the same as a page that was refused. Some category URLs are navigation landing pages that genuinely hold no product grid. Those are reported in the summary as URLs without a product grid. A page that came back as a short placeholder instead of the real listing is reported as an error explaining what happened. Both beat silently returning zero rows and letting you assume the category was empty.

Which URLs work

Category pages, deals pages, and any browse page that renders the product grid. Open the page you want in a browser, confirm you can see products, and paste the address.

Keyword search URLs (listado.mercadolibre.com/...) are not served as a full page to anyone. Rather than return an empty result and let you guess, the actor detects the placeholder and tells you so, naming the URL and suggesting a category page instead. This is stated up front because it is the one thing you might reasonably expect to work.

Input

A list of URLs, and optionally:

• Maximum products per URL — an upper bound per page
• Maximum URLs — how many to process in one run
• URLs in parallel — how many to fetch at once
• Retries — attempts with backoff before a URL is reported failed
• Request from country — a two-letter code, when a site serves different prices or promotions by region

Run summary

How many URLs were requested, how many produced products, which ones had no product grid, the total returned, how many carried a price and how many were discounted, plus a breakdown by country and an average price.

The average price comes with an explicit warning attached: prices are in each site's own currency, so averaging across a multi-country run mixes pesos with reais and means nothing. The summary says so in the output rather than leaving you to notice.

Scale and cost

Each URL costs exactly one page fetch. There is no pagination loop and no per-product follow-up request, so a run of fifty category pages is fifty requests and finishes in seconds. Four category pages across four countries returned 176 products in under two seconds in testing.

What you get is what the page renders, which is typically 20 to 60 cards. The actor does not claim to walk deeper than the page actually serves.

What people use this for

Competitive price tracking. Run the same category URLs on a schedule and join on item_id. Because original_price and discount come through separately from price, you can tell a genuine price cut apart from a card that simply started advertising a higher reference price, which is a distinction a single price column cannot make.

Promotion monitoring. The deals pages are the fastest read on what a market is discounting right now, and badge surfaces which items the site is pushing as bestsellers.

Cross-border comparison. The same product often sits on several MercadoLibre sites at very different prices. Run the equivalent category in two countries, and site and country on every row keep the two sets separable afterwards. Convert currencies yourself: the actor deliberately does not, since a rate baked into the output would be stale the moment it was written.

Catalogue building. item_id, title, image_url and url are enough to seed a product catalogue, and the id is stable across runs.

A note on prices

Prices are read at the moment of the fetch. MercadoLibre runs frequent time-limited promotions, so two runs hours apart will legitimately disagree, and that difference is the data rather than an error. If you are tracking price movement, keep item_id and the timestamp of your run: the id is stable, so joining across runs is straightforward.