Not a delivery app. The product is a voucher spent in the shop, so the number that matters is a discount percentage, not a menu price.
ScrapeIt runs the collection as a managed service. You name the cities, localities and categories; we build the pipeline, keep offers and merchants as separate record types, enumerate at locality level from the published sitemaps, and hand back CSV, JSON, Excel or a push into your warehouse.
Where offer history matters we run repeat collection and keep every observation rather than overwriting, because a discount that has ended leaves no trace on the page.
We collect public merchant and offer data only, honouring the detailed crawl rules the site publishes - app deep links, internal APIs, merchant portal and payment paths are disallowed and we do not go near them. No user profiles, no social activity, no account access. Your counsel should see the use case before the project starts.
The merchant record covers the merchant name, category, full address, locality, city, rating, review count and the outlet's own page address.
Locality is a first class field, not something parsed out of an address afterwards. It is the level the platform itself organises around and the level at which Indian local commerce actually varies - two localities in one city are different markets with different pricing and different competition.
The offer record is where the commercial value sits: discount percentage, any cap or minimum bill, validity, and the terms as published. Those are the numbers a client is buying, and they are a different shape from a menu price.
Where item level detail is published it is collected as its own record type rather than being forced to stand in for a menu that is not there.
Every row carries the collection timestamp and the locality URL it came from, so any figure can be traced back to the page that produced it.
Locality density analysis is the output clients keep coming back for: how many merchants of a category exist in each locality, how discounting differs between them, and where a category is underserved. It runs off the merchant list and needs no offer collection at all, which makes it a cheap first project.
Category mix by locality tells a similar story from the other side, and both are more robust than anything built on a single city aggregate.
Offer history is the time dimension and only exists from the point where collection starts. Clients who want to know how discounting moved over a quarter need the collection to have been running for a quarter, and we say so at scoping rather than implying history can be recovered.
What we avoid is users. Magicpin carries user profiles, posts and social activity; none of it is in scope and none of it is collected. Merchant ratings and review counts come through as merchant attributes, and review text only where a client has a use for it and never tied to named individuals.
Magicpin is an Indian local commerce platform, and treating it as another delivery app is the fastest way to build the wrong dataset. Its core product is a voucher bought in the app and redeemed at a physical merchant: restaurants, cafes, salons, grocery and fashion.
That changes what a price even means here. A delivery app publishes a menu with item prices. Magicpin publishes merchants with a discount - a percentage off the bill at that outlet - and the item level detail is often secondary or absent. A pipeline that goes looking for a menu will come back nearly empty and report the source as thin, when the value was in a different field all along.
The addressing is unusually good for collection. Merchant pages live under a country, city, locality and category path, so enumeration runs at locality level, and the sitemaps are published and split by locality.
Crawl rules are published and detailed, disallowing app deep links, internal APIs, merchant portal and payment paths - none of which a merchant and offers project needs.
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 brief that arrives is usually written for a delivery platform: menus, item prices, coverage. Run unchanged against this source it produces a sparse table and a wrong conclusion about the source being poor.
What the platform publishes is the offer. A discount percentage against a merchant, with terms, in a locality. That answers a different and often more valuable set of questions: how aggressively merchants discount, how that varies by locality and category, and which competitors are buying visibility through deeper offers.
The second point is that these are physical outlets. The merchant is a venue with an address in a locality, and the dataset is closer to a local competition map than to a delivery catalogue. For anyone planning outlets or studying local retail density, that is the useful part.
The third is locality granularity, which the URL structure makes practical. Running enumeration at locality level rather than city level produces a picture that matches how these markets actually work, and the published sitemaps make the locality list obtainable rather than guessed.
The fourth is that offers move. A discount is a campaign, so an offer dataset has a shelf life measured in days and its value comes from repeat collection with each observation kept.
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 localities and category paths change, and repairs it before your offer history develops a gap it cannot backfill.
You see a sample first, in your format, over the localities you actually care about, with offers and merchants typed separately so you can judge the structure on real outlets.
Sometimes, and it should not be the plan. This is a voucher and discovery platform, not a delivery operator: what it publishes consistently is the merchant and the offer. A pipeline built to find menus returns a sparse table and a wrong conclusion about the source.
A discount - a percentage off the bill at that outlet, with any cap, minimum bill and validity terms. It is a different shape from a menu price and it answers different questions: how aggressively merchants discount, and how that varies by locality and category.
Because that is the level the platform organises around and the level at which Indian local commerce actually varies - two localities in one city are different markets. The published sitemaps are split by locality, so the list is obtainable rather than guessed.
Only from the point collection started. An offer that has ended leaves no trace on the page, so history exists if somebody was observing and not otherwise. We say that at scoping rather than implying the past can be recovered.
No. The platform carries user profiles and social activity and none of it is in scope. Merchant ratings and review counts come through as merchant attributes; review text only where you have a use for it, never tied to named individuals.
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
