DoorDash Menu Scraper — Prices & Calories | from $0.59/1K | No Cloudflare Block

Built for restaurant market analysts tracking chain pricing, nutrition app developers enriching food databases with calorie data, and franchise consultants benchmarking menu structures across competing chains.

Pricing: Pay per menu item — $0.59/1K (full menu). Free-plan previews return up to 10 items. Failed, empty, or low-confidence parses do not push dataset rows, so they do not create per-item charges.

No Cloudflare. No Playwright. No browser required. Adaptive charging — never pay for bad data.

Scrape DoorDash chain restaurant pages and extract full menus with prices, calories, item descriptions, and restaurant metadata. Uses the Cloudflare-free /business/ chain path — no browser required, no Playwright overhead. Returns one record per menu item. Structural RSC parser with parse_confidence drift detection. Pay per menu item.

Get every Chipotle, McDonald's, or Starbucks menu item — with calories and prices — in one structured JSON output.

---

vs. competitors

DoorDash's consumer /store/ pages sit behind Cloudflare and require a full browser (15–25s per restaurant, frequent breakage). Most scrapers target this path. This actor targets the /business/ chain path — served without Cloudflare challenge and containing full menu data as RSC streaming payloads. No browser, no Playwright, fast.

Feature	This actor	Typical alternatives
Cloudflare challenge	No (uses /business/ path)	Yes — 15–25s/store, fragile
Prices	Numeric (price_cents + price_usd)	Strings like "$8.50"
Item modifiers / options	Yes — option groups + per-option prices	No
Store metadata on every row	Rating, delivery fee, ETA	Usually omitted
Calories	Yes (null when undisclosed, not a fake 0)	Often missing
Item IDs	Yes (item_id)	Rarely
Parser type	Structural RSC keys (no CSS classes)	CSS class-based (breaks on updates)
Parser health signal	parse_confidence + parse_source + warnings	None
Fallback when format drifts	Yes — RSC → __NEXT_DATA__ → JSON scan	None (hard break)
Charge on failure	Never	Often (broken runs still billed)

---

Output Schema — Per Menu Item

Field	Type	Description
restaurant_name	string	Chain name, e.g. "Chipotle Mexican Grill"
business_id	string	DoorDash store/business ID
city	string	Store city
state	string	Store state/region code
category	string	Menu section name, e.g. "Entree", "Drinks"
item_name	string	Menu item name
description	string	Item description
price_cents	integer	Price in cents (e.g. 1320 = $13.20)
price_usd	float	Price in USD (e.g. 13.20)
calories	number	Calorie count — null when the chain doesn't disclose it (never a misleading 0)
options	array	Option groups / modifiers: [{name, min, max, options:[{name, price_usd, price_cents}]}]. Empty list when the item has none.
image_url	string	CDN image URL
item_id	string	DoorDash item ID
is_popular	boolean	Marked as popular/featured
rating	float	Store average rating (repeated on each row)
num_ratings	integer	Number of store ratings
delivery_fee	string	Displayed delivery fee, e.g. "$0.99"
eta_minutes	integer	Estimated delivery time in minutes
source_url	string	The /business/ URL scraped
parse_confidence	float	0.0–1.0 structural parse quality score
parse_source	string	Which parser produced the row: rsc (primary) or next_data (fallback)
warnings	array	Machine-readable drift signals
scraped_at	string	ISO-8601 UTC timestamp

Each menu-item row is self-contained — it repeats the store name, rating, delivery fee, and ETA, so you can analyze a single row without joining back to a restaurant record.

---

How to Use

Option A — direct URLs

{
  "businessUrls": [
    "https://www.doordash.com/business/chipotle-mexican-grill-115/",
    "https://www.doordash.com/business/mcdonald-s-36398/"
  ]
}

Find the business URL by visiting any chain's DoorDash page and copying the /business/ path URL.

Option B — slug + ID

{
  "businesses": [
    {"slug": "chipotle-mexican-grill", "businessId": "115"},
    {"slug": "mcdonald-s", "businessId": "36398"}
  ]
}

Bulk menu comparison

{
  "businessUrls": [
    "https://www.doordash.com/business/chipotle-mexican-grill-115/",
    "https://www.doordash.com/business/taco-bell-6174/",
    "https://www.doordash.com/business/subway-3796/"
  ]
}

---

Use Cases

Restaurant menu intelligence

Pull every item name, price, and calorie count from competing chains. Track price changes across locations or compare value-per-calorie across menus.

Food delivery market research

Analyze menu structure, category organization, and item naming conventions across fast-food chains. Identify menu gaps or pricing anomalies.

Nutrition & calorie tracking apps

Build or enrich food databases with DoorDash menu data. Filter by calorie count, price range, or is_popular flag.

Franchise pricing analysis

Compare prices for the same chain across different city/state combinations. Identify regional price variation in franchise menus.

Competitive menu benchmarking

Restaurants building new menus can compare their pricing and item structure against established chains at scale.

---

Scope & Limitations

Supported: DoorDash /business/ chain pages only — these contain the full embedded menu without Cloudflare challenge.

Not supported: Consumer /store/ delivery pages (which show delivery ETA, address-gated menus, and real-time availability). Those require Playwright and are a Phase-2 add-on.

• Menu items without a section name get category: "Menu"
• Calories are null when the chain doesn't publicly disclose them (never a misleading 0)
• Prices reflect the chain's listed menu price, not delivery-fee-adjusted totals

---

Proxy

RESIDENTIAL proxy is strongly recommended. Datacenter IPs may be rate-limited on high-volume runs. The actor defaults to useApifyProxy: true, groups: ["RESIDENTIAL"]. Proxy usage is billed to the run owner at standard Apify platform pricing.

---

Parser Resilience (the B-plan)

RSC payload formats drift. This actor degrades gracefully instead of breaking:

1. Primary — RSC parse. Reassembles the React-Flight stream across __next_f.push() chunk boundaries (a single menu node frequently spans two pushes; naive parsers drop it). Nodes are matched by stable keys/shape, never by positional hex IDs or CSS classes.
2. Fallback — __NEXT_DATA__ / embedded JSON. If no RSC stream is present, the actor harvests menu data from the legacy __NEXT_DATA__ script or any inline application/json block. Rows are tagged parse_source: "next_data".
3. Fail-soft everywhere. A truncated or changed node is skipped, never crashes the run. parse_confidence drops to reflect the gap.

Every output record includes parse_confidence (0.0–1.0), parse_source, and warnings. A score below 0.5 signals likely structural change; below 0.3 the actor skips output so buyers are not billed for low-confidence rows. Apify's daily default-run health test catches drift before buyers report it.

---

Pricing

Pay per menu item scraped (apify-default-dataset-item event, $0.59/1K). A 50-item menu = 50 charges; a 150-item menu = 150 charges. You are never charged for:

• the actor starting up,
• failed or blocked fetches,
• restaurants that return no items,
• low-confidence parses (parse_confidence < 0.3).

Set maxItems to cap spend: it's a strict budget enforced even mid-restaurant.

---

Pricing example

Volume	Cost
50 items (1 Chipotle)	$0.075
100 items (~2 restaurants)	$0.15
1,000 items (~15 restaurants)	$1.50
10,000 items	$15.00

A typical chain restaurant has 30–80 menu items. First 10 items free. Low-confidence parses (parse_confidence < 0.3) are pushed for transparency but not charged.

FAQ

Do I need a DoorDash account or API key? No. This actor uses the public /business/ chain pages — no login, no credentials required.

Do I need a proxy? RESIDENTIAL proxy is strongly recommended — datacenter IPs are commonly blocked by DoorDash on higher volumes. The actor defaults to useApifyProxy: true, groups: ["RESIDENTIAL"]. Proxy costs are billed to the run owner at standard Apify pricing.

What output formats are available? JSON (default), CSV, and Excel — via the Apify dataset export or API.

What if the actor returns no menu items? Ensure the URL is a /business/ chain page (not a /store/ consumer delivery page). If parsing fails, check parse_confidence in logs — a score below 0.5 means DoorDash's RSC format may have changed. The actor auto-retries with the __NEXT_DATA__ fallback before giving up.

Calorie data use case

Nutrition app building example: scrape Chipotle's full menu, filter calories > 0, deduplicate by item_name — instant structured nutrition database. Health-conscious buyers pay a premium for calorie-guaranteed data.

Use with AI agents (MCP)

This actor is tagged MCP_SERVERS — compatible with Claude, GPT-4o, and other MCP-aware agents:

https://mcp.apify.com/?tools=bovi/doordash-scraper

Not affiliated with DoorDash. Data is publicly available on doordash.com.

Integrations

Built for restaurant market analysts and nutrition-app developers extracting chain menu prices and calorie data at scale — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

• Uber Eats Menu Scraper
• Opentable Scraper

Chain any of them together from the Integrations tab (the Run succeeded trigger) to build a multi-step workflow — one actor's output feeds the next.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.