We benchmarked 6 web scraping providers to see how they handle food delivery data scraping, sending 12,000 requests in total across the top 4 food delivery platforms, and measured success rate, completion time, and metadata coverage.
Food delivery data scraping benchmark overall results
See the benchmark methodology section for more details on the testing process.
Domain-level food delivery data scraping benchmark results
What kind of data can be extracted from food ordering platforms?
Different platforms expose different layers of data, such as menu data, store data, and product data. For example, in our food delivery scraper benchmark, we scraped product data from Instacart.
Only Bright Data returned a structured JSON response, and we grouped the 26 metadata fields it delivered below:
Menu data typically includes item names, descriptions, prices, discounts, images, dietary tags, calories, customization options, and availability.
Restaurant data typically includes the restaurant name, address, cuisine types, ratings and review counts, delivery fee, minimum order, estimated delivery time, working hours, and active promotions.
Food delivery data scrapers
Bright Data was the only provider that achieved both the highest overall success rate (94%) and the fastest average completion time (11) across the four food delivery domains. Its success rate never dropped below 83% on any single domain.
Bright Data offers two main products for food delivery scraping:
Bright Data Web Unlocker API: a single unblocking endpoint that handles anti-bot challenges, CAPTCHAs, and proxy rotation automatically, returning the page’s HTML response. Zomato, Uber Eats, and iFood were sent through this endpoint.
Scraper APIs: Bright Data publishes dedicated scraper APIs and pre-built datasets for specific targets. Among the food delivery domains we tested, Instacart was supported through Bright Data’s Instacart Scraping APIs, with four ready-made products in the catalog:
- Instacart Products collect by URL: takes an Instacart product URL.
- Instacart Products discover by category URL: takes a category page URL.
- Instacart Products unified schema collect by URL: same as the URL collector, with a normalized output schema.
- Instacart Products unified schema discover by category URL: same as the category discoverer, with a normalized output schema.
All of them return structured JSON with the full product metadata such as name, brand, description, price, store name, and ratings. We used Collect by URL variant for Instacart.
Oxylabs ranked among the most reliable providers, with the second highest overall success rate of 91% across the four food delivery domains. On Instacart it tied with Bright Data and Decodo at 100% success rate but delivered the fastest completion time on that platform at 10s. Its overall completion time averaged 27s.
Oxylabs offers a Web Scraper API with several integration modes (Realtime, Push-Pull, Proxy Endpoint). With the Realtime endpoint, source=universal plus render=html renders the page in a headless browser and returns the HTML response.
It also provides dedicated sources for specific sites. For Instacart, there are three:
instacart_product: takes a product ID and returns parsed JSON with the product’s full metadata.instacart_search: scrapes Instacart search results for a given keyword.instacart: accepts any Instacart URL.
Instacart URLs went through instacart_product in food delivery data scraping benchmark.
Decodo ranked among the most consistent providers, with the third highest overall success rate of 90% and an average completion time of 29s across the four food delivery domains. It had the highest success rate on UberEats at 94%, but was the slowest provider overall with a 29s average
Decodo provides a single Web Scraper API (v2) that handles every food delivery target through one endpoint. The request takes a URL, a target parameter set to universal, and a headless flag set to html so the page is rendered in a real browser before the HTML is returned. Anti-bot bypass, proxy rotation, and rendering are handled on Decodo’s side.
There are no dedicated endpoints or pre-built datasets for individual food delivery platforms.
Nimble ranked among the faster providers, with the second fastest overall completion time of 14s across the four food delivery domains.
Nimble ranked among the faster providers, with the second fastest overall completion time of 14s across the four food delivery domains. It had the highest success rate on iFood at 98% and matched Bright Data with a 100% success rate on Zomato. However, its overall success rate of 85% trailed the top performers, mainly due to weaker performance on UberEats (67%) and Instacart (74%).
Nimble does not offer dedicated APIs for any of the food delivery platforms, so every URL went through the general Extract API. The endpoint accepts any URL along with a render: true flag and a stealth browser driver (vx10 in our setup), and returns the page as rendered HTML, with anti-bot evasion, proxy rotation, and JavaScript execution all managed inside Nimble’s stack.
Zyte ranked second lowest overall in success rate with an average of 82% across the four food delivery domains, though it delivered a moderate average completion time of 18s. Its strongest performance was on iFood at 96% success rate, where it ranked second only to Nimble. However, it struggled on Instacart with 62% success, the lowest result among all providers on that platform.
It takes a single-endpoint approach. The same Zyte API serves every request, and the behavior is controlled by flags on the payload. Setting browserHtml: true spins up a headless browser, runs the page’s JavaScript, and returns the fully rendered HTML, which is the only mode that produces usable output for client-side rendered food delivery sites. That flag stayed on for every food delivery URL we scraped.
Apify ranked lowest overall on both metrics, with an average success rate of 56% and the slowest completion time of 41s across the four food delivery domains. It completely failed on Instacart. Its strongest performance was on Zomato at 89% success rate, though it ranked last among providers with non-zero results on every individual platform we tested.
Apify takes a different approach. Instead of a single universal endpoint, it runs on a marketplace of Actors, each a self-contained scraper for a specific site. None of the food delivery platforms in food delivery data scraping benchmark have a first-party Apify Actor, so we used the general-purpose Web Scraper Actor (apify/web-scraper) across every target. So we used the general-purpose Web Scraper Actor (apify/web-scraper) across every target.
Web Scraper opens each URL in a headless Chrome browser, runs a JavaScript page function we write, and returns the result as JSON, with proxy rotation through Apify Proxy and full JS rendering.
One important difference: the JSON from Apify is not a built-in product schema. Bright Data’s Instacart Scraper API returns a fixed set of fields (product name, brand, price, ingredients, store chain, etc.) that Bright Data parses on its side. With Apify Web Scraper, the JSON contains only the fields we define in the page function.
Challenges of scraping food delivery data
Web scraping tools let businesses pull menus, prices, ratings, and inventory from platforms like Zomato, Uber Eats, iFood, and Instacart. A few recurring challenges show up across all of them.
Client-side rendering: Most food delivery sites are single-page apps built on React, Next.js, or Angular, and a large share of the visible content is not in the initial HTML. DoorDash product pages, for example, render the actual product inside a modal that opens only after JavaScript hydration. Scrapers without a real browser layer return the store shell with no product data.
Geo-blocking: iFood is gated to Brazil and refuses most non-BR IPs. A provider can pass every anti-bot check and still fail this domain if its proxy pool lacks stable Brazilian residential exits.
Bot detection: Instacart and DoorDash sit behind aggressive bot-detection systems (Cloudflare on DoorDash, DataDome / PerimeterX-class systems on Instacart) that combine JavaScript challenges, behavioral fingerprinting, and per-account rate limiting. Generic HTTP scrapers get 403s or stalled challenge pages, which is why every provider in our benchmark relies on a built-in unblocking and JavaScript-rendering layer for these targets.
Session stability: On long pagination jobs, sticky residential sessions with long TTLs reduce mid-run blocks. Rotating IPs too aggressively mid-scroll drops the session cookie and forces the site to re-show the first page.
Food delivery data scraping benchmark methodology
We tested 6 web scraping providers against 4 food delivery platforms: Zomato, Uber Eats, iFood and, Instacart.
These platforms were selected based on Tranco’s top-ranked food delivery sites. Each platform contributed 500 unique product or store URLs collected from real catalog feeds, for a total of 2,000 URLs and 12,000 requests across all providers.
Food delivery dataset
The dataset included 500 URLs per platform. Every URL was a real, live page at run time. URLs were deduplicated and the dataset was kept identical across providers to ensure a fair comparison.
Food delivery benchmark setup
All providers were called using the configurations they recommend for arbitrary web pages: universal endpoints with JavaScript rendering enabled where available.
For two cases we used dedicated APIs rather than the universal endpoint because the provider explicitly supports the target. Bright Data was called through its Instacart Dataset API, which returns structured JSON, and Oxylabs was called through its instacart_product source with the product ID, which also returns structured JSON.
Each request was sent as a single call to the provider. Providers were tested sequentially, one at a time, to avoid mixing rate-limit pressure across services. HTTP 429 responses triggered an automatic 30-second back-off and were retried up to 3 times.
What counts as a successful scrape
A request was marked valid only if all of the following held. First, the provider had to return a 2xx, 3xx or 404 HTTP status; anything else, including 4xx blocks and 5xx errors, counted as a failure.
Second, for 200 responses, the parser had to extract at least one of the platform’s target fields from the returned content. The extraction method depended on the response format. For providers returning raw HTML (Decodo, Oxylabs Web Unblocker, Nimble, Zyte, and Apify), we used CSS selectors targeting the structured product or restaurant data containers on each platform. For providers returning structured JSON (Bright Data’s Instacart Scraper API and Oxylabs’ instacart_product source), we read the equivalent fields directly from the JSON response without needing CSS selectors. For Zomato, Uber Eats, and iFood the parser looked for any of title, rating score, rating label or price range. For Instacart it looked for any of product name, brand, description, or a positive numeric price.
Third, pages that loaded successfully but represented a removed listing (HTML containing phrases such as “not found”, “no longer available” or “restaurant not found”) were counted as valid, since the provider had done its job and the content was simply gone.
3xx and 404 responses were treated as auto-pass: the provider proved it could reach the page, and the absence of product data was a property of the URL, not the scraper.
What we measured
For every request the runner logged validation success as a boolean, end-to-end time as total wall-clock seconds from submission to the moment the response was usable, and total metadata as the number of fields present in the parsed result.
Cite this research
Pick the format that matches where you're publishing. Pasting the link version into your CMS preserves the backlink.
@misc{sipi2026,
author = {Şipi, Nazlı},
title = {{Top 6 Food Delivery Scrapers: Benchmark & Use Cases}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/scrape-food-delivery-data}},
note = {AIMultiple. Retrieved September 29, 2026}
}Results and timestamps of 15.5 thousand data points. Download the summary data shown in this article's charts and tables as a ZIP file containing 2 CSV files and a README.
Want the granular data behind it? Join Premium
Changelog
3 updatesAdded a 6-provider food delivery scraping benchmark with success rates, response times, and per-provider results.
Added a benchmark methodology section covering the 6 providers, 4 platforms, 2,000 URLs, dataset, setup, validity rules and metrics.
Removed a figure and its source from the "Ratings\Reviews" section.
Be the first to comment
Your email address will not be published. All fields are required. Comments are left in their original language.