DoorDash Menu Scraper — Prices & Calories | from $1.50/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 — $1.50/1K (full menu). First 10 items free. Never charged for failed or low-confidence parses (adaptive charging — your money is safe).

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 pushes records for transparency but does not charge. Apify's daily default-run health test catches drift before buyers report it.

---

Pricing

Pay per menu item scraped (menu-item event). 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 (you still get the store record, free),
• low-confidence parses (parse_confidence < 0.3) — pushed for transparency, not billed.

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.