DoorDash Store Details Scraper avatar

DoorDash Store Details Scraper

Pricing

from $2.99 / 1,000 store details

Go to Apify Store
DoorDash Store Details Scraper

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

w3crawler

Maintained by Community

Actor 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-fund
apify validate-schema
APIFY_LOCAL_STORAGE_DIR=./qa-storage apify run --purge --input-file test/inputs/default.json
APIFY_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.