> ## Documentation Index > Fetch the complete documentation index at: https://developer.every.ru/llms.txt > Use this file to discover all available pages before exploring further. # Обновление прохода > Отправляется при изменении статуса прохода (lounge или fast-track). ## OpenAPI ````yaml webhook pass.status.changed openapi: 3.1.0 info: version: 1.0.0 title: Every Travel B2B API description: > Партнёрский B2B API для оформления travel-сервисов: бизнес-залы (lounges), фаст-трек (fast-track) и eSIM. Все B2B-эндпоинты доступны после получения access token через `POST /oauth/v2/token` и (где требуется) с клиентским сертификатом mTLS. ## Состав API - **Идентификация и токены** — OAuth2 (`client_credentials`), JWKS для оффлайн-проверки JWT. - **Каталоги** — список бизнес-залов, фаст-треков и тарифов eSIM, доступных партнёру. - **Бронирование (lounge / fast-track)** — двухшаговый сценарий «создать → подтвердить», получение данных прохода (`/pass`), отмена. - **Заказ eSIM** — двухшаговый сценарий «создать заказ → подтвердить заказ», по подтверждению возвращается выпущенная eSIM с данными для активации (QR/LPA). - **Webhooks** — подписка на события (`booking.status.changed`, `pass.status.changed`, `esim.package.usage_threshold_reached`, `esim.package.exhausted`, `esim.package.expired`). ## Кэширование каталогов API поддерживает условные запросы для эндпоинтов каталогов через заголовки `ETag`/`If-None-Match` и `Last-Modified`/`If-Modified-Since`. Это позволяет клиентам экономить трафик при повторных запросах. ### Использование ETag При первом запросе сервер возвращает заголовок `ETag` с уникальным идентификатором версии ресурса. При последующих запросах клиент может передать это значение в заголовке `If-None-Match`. Если ресурс не изменился, сервер возвращает `304 Not Modified` без тела ответа. ### Использование Last-Modified Сервер также возвращает заголовок `Last-Modified` с датой последнего изменения ресурса. Клиент может передать это значение в заголовке `If-Modified-Since` при следующем запросе. Если ресурс не был изменен после указанной даты, сервер возвращает `304 Not Modified`. ### Пример использования ``` # Первый запрос GET /v2/catalog/lounges → 200 OK → ETag: "abc123" → Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT # Повторный запрос с ETag GET /v2/catalog/lounges If-None-Match: "abc123" → 304 Not Modified → ETag: "abc123" → Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT ``` ## Идемпотентность API поддерживает идемпотентность операций через заголовок `Idempotency-Key`. Операции создания бронирований (POST /v2/b2b/booking/lounges, POST /v2/b2b/booking/fast-tracks), операции выпуска и пополнения eSIM (POST /v2/b2b/fulfilment/esims, POST /v2/b2b/fulfilment/esims/{iccid}/topup) и операции создания аккаунтов и приложений (POST /v2/admin/accounts, POST /v2/admin/accounts/{accountID}/applications) требуют обязательного заголовка `Idempotency-Key`. Операции подтверждения и отмены бронирований (POST /v2/b2b/booking/*/confirm, POST /v2/b2b/booking/*/cancel) идемпотентны по своей природе через бизнес-логику (повторный вызов возвращает 409 при недопустимом состоянии) и не требуют ключа идемпотентности. ### Поведение (Source-of-Truth) При повторном запросе с тем же `Idempotency-Key`: - **Совпадение тела запроса**: сервер возвращает **строго тот же HTTP-код и тело ответа**, что были возвращены при первом запросе. Заголовок `Idempotency-Status: reused` указывает на повторное использование. - **Несовпадение тела запроса**: сервер возвращает `409 IdempotencyConflict`, если тело запроса отличается от сохранённого (см. правила сравнения ниже). ### Правила сравнения тела запроса Для определения конфликта сравниваются следующие поля: - **POST /v2/b2b/booking/lounges**: все поля `LoungeBookingRequest` (lounge_id, first_name, last_name, email, phone, calling_code, transport_number, guests) - **POST /v2/b2b/booking/fast-tracks**: все поля `FastTrackBookingRequest` (fast_track_id, first_name, last_name, email, phone, calling_code, transport_number, guests) - **POST /v2/b2b/fulfilment/esims**: все поля `CreateAccountEsimRequest` (package_template_id, active_period, validity_period) - **POST /v2/b2b/fulfilment/esims/{iccid}/topup**: путь (`iccid`) и все поля `CreateAccountEsimRequest` (package_template_id, active_period, validity_period) - **POST /v2/admin/accounts**: все поля `AdminCreateAccountRequest` (name, csr_pem) - **POST /v2/admin/accounts/{accountID}/applications**: все поля `AdminCreateApplicationRequest` (name, allowed_scopes) Сравнение выполняется путём нормализации JSON (игнорирование порядка полей, нормализация пробелов) и побайтового сравнения нормализованных представлений. ### TTL и истечение срока действия Ключ идемпотентности имеет TTL **72 часа** с момента первого использования. После истечения TTL: - Ключ считается недействительным - Новый запрос с тем же ключом обрабатывается как новый запрос (создаётся новая операция) - Возвращается `Idempotency-Status: created` - **Не** возвращается ошибка 422 или 409 ### Заголовки ответа Все операции, поддерживающие идемпотентность, возвращают: - `Idempotency-Key`: эхо переданного ключа - `Idempotency-Status`: - `created` — операция создана впервые - `reused` — операция повторно использована (возвращён сохранённый результат) ## Webhooks API поддерживает отправку webhook-уведомлений для отслеживания жизненного цикла бронирований и проходов. Это позволяет получать уведомления об изменениях статусов без поллинга API. ### Управление подпиской Партнёр может иметь **не более одной** webhook-подписки на аккаунт. Управление осуществляется через узкие command-эндпоинты, соответствующие поддерживаемым операциям: - `POST /v2/b2b/webhooks` — создание подписки - `GET /v2/b2b/webhooks` — список подписок (0 или 1 элемент) - `GET /v2/b2b/webhooks/{webhookID}` — получение подписки - `POST /v2/b2b/webhooks/{webhookID}/change-url` — изменение URL endpoint - `POST /v2/b2b/webhooks/{webhookID}/rotate-secret` — ротация секрета подписи - `POST /v2/b2b/webhooks/{webhookID}/disable` — приостановить доставку - `POST /v2/b2b/webhooks/{webhookID}/enable` — возобновить доставку - `DELETE /v2/b2b/webhooks/{webhookID}` — удаление подписки При создании подписки указываются: - `url` — URL endpoint для приёма webhook-уведомлений (должен быть доступен по HTTPS) - `secret` — секретный ключ для подписи webhook-уведомлений (HMAC-SHA256) Партнёр получает уведомления обо всех поддерживаемых событиях; отдельная подписка на конкретные типы не требуется. ### Формат webhook-уведомлений Все webhook-уведомления отправляются в формате JSON и содержат: - `event` — тип события - `timestamp` — время возникновения события (ISO 8601) - `data` — данные события (зависит от типа события) ### Поддерживаемые события - `booking.status.changed` — изменение статуса бронирования - `pass.status.changed` — изменение статуса прохода ### Безопасность Webhook-уведомления подписываются с использованием HMAC-SHA256. Подпись передаётся в заголовке `X-Webhook-Signature`. servers: - url: https://api.phoenixpass.space description: Production - url: http://localhost:8080 description: Local development - url: https://api.sandbox.every.ru description: Sandbox security: [] paths: {} ````