Whitelabel Ordering

Show the restaurant's menu to the user as a visual HTML document — a horizontally-scrollable category strip with item photos, names and prices. Present the returned HTML by opening it as an HTML artifact; do NOT paste the markup into the chat as text. (Ordering does not require this — prepare_order resolves item names on its own.)

Resolve a natural-language food order (one or more items) to concrete menu items and return a summary plus a confirmation token. Does NOT place the order. Call place_order with the returned token to actually place it. Delivery is as soon as possible by default; pass 'date' to ask for a later time instead. Each call covers one delivery, so an order for more than one day means one call per day. The

Place an order previously staged by prepare_order. Requires the confirmationToken returned by prepare_order. This causes a real order to be sent to the vendor.

Check the current status of an order the user has already placed, using the order number returned by place_order. Reports whether the restaurant has accepted it, whether it is on its way, and whether it has finished (delivered or declined). There is no background tracking and no notification: call this again when the user asks, and only until the order is reported as finished.

Find restaurants (vendors) available for ordering. This is the discovery entry point: each card shows the clientId and vendorId that list_menu and prepare_order need. Call it with no arguments to list every restaurant — that is the normal case. Returns a complete, self-contained HTML document of vendor cards (logo, address, phone, delivery fee) — restaurants open today first in colour, those close

Start signing the user in to a restaurant so they can place orders. Browsing the menu never needs this — only ordering and saving an address do. Returns a URL the user must open in a browser to sign in with Google or Apple; afterwards they copy the 'code' value from the address bar and you call submit_login_code. Each restaurant has its own login, so this must be done per restaurant.

Sign the user out. By default signs out of every restaurant; pass a clientId to sign out of one, and an account label to sign out just that account.

Complete a sign-in started by login, using the 'code' value the user copied from the browser address bar. On success the user can place orders from that restaurant.

Show which accounts are signed in, per restaurant, and which one is active. Useful when the user keeps separate work and personal accounts.

Choose which signed-in account to order with at a restaurant, e.g. to switch between work and personal. The account must already be signed in via login.