Orderli

Build a link to a restaurant's dashboard page — no data is fetched. Use this to hand the user a clickable destination when they want to *see* something in the dashboard, even if a data call wasn't approved or isn't needed. The returned ``url`` is ready to present as a markdown link. Marketplaces (food courts): to show every stand at once on the analytics page — e.g. "revenue or service fee per stand" — pass the marketplace parent's ``restaurant_id`` with ``page="analytics"``, ``locations=["all"]`` and ``per_location=True``. Args: restaurant_id: the restaurant (or marketplace parent) to link to. page: which page — one of analytics, orders, payments, menu, pos-items, settings, pos, payment-settings, api-tokens, devices, activity-log, account. Defaults to analytics. account_id: optional; resolved from restaurant_id when the page needs it. locations: analytics only — restaurant ids to pre-select in the location selector, or ``["all"]`` for every location in the account. per_location: analytics only — open the per-location breakdown. start: optional ``YYYY-MM-DD`` start date hint for the date range. end: optional ``YYYY-MM-DD`` end date hint for the date range.

get_dashboard_link

List delivery zones. Money fields are backend cents.

get_delivery_zones

Fetch the full text of a doc chunk or operation by its doc_id. Args: doc_id: an id from search_docs, e.g. "md:CLAUDE.md#3" or "op:get_...".

get_doc

Get the full OpenAPI operation (params, request/response schema, errors). Args: operation_id: e.g. "get_orders.get_orders" from search_endpoints.

get_endpoint

Get the POS import pipeline status (state, percent complete, timestamps). Args: restaurant_id: the restaurant whose import status to fetch. account_id: optional; resolved from restaurant_id if omitted.

get_import_status

Get a restaurant's Orderli menus, cards, categories, option groups and items. Menus are returned in full: every per-menu setting (text_alert, service_fee, takeaway, pickup_codes, custom_class, menu_times, ...) lives there. Other rows are projected to identifying fields; a row is active unless it says active:false. Only the first page carries menus, cards, categories and option groups; later pages and queries carry items. Args: restaurant_id: the restaurant whose menu to fetch. account_id: optional; resolved from restaurant_id if omitted. menu_id: scope to one menu and the cards/items it reaches. query: a term or list of terms; items whose name contains one or whose id equals one. unmatched lists terms that found nothing. ids: return these menus/cards/categories/items/option groups in full (translations, times, prices, linked ids) instead. detail: raw rows instead of projections. limit: max items per page (default 500). offset: skip this many items; see next_offset in the reply.

get_menu

Get the menu change history for a restaurant (newest first, paginated). Returns ``{page, page_results, total_results, data: [...]}``. Args: restaurant_id: the restaurant whose change log to fetch. account_id: optional; resolved from restaurant_id if omitted. page: 1-based page number. results: page size (default 50).

get_menu_changes

POS requests Orderli made while pushing one order to the POS. Returns ``{requests: [...]}``, newest first. Each entry has the ``service`` (e.g. ``mpluskassa``, ``untill``, ``lightspeed``), the ``endpoint`` hit, the ``request``/``response`` bodies, and the ``requested_at``/``responded_at`` timestamps. The first place to look when an order didn't reach the POS. Find the ``order_group_id`` via ``list_orders``. Request/response bodies are previewed (truncated, with ``request_truncated``/``request_length`` set) to keep the log small; pass ``request_id`` (an ``id`` from the list) to get that one entry with its full, untruncated bodies. Args: restaurant_id: the restaurant the order belongs to. order_group_id: the order group whose POS requests to fetch. request_id: return only this entry, with full request/response bodies. account_id: optional; resolved from restaurant_id if omitted. limit: max entries per page (default 50). offset: skip this many entries; see next_offset in the reply.

get_order_pos_requests

Order counts over time, bucketed by timeframe — the orders chart series. Args: restaurant_id: the restaurant to report on. start: start date, ``YYYY-MM-DD`` (inclusive). end: end date, ``YYYY-MM-DD`` (inclusive). timeframe: bucket size — ``hour``, ``day`` (default), ``week``, ``month``. account_id: optional; resolved from restaurant_id if omitted. limit: max buckets per page (default 500). offset: skip this many buckets; see next_offset in the reply.

get_orders_timeseries

Requests Orderli made to the POS/PSP while processing one "Payment". "Payments" are the pay-later product, which is being phased out — they are NOT the general order/transaction list. For an order's POS requests use ``get_order_pos_requests`` with an ``order_group_id`` from ``list_orders``; only use this tool for a legacy pay-later ``payment_id`` (taken from the dashboard's Payments page). Returns ``{requests: [...]}``, newest first, with the same shape as ``get_order_pos_requests``: ``service`` (e.g. ``ccv``, ``mollie``, ``stripe``, ``mpluskassa``), ``endpoint``, ``request``/``response``, and timestamps. Bodies are previewed; pass ``request_id`` to get one entry with its full, untruncated bodies. Args: restaurant_id: the restaurant the payment belongs to. payment_id: the pay-later payment whose requests to fetch. request_id: return only this entry, with full request/response bodies. account_id: optional; resolved from restaurant_id if omitted. limit: max entries per page (default 50). offset: skip this many entries; see next_offset in the reply.

get_payment_pos_requests

Payment volume over time: money collected through Orderli. ``results`` combines checkout orders paid online and pay-later bill payments (both including tips); ``payment_sources`` splits them into ``paid_order_groups`` and ``pay_later_payments``. Cash, invoice, external-terminal and test orders are excluded, so this is NOT total order revenue. For that use ``get_revenue_stats`` / ``get_revenue_breakdown`` / ``get_orders_timeseries``. Args: restaurant_id: the restaurant to report on. start: start date, ``YYYY-MM-DD`` (inclusive). end: end date, ``YYYY-MM-DD`` (inclusive). timeframe: bucket size — ``hour``, ``day`` (default), ``week``, ``month``. account_id: optional; resolved from restaurant_id if omitted. limit: max buckets per page (default 500). offset: skip this many buckets; see next_offset in the reply.

get_payments_breakdown

Read one receipt template's current config (HTML, CSS) with a digest. The ``digest`` is what edit_receipt_template requires as expected_digest — it names the version an edit was written against. digest_only returns just the digest and field lengths — a cheap way to ask "has it changed?" without pulling the markup again.

get_receipt_template

Read a restaurant's Custom CSS, and nothing else. Returns the stylesheet with a ``digest`` of its contents, which ``edit_restaurant_css`` requires — it is how an edit says which version it was written against. Args: restaurant_id: the restaurant whose stylesheet to read. account_id: optional; resolved from restaurant_id if omitted. digest_only: return just the digest and length — a cheap way to ask "has it changed?" without pulling the sheet again.

get_restaurant_css

Get the full configuration for a restaurant. Includes POS integration fields, payment settings, opening times, service config, locale/currency, feature flags, and more. Args: restaurant_id: the restaurant to inspect. account_id: optional; resolved from restaurant_id if omitted.

get_restaurant_config

Revenue and sales volume per dish, option, menu, table or area over a date range (YYYY-MM-DD, inclusive), biggest revenue first. For best sellers / items sold / quantity per dish use per_dish: quantity_sold is units, not orders. per_option_chosen lists paid options only. Menu, table and area rows count orders. Rows: {id?, label, revenue, quantity_sold|orders}; page with offset (next_offset).

get_revenue_breakdown

Revenue summary cards for a date range (total revenue, order count, tips, average order value, …) with the previous-period comparison. Args: restaurant_id: the restaurant to report on. start: start date, ``YYYY-MM-DD`` (inclusive). end: end date, ``YYYY-MM-DD`` (inclusive). account_id: optional; resolved from restaurant_id if omitted.

get_revenue_stats

The order groups settled in a specific payout/settlement (paginated). Args: restaurant_id: the restaurant the payout belongs to. payout_id: the settlement/payout id (see get_restaurant reports). page: 1-based page number. page_size: items per page (default 100, max 1000). account_id: optional; resolved from restaurant_id if omitted.

get_settlement_orders

Open a real Orderli guest URL, call guest /init + /menu, and return compact visible IDs. Use a URL returned by setup_qr or list_guest_entrypoints when available. Restaurant ids and menu ids are not guest URL path segments. In auto/readiness mode, ordering sessions return required next steps. A 404, guest_error, or api_error means guest readiness is blocked.

inspect_guest_menu_entrypoint

List the API tokens configured for a restaurant (names + permissions). Args: restaurant_id: the restaurant whose tokens to list. account_id: optional; resolved from restaurant_id if omitted.

list_api_tokens

POS requests Orderli made while importing the menu/catalog from the POS. Returns ``{requests: [...]}``, newest first, each with ``service``, ``endpoint``, ``request``/``response`` and timestamps. Reach for this when a menu import failed or pulled in the wrong items. Unlike the order/payment request logs this is restaurant-wide — no order or payment id needed. Import payloads are large, so bodies are previewed; pass ``request_id`` to get one entry with its full, untruncated bodies. Args: restaurant_id: the restaurant whose import requests to fetch. request_id: return only this entry, with full request/response bodies. account_id: optional; resolved from restaurant_id if omitted. limit: max entries per page (default 50). offset: skip this many entries; see next_offset in the reply.

list_pos_import_requests

List the POS's own items, the layer menu items map onto. pos_id is the POS's id: a menu item's pos_id must equal it. pos_item_id is Orderli's row id for the POS item, never a POS id. Args: restaurant_id: the restaurant whose POS items to list. account_id: optional; resolved from restaurant_id if omitted. query: a term or list of terms (resolve many dishes in one call); each matches a name substring or an exact pos_id/pos_item_id. unmatched lists terms that found nothing. options: add each row's option groups and their options. limit: max rows per page (default 100). offset: skip this many rows; see next_offset in the reply.

list_pos_items

List the payment methods the POS exposes for a restaurant. Args: restaurant_id: the restaurant whose POS payment methods to list. account_id: optional; resolved from restaurant_id if omitted.

list_pos_payment_methods

Return candidate public guest URLs; discovery only, not verification. Reads restaurant database_name and QR codes so agents do not invent URL shapes. For readiness, inspect a returned URL, probe checkout if relevant, then browser-test.

list_guest_entrypoints

One page of order groups for a restaurant (newest first). Returns ``{page, page_results, total_results, data: [...]}``. Each row is a slim summary by default; pass ``detail=True`` for the full order group. Use the filters to narrow, or ``export_orders`` to pull a whole date range at once. Args: restaurant_id: the restaurant whose orders to list. start_date: filter from this date, ``YYYY-MM-DD`` (optional). end_date: filter to this date, ``YYYY-MM-DD`` (optional). page: 1-based page number. results: page size (default 100, max 100). payment_status: filter by status (e.g. ``success``, ``open``, ``failed``). payment_method: filter by method (e.g. ``ideal``, ``card``, ``cash``). order_type: filter by type (``normal``, ``delivery``, ``takeaway``, ``takeaway_onsite``, ``kiosk``). has_tip: only orders that include a tip. has_coupon: only orders that used a coupon. detail: return the full order group instead of the slim summary. account_id: optional; resolved from restaurant_id if omitted.

list_orders

Read recent receipt render attempts for debugging a misprint. Each row records whether a tablet render of an order succeeded, which template/version it used, and any templating error. Filter by template_id, order_group_id, or only_failures to find what went wrong after the fact.

list_receipt_render_logs

List a restaurant's receipt templates (name, ticket type, publish state).

list_receipt_templates

Render a template against a sample or a real order and return the HTML. Use this to check how order data flows through the layout before publishing. Pass order_group_id to render a real order from this restaurant; otherwise sample_key picks a built-in sample (the response lists the available ones; omit both for the default multi-group sample). Search real orders with search_orders_for_receipt_preview.

preview_receipt_template

Publish a template version so tablets start printing it (WRITE). Defaults to the latest draft version. Publishing runs a render gate against sample orders; a template that cannot render is refused rather than made live, so printing never breaks.

publish_receipt_template

Resolve a restaurant_id to its owning account_id (plus basics). The Orderli dashboard API is **account-first**: almost every path is nested under ``/accounts/{account_id}/...``, so a bare restaurant id is not enough to build one. There is no ``/restaurants/{id}`` collection to guess at. Call this first when all you have is a restaurant id — it hands back the ``account_id`` every other tool needs. Returns id, name, account_id, account_name and pos_integration, plus a dashboard deep link. Prefer this over guessing restaurant-first paths. Args: restaurant_id: the restaurant to resolve.

resolve_restaurant

Read every QR code in an image and return the data each one encodes (READ). A standalone reader with no knowledge of Orderli: give it the URL of an image — e.g. an uploaded photo of a QR sticker — and it returns the exact text/URL each QR code contains. It does not act on the result; you decide what to do with the values. For an Orderli table sticker that means passing the decoded URL to setup_qr. A photo containing several stickers returns several codes. Decoding is expensive, so this is rate limited.

scan_qr

Search Orderli docs and API operations by keyword. Args: query: natural-language or keyword query. max_results: max hits to return. source: optionally restrict to "markdown" or "openapi".

search_docs

Search available API operations by keyword (path, summary, tags). Returns matching operationIds with method + path. Use get_endpoint for the full request/response schema.

search_endpoints

Find real orders to preview a template against (id, table, pickup, name). Matches order id, table number, pickup code or guest name; empty query returns the most recent orders. Feed an id to preview_receipt_template's order_group_id.

search_orders_for_receipt_preview

Set or clear a kiosk QR's fixed eat-in/take-away choice (WRITE).

set_qr_kiosk_dine_choice

Set when a card (section group) is visible and orderable (WRITE). A card has two independent schedules: - visibility_windows: when guests can SEE the card. - ordering_windows: when guests can ORDER from it. Omit to match visibility. Make ordering NARROWER than visibility for "view-only until X" — e.g. a breakfast card visible from 08:00 but only orderable 08:00-11:00, or a whole menu you can browse before it opens. Each window is {"days": "all", "weekdays", "weekends", "mon-fri", a day name/list of names, or 0-6 where Mon=0; "start": "HH:MM", "end": "HH:MM"}. Prefer day names/ranges over numeric days.

set_card_schedule

Open or close guest delivery for whole day(s) (WRITE). Delivery capacity is driver-backed, so this creates or removes a 'close' capacity override on the restaurant's delivery driver resource. Use it for requests like "my driver called in sick, close delivery tomorrow" rather than editing menus, zones or ordering settings. `available` is required: False closes delivery, True reopens it (removes the matching close override). Give the day as either `date` (YYYY-MM-DD) or `days_from_today` (0 = today, 1 = tomorrow) so you never have to know the calendar date; `end_date` (YYYY-MM-DD, inclusive) spans a multi-day range. Days are resolved in the restaurant's own timezone. Takeaway and dine-in are unaffected.

set_delivery_availability

Set the ordered children of one or many menu containers (WRITE). links maps each parent id to its child ids in display order, e.g. {"178143": [11248, 11257], "178145": []}. Each list replaces that parent's whole set ([] clears it); parents left out are untouched. Children must already exist (upsert_* tools). parent_type is one of "menu.cards", "card.categories", "category.items", "item.option_groups" (option-group ids), "option_group.items" (item ids).

set_menu_links

Enable or disable a feature flag for a restaurant (WRITE). Upserts the restaurant↔flag link (creating it if needed, un-deleting it if it was removed). Requires ORDERLI_ALLOW_WRITES and a write-scoped token. Args: restaurant_id: the restaurant to toggle the flag on. flag: the flag slug (e.g. "rootline_checkout_components") or its numeric id. enabled: True to enable (default), False to disable. account_id: optional; resolved from restaurant_id if omitted.

set_restaurant_feature_flag

Register an existing printed QR sticker for table/takeaway/delivery/kiosk (WRITE). Needs the sticker's code: pass qr_link (the URL it encodes) or code; it cannot mint one. For takeaway/delivery ordering without a sticker use the URLs from list_guest_entrypoints. area can create/use an area and colour the QR. Returns candidate guest URL(s), not readiness evidence.

setup_qr

Fill in a menu's other languages with Orderli's AI translator (WRITE). Orderli has a menu-tuned translation SPECIALIST behind this — strongly prefer it over hand-translating rows. Build the whole menu in the single language you actually have (source_language), then call this once to add every target language across all items, categories and cards. This is the right way to get a bilingual menu — do NOT paste one language's text into another language's fields. Runs as an async job and may take a minute or two on a large menu; this tool waits for it and applies the result. If it is still running when the wait budget is up, it returns a job_id — call translate_menu again with that job_id to resume waiting and apply. only_add_missing=True (default) only fills empty translations and never overwrites text you wrote. entity_types defaults to ["item","category","card"]. account_id resolves from restaurant_id when omitted.

translate_menu