Выберите сценарий
Для серверного доступа к каталогу и создания предзаказов выберите партнёрские предзаказы. Для передачи заказов из другой системы используйте внешний приём заказов. Гостевые интерфейсы используют персональные токены и проверку контакта вместо общего ключа ресторана.
Опубликованные витрины предоставляют проверенный контент, явно привязанные заведения и nullable нативную ordering discovery. Гостевой заказ навынос/с доставкой использует точный канал: опубликованные меню/конфигуратор/корзину, ASAP или плановое время, черновик/проверку контакта, принятие зафиксированного quote и исходное управление. Origin allowlisting остаётся отдельным нативным условием. QR-доступ использует собственный join/claim lifecycle; гостевые observers — текущие READ-полномочия ресурса, а не полномочия заказа или оплаты; нативная квалификация WebSocket остаётся отдельной.
Бронирование выбирает нативную доступность, показывает точное серверное предложение гарантии и принимает его digest до создания намерения и реальной проверки контакта. Разделяйте исходные квитанции и текущее состояние intent/manage. Финансовое CHANGE/RESTORE сотрудника требует проверки контакта существующего гостя и явного согласия с точным планом; фактическое распоряжение средствами и активация остаются отдельными.
Используйте JS/TS SDK для выбранных Guest PRO methods либо изолированный reservation, preorder или table widget. Виджету нужны точные проверенный parent binding и стабильный публичный slot. Bootstrap и собственный нативный сценарий предоставляют текущие ресурсы и credentials. Node partner Preorders используют отдельный Bearer client из четырёх методов.
Начинайте нативную оплату с прав нужного источника
Гостевые платежи начинаются с текущих прав QR_MEMBERSHIP, PREORDER_MANAGE или настоящего RESERVATION_MANAGE, нативной допустимости оплаты и привязки эквайринга. У счёта и гарантии брони разные формы выбора и серверные capture modes. Покажите точного юридического получателя, суммы и предложение, затем получите явное неизменяемое согласие. Просмотр Storefront, join, черновик, ID предложения или observer ticket не заменяют этот вход.
Для обычного cross-origin headless flow используйте настроенный canonical checkout origin и receiver-first handoff. Изолированный виджет использует приватный prepare/claim transition перед обычным handoff redemption. Сохраняйте исходную команду после reload, return и UNKNOWN; read-only receipt/progress recovery не означает новую оплату. Курьерская интеграция, deployed artifacts и live PSP-квалификация остаются отдельными.
Подготовьте доступ
Администратор ресторана выбирает организацию и заведение в Hallify, включает нужный канал или подключение провайдера и выдаёт необходимые права. Ключи создаются в существующих настройках. Для витрины также нужны опубликованная ревизия, активное соединение HOSTED и действующая проверенная привязка хоста. Просмотр документации не создаёт ключ доступа и не публикует ресторан.
Подготовьте первый запрос
Базовый адрес публичного серверного API — https://api.hallify.co. Прокси /api на сайте — инфраструктура приложения, а не отдельный интеграционный API. Первые запросы выполняйте только в тестовом заведении, явно согласованном с владельцем; документация не создаёт sandbox.
Откройте первый метод руководства, изучите условия, скопируйте cURL или пример TypeScript для Node.js и замените вымышленные идентификаторы значениями из Hallify. Для гостевых запросов браузера следуйте правилам credentials: 'omit' и управляемого браузером Origin из руководства. Проверьте HTTP-статус перед использованием тела ответа. Идентификаторы, токены, даты и ответы в примерах не относятся к реальным ресурсам.
Обрабатывайте рабочие ситуации
Храните партнёрские ключи и HMAC-секреты на сервере. Приватные гостевые ключи и билеты наблюдения оставляйте в соответствующем гостевом сценарии, вне URL, журналов, аналитики и глобального состояния приложения. Сохраняйте возвращённые ссылки, ревизии и сроки действия. Повторно используйте ключ идемпотентности только для повтора той же команды. Обрабатывайте истечение срока, конфликты и повторы webhooks по контракту выбранного метода.