Ключи партнёров
Партнёрские предзаказы используют Authorization: Bearer <key>. Администратор создаёт ключ с правами catalog:read, quotes:write, orders:write, orders:read и/или webhooks:manage. Ключ ограничен заведением и выбранными каналами продаж, может иметь срок действия, ротироваться и отзываться. Секрет выдаётся один раз. Также требуется активный публичный канал предзаказов.
Доступ гостей и кандидатов
Управление бронированием и предзаказом использует Bearer-токены конкретной записи. Гостевой кабинет передаёт x-guest-portal-token после одноразового обмена начального доступа. Кабинет кандидата использует Authorization: Candidate <token>. Публичный handle или slug вакансии обозначает ресурс, но не предоставляет доступ.
Начальный доступ гостевого кабинета и предзаказов, полученный во фрагменте URL, обменивается соответствующим гостевым flow. Не помещайте токены в query-параметры, логи, аналитику и глобальное состояние приложения. Учитывайте отзыв и срок действия.
Нативный вход из кабинета требует свежий выбранный сервером целевой proof для точных RESERVATION, WAITLIST или PREORDER и исходной аудитории. Настоящий использованный reentryChallengeId может связать подтверждение контакта текущей сессии; клиент не выводит его из времени входа. receipt — неизменное подтверждение, а current.manageToken независимо может быть null. /guest-portal/reentry-context — приватная POST-команда, а не кэшируемые метаданные профиля. Отдельный initial QR reentry требует одновременно tableGuestToken и guestPortalToken; подготовка BOOKING и association допускают table-only или обе capabilities.
Публичные представления и гостевой доступ Hallify
Чтение Storefront не требует ключа и раскрывает только опубликованное содержимое и безопасные текущие данные заведения. Публичный идентификатор, имя хоста, connectionId и QR-идентификатор служат для поиска. Они не заменяют гостевой ключ выбранного ресурса Hallify.
QR-допуск возвращает приватный requestToken одного запроса присоединения; получение одобренного участия возвращает отдельный capability сессии стола. Передавайте подходящий токен как Bearer только документированному методу его ресурса. Команды начального снимка и билета наблюдения принимают текущий ключ READ ресурса PREORDER, RESERVATION, WAITLIST или TABLE_SESSION в теле JSON. Сначала получите снимок и курсор, затем отдельный одноразовый билет и потребуйте совпадение scopeBinding; нативная проверка WebSocket ещё не завершена.
Проверки гостевого представления используют фактический Origin запроса. Браузерные клиенты позволяют браузеру передать его и используют credentials: 'omit'; cookie учётной записи, авторизацию сотрудника и заголовки CSRF нельзя добавлять как запасной доступ. Методы, объявляющие x-hallify-connection-id, используют его как несекретный идентификатор подключения; разрешение QR-идентификатора использует документированный query-параметр connectionId. Они не меняют привязку представления, зафиксированную в выданном гостевом доступе. Храните ключи и билеты в памяти соответствующего сценария, вне Redux, URL, cookie, журналов, аналитики и содержимого ошибок.
Для изолированного виджета bootstrap выполняется внутри frame и определяет точные проверенный parent binding, frame/API origins и текущий режим. Новый спрос передаёт storefrontWidgetContext как x-hallify-widget-context отдельно от нативных draft/manage/membership/payment credentials. ACTIVE может выдать краткосрочный presentation proof; DISABLED может вернуть CONTINUATION_ONLY с null discovery/proof. Существующие доступы сохраняют исходные права и сроки. Ни proof, ни native credentials не попадают в parent messages или публичные URL.
Проверка брони и права соглашения
guarantee-offer и read-intent объявлены публичными. Условия/digest предложения не дают прав бронирования и оплаты. read-intent ограничен точным нативным каналом, исходным request fingerprint и текущими Origin/presentation и возвращает только обезличенное состояние проверки. Не добавляйте вымышленный токен намерения и не восстанавливайте управление по угаданному ID.
Для предложенного сотрудником CHANGE/RESTORE challenge запускает реальную проверку контакта существующего гостя. verify передаёт исходную challenge capability и настоящий код в JSON-теле; только совпавшая проверенная нативная личность получает замороженное предложение и отдельную acceptance capability. accept передаёт её и точный planHash в теле после явного согласия. Эти данные привязаны к предложению, фактическому Origin, request fingerprint и фиксированному сроку и отличаются от manage Bearer и платёжного доступа.
Храните контакт, коды, challenge/acceptance/manage capability и приватные квитанции внутри своего сценария вне URL, cookies, глобального состояния, логов и аналитики. Сохраняйте исходные ключ/тело каждой команды и выданный срок; повторы не выдают новое доказательство. Ни одни гостевые данные не открывают защищённые операции удержания и зачёта гарантии сотрудником.
Нативный гостевой платёжный доступ
Платёжный вход принимает текущую QR_MEMBERSHIP, PREORDER_MANAGE или настоящую RESERVATION_MANAGE capability в приватном JSON-теле при фактическом Origin источника. Вход брони указывает на точную нативную бронь и гарантию, а не на лист ожидания или предложение соглашения. Выданная платёжная capability отделена от observer tickets, join, черновика, партнёрских и аккаунтных данных. UUID доступа несекретный и сам не даёт прав.
Open-access, issue-handoff и redeem-handoff используют body credentials. Bill, quote, consent-offer, создание checkout, восстановление команды и progress/recovery используют отдельную Bearer-схему guestPaymentAccessToken. Тела с credentials и приватные ответы остаются вне Redux actions/cache; generated private-command builders не являются обычными кэшируемыми endpoint hooks. Не добавляйте дублирующий транспортный аргумент Authorization или account/CSRF fallback.
Между разными origins handoff начинается на получателе: он сохраняет собственный исходный токен и возвращает только его SHA-256 digest и correlation. Токены источника/native и получателя никогда не пересекают чужие origins. В deliver POST-теле передаётся только приватный handoff с привязкой к получателю. Его pending-контекст остаётся UNVERIFIED до backend issue/redeem с проверкой текущих нативных полномочий и представления; URL содержат только несекретный контекст.
Каждый запрос должен точно соответствовать текущему transportOrigin доступа. Браузерный клиент не отправляет cookies, сохраняет no-store для приватных ответов и отклоняет API redirects. Исходные сроки доступа и раскрытия результата сохраняются при handoff и ротации доступа; срок собственного результата до двадцати четырёх часов не является пятнадцатиминутным финансовым окном и не разрешает новое расходование.
Подписанные интеграции
Внешние заказы, аудит, Workforce, коммуникации и платежи используют отдельные HMAC-профили. Различаются формат времени, канонизация тела, декодирование секрета, представление подписи и повторы. Банковские callbacks проверяются по собственным протоколам провайдеров.
Настройки в кабинете Hallify
Настройка интеграции выполняется из учётной записи Hallify с правами организации и заведения. Пользовательские сессии используют HttpOnly cookies и CSRF-проверку; Authorization Bearer для них не принимается. Ключ партнёра не заменяет сессию сотрудника и не открывает все модули Hallify.