ddREST
Provides a RESTful interface to DoorDash consumer services, including browsing restaurants, managing carts and orders, and retrieving receipts, with session-based authentication and token renewal.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ddRESTfind restaurants in San Francisco"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ddREST
A REST implementation of the DoorDash Consumer MCP server.
The gateway speaks JSON-RPC 2.0 over Server-Sent Events and describes itself
through MCP's tools/list. ddREST puts conventional REST resources in front of
that: GET /v1/restaurants, POST /v1/carts/{cart_uuid}/items,
GET /v1/orders/{order_uuid}/receipt. Clients never see JSON-RPC, SSE, or the
intent argument every tool requires.
Inspired by dd-cli, DoorDash's
own terminal client for the same gateway. ddREST is an independent
implementation.
Two problems shape the whole design:
DoorDash only permits loopback OAuth callbacks (
http://localhost:4180…, ports 4180–4184). A server-hosted API can never receive the redirect, so login is a paste-back flow.DoorDash rotates refresh tokens with no grace period. Every renewal invalidates the previous refresh token immediately, so tokens are stored server-side — encrypted under a key that exists only in the client's credential, so the database alone reveals nothing.
Built on Bun + Hono. Monetary values are in cents throughout.
Quick start
bun installbun run keygenPut that line in .env (see .env.example), then:
bun run devThen browse the API at http://localhost:8787/docs. Complete the login flow below once and Try it out works on every endpoint from that page.
Related MCP server: DoorDash MCP Server
Docker
Images are published to GitHub Container Registry for linux/amd64 and
linux/arm64.
docker run -d --name ddrest -p 8787:8787 \
-e SESSION_KEYS="$(openssl rand -base64 32)" \
-v /path/to/appdata:/data \
ghcr.io/larveyofficial/ddrest:latestSESSION_KEYS is the only required setting. openssl rand -base64 32 produces
exactly the format it wants, so no Bun install is needed to generate one.
The container starts as root only to fix ownership of /data, then drops to
PUID:PGID (default 1000:1000). Pass --user instead if you would rather
pin it yourself — the entrypoint handles both.
Setting | Default in image | Notes |
| (none) | Required. Container exits with instructions if unset. |
|
| Overridden from the |
|
| Mount |
|
| Ownership of |
| (derived) | Set it behind a reverse proxy — device pairing prints this address for a human to visit. |
|
|
|
Cookies over plain HTTP. COOKIE_SECURE defaults to true, so a browser
reaching this over http://host:8787 will silently drop the session cookie.
Set COOKIE_SECURE=false for LAN-only HTTP, or put it behind a reverse proxy
with TLS and leave it alone. Bearer tokens work either way.
Unraid
unraid/my-ddREST.xml is a Community-Applications-style
template. Copy it to /boot/config/plugins/dockerMan/templates-user/ on your
server, then Docker → Add Container and pick ddREST from the template
dropdown.
Generate the key on the Unraid terminal first:
openssl rand -base64 32Paste that into SESSION_KEYS. The template defaults PUID/PGID to 99/100
and COOKIE_SECURE to false, which is what LAN-only HTTP access needs; the
rest is optional and hidden under Advanced. The WebUI button opens /docs.
The template ships no icon. Drop a PNG somewhere reachable and add an <Icon>
element if you want one in the Docker tab.
Logging in
DoorDash only permits loopback OAuth callbacks, so this server cannot receive the redirect. Log in once by pasting it back:
curl -sX POST http://localhost:8787/v1/auth/login/startOpen the authorize_url it returns and sign in. You land on
http://localhost:4180/oauth2/callback?code=…&state=… and the page fails to
load — that is expected, the URL in the address bar is the payload. Send it back
with the ticket:
curl -sX POST http://localhost:8787/v1/auth/login/complete \
-H 'content-type: application/json' \
-d '{"login_ticket":"ddl1.…","redirect_url":"http://localhost:4180/oauth2/callback?code=…&state=…"}'You get a session_token back and a dd_session cookie is set. That is the
last login you need until the session's hard expiry, 30 days later by default —
the tokens renew themselves in between.
Signing in something with no usable browser, like a TV or a headless box? See Device pairing.
Full walkthrough: Logging in.
Documentation
Browse the live API at /docs on your own instance — Swagger UI generated
from its own route definitions, so it always matches the version you are
running. The raw document is at /openapi.json.
Everything else is in the wiki:
Page | What is in it |
The paste-back OAuth flow in full, and why it works that way. | |
RFC 8628-style pairing for devices with no browser. | |
Silent renewal, session lifetime, what is stored and what protects it. | |
Every route and its tool, locations, optional parameters, errors, response shapes. | |
Tests and a map of the source. |
Disclaimer
ddREST is not affiliated with, endorsed by, or supported by DoorDash. It is an independent project. Nothing here is official, and DoorDash provides no support for it.
Access to the MCP server is gated by DoorDash. It is waitlist-only and requires an approved DoorDash account — see doordash-oss/doordash-cli for the waitlist and for DoorDash's own client. ddREST neither grants nor bypasses that gating: it authenticates as you, using your own account, and does nothing you could not already do through DoorDash's client. Without an approved account it will not work at all.
Your use of ddREST is still governed by DoorDash's terms. Those terms define
"the CLI" to include the authentication tokens, not just the binary — so
authenticating through this project puts you squarely under DoorDash's CLI
Access Terms of Service, together with the Consumer Terms of Service and Privacy
Policy they incorporate. The CLI Terms ship with the dd-cli download. They
cover, among other things, personal and non-commercial use, acting only on your
own account, and limits on retaining or reusing data obtained through the CLI.
Read them and satisfy yourself that your intended use complies. That responsibility is yours, not this project's, and nothing in this README grants permission DoorDash has not.
Provided as-is, without warranty of any kind.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to discover and order food from multiple delivery services (DoorDash, UberEats, Grubhub) using A2A protocol and process payments via Stripe with AP2 protocol mandates for cryptographically signed user authorization.1MIT
- FlicenseBqualityDmaintenanceEnables AI agents to search restaurants, browse menus, and manage DoorDash carts through structured JSON data. It leverages a background browser to handle authentication and direct GraphQL API calls for efficient interaction.72
- FlicenseBqualityDmaintenanceEnables AI agents to search restaurants, browse menus, manage carts, and place orders on DoorDash programmatically. It utilizes a headless browser to interact with DoorDash's GraphQL API and bypass anti-bot protections for the full delivery lifecycle.222
- AlicenseAqualityAmaintenanceOrder food on DoorDash — search stores, compare real fee-included totals from live quotes, and build carts; placing an order always requires a human approval dialog (fail closed without elicitation). Local macOS server driving DoorDash's official dd-cli.2992MIT
Related MCP Connectors
AI food ordering across Canada — 17,000+ restaurants, 89 cities, real UberEats + DoorDash.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
A paid remote MCP for ShipSwift, built to return verdicts, receipts, usage logs, and audit-ready JSO
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LarveyOfficial/ddREST'
If you have feedback or need assistance with the MCP directory API, please join our Discord server