DoorDash Store Details Scraper
Pricing
from $2.99 / 1,000 store details
DoorDash Store Details Scraper
Extract bounded public store details from explicit DoorDash store pages, including identity, address, rating, menu metadata, and public structured-data reviews.
Pricing
from $2.99 / 1,000 store details
Rating
0.0
(0)
Developer
w3crawler
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
3 days ago
Last modified
Categories
Share
This Actor extracts bounded public store details from explicit DoorDash /store/ pages. It uses a consistent desktop-navigation header profile for direct HTTPS requests to official DoorDash hosts only, caps each response, follows a small number of same-host redirects, and never logs in, solves CAPTCHAs, or bypasses security controls. When DoorDash blocks an unlocalized /store/ route, the Actor retries the equivalent official /en/store/ route, which exposes the same public page data without requiring a session.
Input
Pass urls or startUrls as an array of { "url": "https://www.doordash.com/store/..." } objects. url is accepted as a single-target alias. maxItems, timeoutMs, maxRequestRetries, requestDelayMs, maxBytes, and userAgent are bounded request controls. proxyConfiguration accepts the standard Apify Proxy object and defaults to direct access. Unknown fields, credentials, non-HTTPS URLs, off-domain URLs, and non-store paths are retained only as explicit invalid-input diagnostics.
If no target is supplied, the Actor uses one checked-in public DoorDash store URL as a bounded live example. Test fixtures are used only by the automated parser tests and cannot be selected through Actor input.
Output
Successful rows have recordType: "doordash-public-store-details" and include the public store ID/slug, name, location, address, phone, rating, review count, price range, cuisine, opening hours, menu metadata, bounded structured-data reviews, page metadata, extraction provenance, and timestamps when exposed. Blocked, failed, oversized, unsupported, or invalid targets are retained as diagnostics with exactly url, error, errorCode, and scrapedAt. The canonical OUTPUT_SUMMARY key-value record contains requested, successful, diagnostic, menu-item, review, transport, request, status, and completion metrics; OUTPUT remains as a backward-compatible copy. Operational request details stay out of normal dataset rows.
You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.
Run summary
OUTPUT_SUMMARY is the source of truth for run qualification. successfulTargetCount and diagnosticTargetCount reconcile with normal and diagnostic dataset rows; menuItemCount and reviewCount count bounded structured child records; transportCounts reports direct, Apify Proxy, and fixture target routes; and completedAt records completion. A blocked status means the public page returned a source boundary such as HTTP 403/429 or a security-verification page, while empty means no usable public store identity was exposed without a known boundary.
Usage and cost
Start with one official store URL, maxItems: 1, low retries, and a respectful request delay. Runtime cost grows with target count, response size, retries, and any Apify Proxy traffic. Review OUTPUT_SUMMARY before increasing limits.
FAQ
Does this Actor log in or bypass a challenge? No. It only requests the public DoorDash store page and reports access boundaries as diagnostics.
Can I use fixture data for production verification? No. Fixtures are restricted to local deterministic QA; Cloud qualification requires a live public page and a normal record whose sourceTransport is direct or apify_proxy.
Local QA
From this Actor directory:
npm ci --ignore-scripts --no-audit --no-fundapify validate-schemaAPIFY_LOCAL_STORAGE_DIR=./qa-storage apify run --purge --input-file test/inputs/default.jsonAPIFY_LOCAL_STORAGE_DIR=./qa-storage npm run validate
Use test/inputs/live.json with a public DoorDash store URL for a live boundary check. If direct access is blocked, a bounded cloud validation can set proxyConfiguration.useApifyProxy to true; proxy credentials are supplied by Apify and are never stored in input or output. A source-side HTTP 403/429 or security-verification page is reported explicitly as a diagnostic; it is not treated as successful extraction.