Разработка и интеграция приложения с iiko

Что такое iiko и зачем интегрировать приложение

iiko — самая массовая POS-система для ресторанов в России. На ней работают одиночные заведения, малые сети и крупные ресторанные холдинги. В системе живут меню, остатки, цены, заказы, технологические карты, отчёты и расписания смен — это «операционный мозг» ресторана.

Когда сеть запускает клиентское приложение, сайт доставки или приложение для управляющих, рано или поздно встаёт задача интеграции с iiko. Без неё:

• меню в приложении расходится с тем, что фактически в продаже на точке;
• остатки не сверяются — клиент заказывает блюдо, которое закончилось;
• заказы из приложения не попадают в общий поток кухни и обрабатываются вручную;
• статусы заказа не доходят до клиента вовремя;
• программа лояльности работает в двух системах с расхождениями.

Интеграция с iiko это решает: через iikoCloud REST API или iikoServer API (внутренний интерфейс iikoFront / iikoOffice / iikoChain) приложение читает меню и остатки, пишет заказы, получает статусы, синхронизирует клиентов и баллы.

В экосистеме iiko есть App Store с 500+ готовыми приложениями — лояльность, аналитика, маркетинг. Для типовых задач малой сети это разумный выбор. Для премиум-сетей с уникальным интерфейсом, мультибрендом, глубокой лояльностью и собственной курьерской службой нужна кастомная разработка с iiko-интеграцией — это и есть наша работа.

Какие интеграции с iiko мы делаем

Под «интеграцией с iiko» живут разные продукты — у каждого своя архитектура и набор API. Под бизнес обычно выбирают 1–2 приоритетных типа для MVP, остальные добавляют поэтапно. Для холдинга с несколькими брендами всё это часто живёт внутри супераппа ресторанной сети.

iikoCloud API или iikoServer API — что выбрать

iiko предлагает два уровня API, и выбор между ними — главное архитектурное решение проекта.

В большинстве проектов мы используем гибрид: основная часть работает через iikoCloud (универсально и удобно), а тяжёлые аналитические задачи и DSR-функции — через iikoServer, где нужна глубина данных и нет жёстких лимитов. Окончательный выбор делаем на этапе Discovery после анализа задач и инфраструктуры сети.

Архитектура интеграции

Прямое подключение мобильного приложения к iikoCloud — это запрос к API на каждое действие пользователя. Через неделю такой подход упрётся в лимиты, через две — в проблемы с обновлением токенов. Грамотная архитектура строится через посредника.

1. Прокси-сервис между приложением и iiko

Приложение и сайт не дёргают iiko напрямую, а обращаются к собственному backend-сервису, который кеширует данные и общается с iiko централизованно. Он агрегирует запросы и снимает нагрузку с iikoCloud, кеширует меню, остатки и цены на 1–5 минут, управляет обновлением токенов без участия клиента и даёт единую точку для мониторинга.

2. Асинхронная обработка заказов

Заказ из приложения сначала создаётся в нашей базе, потом асинхронно уходит в iiko. Если iiko недоступна — заказ попадает в очередь и отправляется при восстановлении. Клиент не видит «ошибки сервера», заказ не теряется.

3. Статусы в реальном времени

Статусы заказа (в работе → готовится → готов → доставлен) — критичная часть UX. Передача через WebSocket с прокси-сервиса даёт мгновенное обновление в приложении клиента, в приложении курьера системы маршрутизации и в DSR-приложении управляющего.

4. Очереди синхронизации меню и остатков

Меню в iiko меняется — новые позиции, акции, временно недоступные блюда. Через очередь (Kafka / RabbitMQ) обновления приходят в backend и оттуда в приложение и на сайт, без расхождений на стыке.

5. Интеграционная шина для крупных холдингов

Для сетей с десятками сервисов (iiko + 1С:ЗУП + CRM + WMS + BI + LMS) разумно строить интеграционную шину ESB — единый брокер для всех систем: меньше связанности, проще масштабирование.

В нашем кейсе KFC DSR этот подход реализован полноценно: прокси-сервис между приложением управляющего и POS-стеком сети, асинхронная обработка, кеши и очереди.

Типовые сложности интеграции с iiko

С этими проблемами сталкивается каждая разработка — что обычно ломается на старте.

• Лимиты запросов iikoCloud. Если приложение запрашивает меню при каждом открытии страницы, на 100–1000 пользователях в час оно упрётся в лимит. Решение — кеш на прокси-сервисе со временем жизни 1–5 минут на разные типы данных.
• Обновление токенов. Токен iikoCloud живёт около 30 минут, дальше нужно обновление. Если клиент управляет токеном сам — половина запросов получает ошибку авторизации. Прокси-сервис централизует это на бэкенде.
• Версионирование API. iiko регулярно обновляет API, старые версии иногда отключаются. Слой абстракции между нашим кодом и iiko позволяет переехать на новую версию без переписывания всего приложения.
• Расхождение Cloud- и Server-данных. В Cloud — онлайн-снимок, в Server — полные операционные данные. Если приложение читает Cloud, а DSR пишет в Server, нужны механизмы согласования и проверки целостности.
• Синхронизация меню. Когда iikoOffice меняет состав блюда или включает акцию, приложение должно обновиться за минуты, а не часы. Решение — webhook или фоновый опрос (а лучше оба).
• Дополнительные статусы заказа. Базовые статусы iiko часто хотят дополнить клиентскими («курьер выехал», «5 минут до двери») — это пишется поверх базовых с собственным сопоставлением.
• Несколько брендов на разных серверах iiko. Если в супераппе живут рестораны на разных серверах iiko, нужен мультитенант на стороне прокси-сервиса: свой токен на бренд и маршрутизация запросов по идентификатору бренда.

Кейсы Surf

Мы создаём foodtech-продукты для лидеров рынка — от стартапов до федеральных сетей. Несколько релевантных проектов из портфеля (полный — на странице foodtech-практики):

Юнит-экономика собственного приложения поверх iiko

Зачем сети инвестировать в кастомное приложение, если есть готовые в iiko App Store? Окупаемость считаем по четырём направлениям.

• Экономия комиссии агрегаторов. Заказ через Яндекс.Еду или Купер обходится сети в 15–30% комиссии, заказ через собственное приложение — почти 0 (только эквайринг). На сети с месячным оборотом доставки 50 млн ₽ это потенциально 7,5–15 млн ₽ экономии в месяц.
• Владение клиентскими данными. В коробочных приложениях из App Store база клиентов и история заказов часто принадлежат поставщику решения. В кастомном приложении CRM остаётся у бизнеса — это основа маркетинга, лояльности и удержания.
• Гибкость интерфейса и механик. Готовое приложение — это шаблон в рамках платформы. Кастом даёт уникальный интерфейс под бренд и нестандартную лояльность (музыкальный паспорт для бара, конструктор сетов для суши, AR-меню для бургерной).
• Ниже совокупная стоимость владения. Подписка коробочного приложения растёт с числом точек и пользователей; кастом — разовая инвестиция плюс поддержка. На горизонте 3–5 лет на сети 30+ ресторанов кастом обычно окупается. Разбор экономики — в гайде «сколько стоит приложение доставки еды».

Кастомная разработка или готовое приложение в iiko App Store

В iiko App Store — 500+ приложений от партнёров, это серьёзная экосистема. У каждого подхода свои сценарии.

Для одиночного заведения или малой сети готовое приложение из App Store справится. Для премиум-сетей и сетей с уникальной концепцией — кастомная разработка с первого дня: миграция с коробки через 2–3 года обычно стоит как новая разработка.

Процесс разработки

Стек технологий

Команда: продакт, закреплённый тимлид-архитектор с опытом POS-интеграций, инженер iiko-интеграций (iikoCloud / Server, токены, лимиты), 1–2 backend-разработчика, 1–2 мобильных разработчика Flutter, frontend-разработчик (сайт доставки), QA (стресс-тесты на лимиты и сбои), DevOps.

Стоимость и сроки

Что влияет на бюджет: выбор iikoCloud или iikoServer (или гибрид), глубина интеграции (только меню+заказ или мультимодуль с лояльностью и аналитикой), мультитенант для нескольких брендов, статусы в реальном времени, глубина асинхронной обработки и отказоустойчивости, стек (Flutter или нативная пара iOS+Android). Если нужно проверить узкую гипотезу за 2–3 месяца — рассмотрите MVP foodtech. Ценовой ориентир по foodtech — в гайде «сколько стоит приложение доставки еды».