Four catalogues wearing one app. A restaurant menu and a pharmacy shelf have almost no fields in common, and one table for both serves neither.
ScrapeIt runs the collection as a managed service. You name the countries, the verticals and the merchant categories; we build a separate schema per vertical, keep country and currency on every row, compute unit prices for retail, and hand back CSV, JSON, Excel or a push into your warehouse.
Where a brief spans several countries we run them as separate markets on one delivery, so aggregation stays your decision rather than a side effect of the pipeline.
We collect public catalogue data only, honour the crawl rules the site publishes and pace requests; account, checkout and internal API paths are disallowed and we do not go near them. No customer data, no courier data, no account access. Terms restrict commercial reuse, so the output is for analysis rather than republication, and your counsel should see the use case first.
Records are typed by vertical rather than merged. Restaurant rows carry venue, menu section, item, description, price and option groups. Retail and grocery rows carry product, brand, pack size, unit price, category and barcode where published. Pharmacy rows add composition and prescription status where the platform states it.
Country and currency are first class fields on every row. Rappi operates on local currencies that move at different speeds, and a price series that does not record which currency it is in cannot survive contact with a year of inflation.
Merchant records carry the store name, category, address and city, delivery fee, minimum order, estimated delivery time and open state, kept separate from the items.
Unit price is computed for grocery and pharmacy rows where weight or count is published, because comparing a six-pack against a single unit is not a comparison.
Availability and the collection timestamp are on every row, with the country domain recorded so a row can always be traced back to the market it came from.
Price series in this region need deliberate handling. Recording the nominal price with its currency and timestamp is the minimum; where a client is doing real analysis we keep the raw local price untouched and leave conversion and deflation to them, because a converted price with a lost original is a number nobody can check.
Coverage analysis per country is the usual second brief: which merchants and categories exist in each market, how deep the assortment goes, and where a competitor is present that you are not. That runs off the merchant and category lists and is far cheaper than full catalogue collection.
Cross platform matching comes up whenever a client works in more than one app. Merchant names and addresses are written differently across platforms, so the match is a resolution step with a confidence value attached rather than a join on a string.
What stays out of scope is people. No customer accounts, no order history, no courier information, and reviews only where a client has a use for them and never tied to named individuals. The catalogue and pricing work needs none of it.
Rappi is the largest delivery platform in Latin America, operating across roughly nine countries with a separate domain for each: Colombia, Brazil, Mexico, Argentina, Chile and others, each with its own currency, catalogue and merchant base.
It is not one catalogue. Restaurants, supermarkets, pharmacies, convenience and specialist retail sit side by side in the same app, and they are different data. A restaurant listing has a menu with sections and options. A supermarket listing has products with brands, weights, barcodes and unit prices. A pharmacy listing has products with compositions and prescription rules. Treating them as one product table produces a table with three quarters of its columns empty.
The restaurant surface responds directly and carries substantial content, and crawl rules are published, with account, checkout and internal API paths disallowed - none of which a catalogue project needs.
Per country separation runs deep. Prices are in local currency, merchants differ, and the same brand carries different assortments, so each country is a market rather than a region of one.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
The tempting brief is one table of everything Rappi sells. It is deliverable and it is close to useless, because the fields that matter differ per vertical and a merged table drops whatever does not fit.
Restaurants need menu structure and option surcharges. Groceries need brands, pack sizes and unit prices. Pharmacy needs composition and prescription status. Each of those is the primary key of a different analysis, and a client who asked for groceries and received a restaurant schema with a price column is going to build something wrong on top of it.
Countries have to stay apart for a simpler reason: the currencies are different and several of them move fast. A price series across a Latin American market has to carry its currency and its date or it turns into a chart of inflation wearing the costume of a chart about products.
The third reason is that the merchant base differs by country. A brand present in Colombia may not exist in Chile, and coverage questions are answered by the merchant list rather than by the catalogue. Kept per country, that list is itself a market entry dataset.
The fourth is time of day. Fees, availability and promotions move during the day here as they do on any delivery app, and a single daily snapshot records one arbitrary moment of it.
Learn how to use web scraping to solve data problems for your organization
Leveraging advances in technology, the AI-powered web scraper has skyrocketed in demand and is helping to expand capabilities by automating tedious daily tasks and speeding up data collection from thousands of websites several times over.
Web scraping is a method of obtaining web data by extracting it from pages of web resources with the help of a program, that is, in automatic mode. It is used to syntactically convert web pages into more usable forms.
If you specialize in machine learning, you need to feed large amounts of data to the algorithms. Web scraping is the easiest and the most efficient method of collecting the data from all over the Internet.
ScrapeIt is a managed extraction company, not a tool you have to learn. Our team builds the pipeline, watches it as verticals and country catalogues change, and repairs it before your market comparison quietly loses a country.
You see a sample first, in your format, over the countries and verticals you actually trade in, with local currency preserved and unit prices computed so you can judge the structure on real merchants.
We can deliver it, and we will tell you why it is a bad idea first. A restaurant menu, a supermarket shelf and a pharmacy listing share almost no fields, so the merged table drops whatever does not fit and leaves most columns empty. Typed per vertical, each one is directly usable.
Currency and country sit on every row and we keep the raw local price exactly as published. Conversion and deflation are left to you, because a converted price with the original lost is a number nobody downstream can check - and in this region that matters within months, not years.
No. The merchant base, assortment and pricing differ per country, and each runs on its own domain. We collect them as separate markets on one delivery so any aggregation is your deliberate choice rather than something the pipeline did quietly.
Yes, wherever weight or count is published, because comparing a six-pack against a single unit is not a comparison. The raw price and pack size stay on the row alongside it so the calculation is auditable.
Out of scope entirely. No customer accounts, no order history, no courier information. The crawl rules disallow account and checkout paths and we do not go near them; catalogue and pricing work needs none of that data.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
