A restaurant that runs iiko has already typed its menu once. Typing it a second time into a QR menu â and then keeping both in step every time a price moves â is work nobody asked for, and the first thing that slips when the kitchen is busy.
QRmenu now talks to iiko directly through its Cloud API. The menu arrives from the till, prices and availability follow it on their own, and guests can send their basket to the kitchen from the table they are sitting at.
What the integration does
- Imports the menu: categories, dishes, descriptions, prices, portion sizes, serving hours such as a 12:00â16:00 lunch, and allergen groups
- Keeps prices identical to the till â a price raised in iiko reaches guests without anyone opening the editor
- Brings the stop list to the guest: a dish the kitchen takes off goes dark in the menu, separately for each branch
- Moves photos already stored in iiko into your own menu in one click
- Updates itself: iiko reports a change as it happens, so there is no schedule to remember and nothing to run by hand
- Optionally lets guests send their basket straight to the till, to the table their QR code names
What the till owns, and what stays yours
The split is deliberate and it does not move. iiko owns price, availability and which dishes exist â it is the system your staff already work in, and the one the kitchen trusts. Everything you built on top in QRmenu stays yours: translations into Armenian, Russian and English, dish photos, tags, recommendations and the menu's design. A sync never overwrites them.
A dish you remove from iiko is not deleted from QRmenu. It is hidden from guests and kept with its photo and translations, so putting it back on the till brings it back to the menu as it was. Nothing you paid a photographer for is lost because a seasonal dish went away for a month.
Guests can order from the table
With ordering turned on, the basket a guest fills while reading the menu can go straight to the till. Print one QR code per table and the order arrives on the right table by itself; without a per-table code the guest picks their table in the basket.
The order arrives open and unpaid, exactly as if a waiter had entered it, and it is closed at the till the usual way. Nothing about payment or your cash discipline changes. Prices are taken from the published menu rather than from the phone, so what the guest saw is what the kitchen receives.
What a restaurant needs before connecting
| What | Details |
|---|---|
| Cloud API licence | Included in cloud iiko tariffs. On local iikoClassic tariffs it is bought separately, one licence per restaurant â your iiko manager can confirm it |
| An external menu in iikoWeb | QRmenu imports the external menu you assemble for guests, not the whole nomenclature. If it is not assembled yet, there is nothing to import |
| An API key | Created in iikoWeb under Integrations â API keys, with your restaurants attached to it |
| Rights on the key | Menu and stop lists are enough to start. Restaurant orders are needed only if guests will send baskets to the till |
How connecting works
- Create the key in iikoWeb with the longest expiry available and an email that someone actually reads â that is where iiko writes about usage limits
- Set the order source to qrmenu so orders from the QR menu are recognisable on the till
- Paste the key into QRmenu under Settings â iiko and let it confirm the key against iiko
- Choose the organization, the external menu, the price category and the till group, then save â the subscription to menu and stop-list changes is registered for you
- Press Sync and review what arrived: new categories and dishes, changed prices, dishes iiko no longer serves, and how many photos are waiting
- Publish when the menu reads the way you want it to
Frequently asked questions
Does the integration cost extra in QRmenu?
No. What may cost extra is the Cloud API licence on iiko's side: cloud tariffs include it, while local iikoClassic tariffs need it bought once per restaurant. Ask your iiko manager before planning the work.
Will syncing overwrite my translations and photos?
No. iiko owns prices, availability and which dishes exist; translations, photos, tags, recommendations and design stay yours and are carried over on every sync. Names and descriptions in the original language are written once on the first import and then left alone unless you explicitly ask for them to be refreshed.
Does it work for a restaurant with several branches?
Yes. The stop list is read per till group, so a dish paused at one branch does not disappear at another, and tables are mapped to the branch they belong to.
Do guests pay inside the menu?
No. An order sent from the table arrives open at the till and is closed by a waiter exactly as before. QRmenu never handles payment, and no payment data passes through the menu.