DoorDash dish & item search API

Endpoint facts

Method

GET

API path

/doordash/search/items

Auth

apiKey

Credits

1 credit/request

Platform

DoorDash

Response schema

#/definitions/doordash.searchItemsResponseDoc

Overview

Searches menu items across nearby merchants from the Android mobile guest experience. Nearby candidate stores are selected first, then their menus are read and every item whose name or description matches the query is returned with its parent store. At most five proximity-ranked stores are inspected per request, and a store whose menu cannot be read is skipped, so results are best-effort across that candidate set. An empty result array means no candidate store menu matched, not that no nearby merchant sells the item. No DoorDash account or caller-supplied token is required. Developers commonly use this endpoint for data enrichment, monitoring, research dashboards, internal automation, and agent-native workflows that need repeatable structured public web data. Authentication uses the documented Crawlora headers, and usage is metered with the credit cost shown on this page.

Authentication

Send your scraping API key in the x-api-key header. Use the console API Keys page to rotate or select the active key.

Billing

Endpoint usage is metered in credits. The plan prices, included credits, limits, and overage rates below match the active backend billing configuration.

Credit cost

1 credit/request

Charged response

Successful 2xx responses

Infrastructure behavior

This endpoint is executed through Crawlora's managed scraping infrastructure.

• Proxy strategy: managed automatically where needed
• Browser rendering: enabled for supported targets that require rendered HTML or JavaScript execution
• Browser cluster: supported dynamic workloads can be routed through distributed browser instances
• Retry behavior: automatic retry/fallback may be used depending on endpoint type
• Challenge handling: challenged pages or unusable upstream HTML are detected and surfaced clearly when they cannot be used
• Billing: credits are charged only for successful 2xx responses
• Observability: responses include request context where available

Response behavior

The query first selects nearby candidate stores, then each of those stores' menus is read and every item whose name or description contains the query text is returned with its parent store's identity and distance. Because candidate stores come from the same upstream-capped catalog that backs `/doordash/search`, at most five stores are inspected per request, ranked by proximity. A store whose menu cannot be read is skipped rather than failing the request, so results are best-effort across the candidate set. An empty `results` array means no nearby candidate store's menu matched the query; it is not evidence that no merchant nearby sells the item. `itemId` is not populated: DoorDash's anonymous menu surface exposes no stable per-item identifier. Use `name` together with `storeId` against `/doordash/store/{store_id}/item/{item_id}`. Missing required parameters return `400`. Example response: ```json {"code":200,"msg":"OK","data":{"query":"duck","results":[{"name":"Roasted Duck","description":"With duck sauce","price":"$22.99","storeId":"26282644","storeName":"Eats","distance":"1.2 mi"}]}} ```

Error behavior

Crawlora does not silently return bad data when the upstream page cannot be used.

When possible, Crawlora returns structured error context so your integration can retry, back off, or inspect the request.

Related