DoorDash is a site where the cheapest fetch is also the best one. On 28 September 2026 we fetched doordash.com through residential exits in the United States and Canada. A plain HTTP client, no JavaScript, got 200 OK and 485 words on the first request from the US and 544 from Canada; a store page got 2,951,645 bytes and 1,087 words of menu and prices the same way. That is the setting for DoorDash proxies: residential, plain HTTP, US exit, and no browser at all.
The search result is about the wrong kind of proxy
Search DoorDash proxies from the US and Google mostly answers a question about corporate governance. Rank one is DoorDash's definitive proxy statement on the SEC filings page, rank seven is the SEC index, and the related searches are 10-K, annual report and investor presentation. Between them sit an engineering post about DoorDash's Envoy-and-Valkey proxy cache serving 1.5 million requests a second, a Reddit thread about routing the Dasher app through a proxy, and two vendor pages.
Autocomplete tells the real story. Proxies for DoorDash returns nothing; DoorDash scraper returns menu scraper, scrape DoorDash data, scrape DoorDash menu. The buyer is not looking for an IP, they are looking for rows: restaurants, menus, prices, delivery fees by city. So the question this post answers is what DoorDash hands a proxied client, and what it costs to turn that into rows.
Plain HTTP gets the homepage on the first request
We audited doordash.com from a US residential exit with no cookies and no Accept-Language header, then again from a Canadian one.
| Fetch | Exit | Status | Bytes | Words | Seconds |
|---|---|---|---|---|---|
| Homepage, plain HTTP | United States | 200 | 2,025,194 | 485 | 18.1 |
| Homepage, plain HTTP | Canada | 200 | not weighed | 544 | 6.4 |
| Store page, plain HTTP | United States | 200 | 2,951,645 | 1,087 | 5.3 |
| robots.txt | United States | 200 | 2,245 | 19 sitemaps | 1.1 |
The homepage response is a two-megabyte Next.js document with the canonical, the title, the description, an h1 of "$0 DELIVERY FEE ON FIRST ORDER" and 485 words of navigation, city links and marketing copy. There is no JSON-LD on the home. It is a large page for what it says, but every one of those bytes arrives on a plain request, which is what matters when you are choosing whether to pay for a browser.
The Canadian fetch is the geo point. Same URL, same 200, 544 words instead of 485, and the title changes its punctuation: a hyphen between "Retail" and "Fast Same Day Delivery" from the US, an em dash from Canada. That is a different template being served off the exit IP alone. A parser keyed on the exact title string, or a diff that treats the two as the same page, will misfire quietly. Pin the exit to the market you are measuring and compare like with like.
Store pages carry the menu, and they are the cheapest way to read it
The page that matters for pricing is the store page. We fetched /store/polvos-mexican-restaurant-austin-25522607/ over plain HTTP from a US exit and received 2,951,645 bytes and 1,087 extractable words: the title "Order Polvos Mexican Restaurant - Austin, TX Menu Delivery [Menu & Prices]", the description with the street address and the first-order delivery-fee line, and thirteen headings of menu sections with items and prices under them.
Read that against what most guides tell you. The standard advice for a JavaScript site is to render it. On DoorDash the plain response already contains the menu, and rendering is the one mode we do not recommend: our residential exit plus plain HTTP returned 485 and 1,087 words on the first request, with the fee and the menu in the HTML, and that is the setting. Telling you to skip the browser is telling you to spend less, which is the reason to believe the rest of this page.
The related trap is the bandwidth calculator ranking on the SERP, which quotes 2.32 MB per GET for doordash.com listings. Our homepage weighed 2.03 MB and the store page 2.95 MB, so the order of magnitude is right. The conclusion drawn from it is not: on our line the homepage costs $0.00162 and the store page $0.00236 in bandwidth, and neither needs a rendered session.
The collector returns rows where the page returns HTML
Two megabytes of HTML per restaurant is the wrong shape for a dataset. For that we ran the DoorDash restaurants collector once, with the input "Austin, TX" and nothing else, on the same afternoon.
| Run | Input | Rows | Seconds | Price per row |
|---|---|---|---|---|
| doordash_restaurants | Austin, TX | 50 | 5.98 | $0.001 |
Each of the 50 rows carries the store id, name, rating, an exact review count, cuisine, price band, street address and the store URL. The exact counts are the detail worth paying for: the page shows a rounded figure, the row shows 24,149 reviews for The Cheesecake Factory, 10,774 for True Food Kitchen, 66 for a seafood bar that opened recently. One of the 50, Jasmines Restaurant in Del Valle, carries no rating at all, and the collector keeps it rather than dropping it, so your count of restaurants is the count of restaurants.
The collector reads DoorDash's own schema.org list for the city, one page per city, and takes a cuisine argument to reach beyond the first page. Fifty rows cost $0.05. Fetching the same fifty store pages yourself over the proxy is 147,582,250 bytes, $0.118 in bandwidth, and a parser to maintain. Where the job is a list of restaurants with ratings and addresses, the collector is cheaper and faster; where the job is one restaurant's full menu, the store page over plain HTTP is the right fetch.
What robots.txt and the Terms close off
doordash.com/robots.txt is 2,245 bytes. The wildcard agent is kept out of orders and order history, the consumer and Dasher account paths, the cart and group-cart flows, /product/*, /browse/products/*, /s/* search results, gift pages and team invites. ia_archiver is disallowed entirely; Googlebot and Googlebot-image are allowed everything. Then come 19 sitemap indexes: stores, businesses, business menus, cities, city-by-cuisine, dishes, products, and Spanish-US and French-Canadian variants of the city sitemaps.
The sitemap list is the map of what DoorDash publishes for crawlers, and it is where the store URLs we fetched come from. The disallow list is the map of what it does not want scripted: accounts, carts, product search. Stay on the store, city and cuisine pages and you are on the paths the file publishes.
The consumer Terms and Conditions, clause (p), state that you will not collect content or data from the Services using automated means unless DoorDash has given prior written permission. That is a contractual line, not a technical one, and it is the same line Meta draws on Facebook. Reading the pages the site serves anonymously is a technical fact; permission is DoorDash's to give, and we do not pretend a residential IP changes that. Nothing here is about Dasher accounts, promotions or deactivations, which are identity-bound and outside what a network layer can touch. For the US legal ground, see is web scraping legal in the US.
The cost of a DoorDash page on residential bandwidth
Every fetch here went through residential proxies on the Basic line at $0.80/GB. Counting a gigabyte as 10^9 bytes:
| Job | Bytes per request | Requests per GB | Cost per request |
|---|---|---|---|
| Homepage, plain HTTP (485 words) | 2,025,194 | 493 | $0.00162 |
| Store page, plain HTTP (1,087 words, menu and prices) | 2,951,645 | 338 | $0.00236 |
| 50 restaurants from the collector | none billed as bandwidth | n/a | $0.05 per run |
A thousand store pages is $2.36 of bandwidth and about a gigabyte and a half. That is the whole cost of reading a thousand menus, because no browser session is involved. The datacenter line at $0.50/GB would cut it to $1.48, but the vendor page ranking on this SERP measured 50 datacenter-class free proxies against the front door and reported none reaching the site; the residential exit is the one that returned the page on the first request in our run, so the extra 30 cents buys the response. Mobile at $2.30/GB buys nothing we could measure.
The setting that works on DoorDash
- Network: residential proxies, Basic line, $0.80/GB. The homepage and a store page both answered the first plain request from a residential exit with 200 and the full content.
- Fetch mode:
engine: tls, never rendered. Plain HTTP returned 485 words on the homepage and 1,087 words of menu and prices on a store page; the browser adds cost and nothing else on this site. - Country: pin
country=usfor US stores. The same URL from a Canadian exit returned a different template, 544 words instead of 485, with a different title string; the exit decides which market's page you get. - When the proxy is not enough: the DoorDash restaurants collector returned 50 restaurants for Austin, TX in 5.98 seconds with exact review counts, at $0.001 a row, one page per city and a cuisine filter to go deeper. For a UK sibling of the same company that behaves the opposite way, see Deliveroo proxies.
- The free tier is real: every account gets $2 of free API usage per month, which is 2,000 collector rows or 10,000 plain page fetches through the web scraping API before you pay anything.