Не работает сайт доставки, приложение или киоск на iiko? Что случилось после 29 августа 2026 и как починить

2 сентября 2026Автор: Редакция Restohub - IT-интегратор для ресторанного бизнеса

29 августа 2026 iiko отключила старую схему авторизации (iikoTransport) в облачном API. Если сайт доставки, мобильное приложение, киоск самообслуживания или сервис бронирования подключены через старые ключи, заказы перестали доходить до кассы. Решение - перевести интеграцию на новую схему авторизации через портал разработчика iiko, при сложностях обратиться в техподдержку iiko или к интегратору.

Что случилось с интеграциями iiko 29 августа 2026 года?

Да, это подтверждённое событие, а не единичный сбой у отдельного заведения. 29 августа 2026 iiko полностью отключила старую схему авторизации в облачном API iikoTransport для всех кастомных интеграций. Официальный источник - новость на iiko.ru.

Это плановое техническое обновление ради безопасности API, а не поломка со стороны iiko. Новые ключи по старой схеме не выдавались с 1 июня 2026 - у бизнеса было почти три месяца на переход. Проблема в том, что часть заведений и подрядчиков этот срок пропустила: интеграция продолжала работать по старой схеме до самого дедлайна, а потом просто перестала.

Если у вас есть чек-лист подготовки к переходу, который вы не успели закрыть до дедлайна, - логика та же, что описана в статье «Авторизация в API iiko: как подготовиться к 29 августа 2026». Эта статья, наоборот, для тех, кто уже столкнулся с поломкой на практике и решает вопрос постфактум.

Важно понимать: отключили именно способ подтверждения подлинности запросов к облачному API, а не сам API целиком. Технически это значит, что сервер iiko перестал принимать запросы, подписанные старым способом, и требует запросы с новой авторизацией. Все данные, меню, остатки и настройки заведения при этом никуда не делись - проблема только в том, что внешние сервисы не могут достучаться до кассы.

Какие симптомы у проблемы: как понять, что дело именно в авторизации API?

Зависит от типа интеграции, но общий признак один: сервис, который раньше передавал данные в iiko или получал их оттуда, перестал это делать именно с 29 августа, без видимых изменений в самом заведении. Заказы либо не доходят до кассы, либо сервис показывает ошибку при обращении к iiko.

Типичные проявления:

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

Если проблема началась именно 29 августа 2026 и раньше интеграция работала стабильно, это почти наверняка тот самый случай. Совпадение по дате - самый надёжный первый признак, до того как разбираться в логах.

Отдельно стоит проверить, что дело не в другом: не отключился ли интернет на точке, не упал ли сам сайт или сервер приложения, не идут ли работы на стороне платёжного провайдера. Если базовые вещи в порядке, а заказы всё равно не доходят до кассы - переходите к диагностике авторизации.

Какие сервисы могло затронуть?

Затронуты интеграции, которые работают через облачное API iiko: сайты доставки, мобильные приложения заказа, киоски самообслуживания, сервисы бронирования столов и чаевых, а также другие кастомные решения, написанные под конкретное заведение или сеть.

Сама касса и iikoFront на точке продолжают работать в обычном режиме - официант или кассир может пробивать заказы вручную без проблем. Проблема именно во внешних сервисах, которые общаются с iiko через программный интерфейс, а не в самой системе учёта.

Если у заведения нет собственного сайта доставки, приложения или киоска и все заказы принимаются через кассу вручную или через агрегаторов с готовой встроенной интеграцией, изменение, скорее всего, вас не коснулось напрямую - у крупных агрегаторов такие переходы обычно делает сама сторона интеграции. Риск выше у тех, кто заказывал сайт, приложение или киоск как индивидуальную разработку у подрядчика или делал интеграцию своими силами.

Отдельно стоит проверить сети и франшизы: если несколько точек используют одну и ту же кастомную интеграцию (например, единый сайт доставки на всю сеть), проблема проявится сразу на всех точках одновременно, а не на одной. Это усложняет диагностику, но и решение в этом случае одно на всю сеть, а не отдельное для каждой точки.

Что делать прямо сейчас: пошаговый алгоритм диагностики и перехода на новую схему

Алгоритм действий одинаковый независимо от типа интеграции: сначала локализовать проблему, потом перевести доступ на новую схему через официальный портал разработчика iiko, потом протестировать и подключить поддержку, если своими силами не справиться.

Зафиксируйте симптом и время его появления. Проверьте логи сайта, приложения или киоска - когда именно перестали проходить заказы. Совпадение с 29 августа 2026 указывает на авторизацию API как на причину.
Определите, кто и как разрабатывал интеграцию. Это штатная разработка, подрядчик или готовое коробочное решение стороннего поставщика. От этого зависит, кто должен вносить изменения в код или настройки авторизации.
Проверьте, использует ли интеграция облачное API iiko и старую схему авторизации (iikoTransport). Если сервис обращается к iiko через API и ключи выдавались до 1 июня 2026, вероятность, что дело именно в этом, очень высокая.
Свяжитесь с разработчиком или поставщиком интеграции и уточните, переведена ли она на новую схему авторизации. Если интеграция самописная и вы или ваша команда имеете доступ к коду - переходите к следующему шагу самостоятельно.
Зарегистрируйте или переведите интеграцию на новую схему авторизации через портал разработчика iiko, следуя официальной инструкции iiko для актуальной версии API. Это ключевой технический шаг, который выполняется на стороне интеграции, а не на стороне кассы.
Протестируйте работу после перехода. Сделайте тестовый заказ через сайт, приложение или киоск и проверьте, что он корректно доходит до iikoFront, кухни и кухонного дисплея.
Если разобраться своими силами не получается - обратитесь в техподдержку iiko или к системному интегратору, который сопровождает вашу автоматизацию. Особенно это касается заведений, где интеграцию делал подрядчик, который уже недоступен, или где нет своей IT-команды.

Пока переход не завершён, разумно временно принимать заказы вручную по телефону или через кассу, чтобы не терять гостей, - это не решает проблему, но снижает потери на время диагностики и перехода.

Сколько времени занимает переход на новую схему авторизации?

Зависит от сложности интеграции и от того, кто ей занимается. Если у вас есть доступ к коду и разработчик на связи, техническая часть перехода может занять от нескольких часов до пары дней вместе с тестированием. Для сложных кастомных решений или при поиске нового подрядчика срок может растянуться на неделю и дольше.

Главный фактор времени - не сама процедура перехода на новую схему авторизации, а то, насколько быстро удаётся найти человека, который знает код вашей интеграции и может внести изменения. Если интеграцию делал подрядчик, который давно не сопровождает проект, поиск нового исполнителя обычно занимает больше времени, чем сама техническая доработка.

Точных официальных сроков перехода iiko не публикует - это зависит от конкретной интеграции, а не от вендора. Разумно закладывать резерв времени и параллельно принимать заказы вручную, чтобы не останавливать продажи на весь период диагностики и доработки.

Как избежать таких сбоев при будущих обновлениях API iiko?

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

Практические шаги на будущее:

назначьте ответственного (сотрудника или интегратора), который отслеживает раздел новостей на iiko.ru и портал разработчика на предмет технических изменений API;
ведите список всех кастомных интеграций заведения (сайт доставки, приложение, киоск, бронирование, чаевые) с указанием, кто их разработал и как с ним связаться;
при получении уведомления о плановом изменении API не откладывайте переход до последнего дня - как показал этот случай, дедлайн наступает жёстко и без продления;
держите под рукой контакты техподдержки iiko и своего интегратора, чтобы не искать их в момент, когда заказы уже не проходят.

Чек-лист подготовки к переходу на новую схему авторизации - в более ранней статье «Авторизация в API iiko: как подготовиться к 29 августа 2026». Она пригодится, если вы уже почти всё починили и хотите убедиться, что ничего не упустили, а также как шаблон действий на будущее для похожих обновлений API.

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

Техническое сопровождение и интеграции iiko с Restohub

Restohub диагностирует, почему перестала работать интеграция с iiko, и переводит сайты доставки, приложения, киоски и другие кастомные решения на актуальную схему авторизации API. Берём на абонентское сопровождение, чтобы подобные обновления вендора в будущем не превращались в остановку заказов.

Телефон: +7 905 243-72-50 Email: sale@restohub.pro Сайт: https://www.restohub.pro Визитка Restohub

Статья обновлена: сентябрь 2026. Автор: редакция Restohub - IT-интегратор для ресторанного бизнеса.

Частые вопросы про отключение старой схемы авторизации API iiko

Это баг iiko или мы что-то сломали на своей стороне? Нет, это не баг и не ваша ошибка. 29 августа 2026 iiko планово отключила старую схему авторизации в облачном API для всех интеграций - это техническое обновление ради безопасности, а не сбой конкретного заведения или подрядчика.

Отключилась ли касса и обычные заказы в зале и на вынос через официанта? Нет. Сама касса и iikoFront продолжают работать в обычном режиме, официант и кассир могут пробивать заказы вручную. Проблема касается только внешних сервисов, которые общаются с iiko через облачное API: сайтов доставки, приложений, киосков, бронирования.

Можно ли ещё как-то использовать старую схему авторизации iikoTransport? Нет, с 29 августа 2026 старая схема полностью отключена, а новые ключи по ней не выдавались уже с 1 июня 2026. Единственный рабочий путь - перевести интеграцию на новую схему авторизации через портал разработчика iiko.

Нужно ли платить за сам переход на новую схему авторизации? Зависит от того, кто выполняет переход. Техническое требование новой схемы авторизации - это бесплатное обновление вендора. А вот работа по доработке кода конкретной интеграции - самостоятельно, силами подрядчика или интегратора - оплачивается отдельно, как любая техническая доработка.

Что делать, если не знаю, кто разрабатывал сайт доставки или приложение? Начните с проверки договоров, счетов и переписки за последние пару лет - там обычно указан исполнитель. Если найти подрядчика не получается, обратитесь в техподдержку iiko или к системному интегратору, который сможет провести диагностику и перевести интеграцию на новую схему заново.

Нужно ли останавливать приём заказов на время перехода на новую схему? Нет, полностью останавливать продажи не обязательно. Пока идёт диагностика и перевод интеграции, заказы можно принимать вручную по телефону или через кассу - это временное решение, которое снижает потери, пока техническая часть не восстановлена.

Поможет ли Restohub перевести интеграцию на новую схему авторизации? Да. Restohub диагностирует причину сбоя, переводит сайты доставки, приложения, киоски и другие кастомные интеграции с iiko на новую схему авторизации и может взять техническое сопровождение на постоянной основе, чтобы будущие обновления API не останавливали заказы.