🛵 ordercli — Your takeout timeline, in the terminal.

Providers:

• foodora (working)
• deliveroo (work in progress; requires DELIVEROO_BEARER_TOKEN)
• ubereats (browser-session backed; web account pages)

Concepts (shared CLI UX; provider-specific implementations):

• history (past orders)
• orders (active orders)
• order / history show (details)

Config lives in your OS config dir by default; override for testing:

./ordercli --config /tmp/ordercli.json foodora config show

Build

go test ./...
go build ./cmd/ordercli

foodora

Configure country / base URL

Bundled presets (from the APK):

./ordercli foodora countries
./ordercli foodora config set --country HU
./ordercli foodora config set --country AT
./ordercli foodora config show

Manual:

./ordercli foodora config set --base-url https://hu.fd-api.com/api/v5/ --global-entity-id NP_HU --target-iso HU

Login

oauth2/token needs a client_secret (the app fetches it via remote config). ordercli auto-fetches it on first use and caches it locally.

Optional override (keeps secrets out of shell history):

export FOODORA_CLIENT_SECRET='...'
./ordercli foodora login --email you@example.com --password-stdin

If MFA triggers and you're running in a TTY, ordercli prompts for the OTP code and retries automatically. Otherwise it stores the MFA token locally and prints a safe retry command (--otp <CODE>).

Client headers

Some regions (e.g. Austria/mjam mj.fd-api.com) expect app-style headers like X-FP-API-KEY / App-Name / app User-Agent. ordercli uses an app-like header profile for AT by default.

For corporate flows, you can override the OAuth client_id:

./ordercli foodora login --email you@example.com --client-id corp_android --password-stdin

Cloudflare / bot protection

Some regions (e.g. Austria/mjam mj.fd-api.com) may return Cloudflare HTML (HTTP 403) for plain Go HTTP clients.

Use an interactive Playwright session (you solve the challenge in the opened browser window; no auto-bypass):

./ordercli foodora login --email you@example.com --password-stdin --browser

Prereqs: node + npx available. First run may download Playwright + Chromium.

Tip: use a persistent profile to keep browser cookies/storage between runs (reduces re-challenges):

./ordercli foodora login --email you@example.com --password-stdin --browser --browser-profile "$HOME/Library/Application Support/ordercli/browser-profile"

Import cookies from Chrome (no browser run)

If you already solved bot protection / logged in in Chrome, you can import the cookies for the current base_url host:

./ordercli foodora cookies chrome --profile "Default"
./ordercli foodora orders

If the bot cookies live on the website domain (e.g. https://www.foodora.at/), import from there and store them for the API host:

./ordercli foodora cookies chrome --url https://www.foodora.at/ --profile "Default"

If you have multiple profiles, try --profile "Profile 1" (or pass a profile path / Cookies DB via --cookie-path).

Import session from Chrome (no password)

If you’re logged in on the website in Chrome, you can import refresh_token + device_token and then refresh to an API access token:

./ordercli foodora session chrome --url https://www.foodora.at/ --profile "Default"
./ordercli foodora session refresh --client-id android
./ordercli foodora history

If session refresh errors with “refresh token … not found”, that site session isn’t valid for your configured base_url (common for some regions).

Orders

./ordercli foodora orders
./ordercli foodora orders --watch
./ordercli foodora history
./ordercli foodora history --limit 50
./ordercli foodora history show <orderCode>
./ordercli foodora history show <orderCode> --json
./ordercli foodora order <orderCode>
./ordercli foodora logout

Reorder (add to cart)

Safe default (preview only):

./ordercli foodora reorder <orderCode>

Actually call orders/{orderCode}/reorder (adds to cart; does not place an order):

./ordercli foodora reorder <orderCode> --confirm

If you have multiple saved addresses, you must pick one:

./ordercli foodora reorder <orderCode> --confirm --address-id <id>

deliveroo (WIP)

history still requires a valid bearer token. orders can now fall back to a public Deliveroo status/share page from your local browser history.

export DELIVEROO_BEARER_TOKEN='...'
export DELIVEROO_COOKIE='...' # optional
./ordercli deliveroo config set --market uk
./ordercli deliveroo history
./ordercli deliveroo orders # bearer-token path if set
./ordercli deliveroo orders --browser atlas
./ordercli deliveroo orders --status-url 'https://deliveroo.co.uk/orders/.../status?...'

orders looks for the most recent Deliveroo status URL in Atlas or Chrome history when no bearer token is present, then renders the page in headless Chromium and extracts the order details.

ubereats (browser-session backed)

ordercli currently uses the logged-in Uber Eats web experience instead of a documented public consumer API. The first step is to create a persistent browser profile and sign in once:

./ordercli ubereats config set --browser-profile "$HOME/Library/Application Support/ordercli/ubereats-profile"
./ordercli ubereats login

After that:

./ordercli ubereats orders list
./ordercli ubereats orders list --filter past --limit 10
./ordercli ubereats orders show <orderUuid>
./ordercli ubereats logout --yes

Notes:

• login opens a real Playwright Chromium window and waits until you land on an Uber Eats orders page.
• login verifies the authenticated session and stores the CLI-managed browser profile plus user agent.
• orders reuses the CLI-managed browser profile to extract fresh session cookies, then talks to the Uber Eats JSON endpoints over plain HTTP.
• Hidden compatibility aliases for history, order, and login --browser still exist for older scripts.
• If you are not signed in, commands fail with a prompt to run ordercli ubereats login.

Safety

This talks to private APIs. Use at your own risk; rate limits / bot protection may block requests.