Демоверсия

Руководство

Что такое интеграция API: объяснение для туристического бизнеса

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

  • Один запрос, один ответ
  • REST, XML, SOAP и вебхуки
  • Одно бронирование через четыре системы
  • Как тестируют интеграции

Определение

Что такое интеграция API простыми словами

API расшифровывается как интерфейс прикладного программирования: набор правил, который система публикует, чтобы другое ПО могло с ней общаться. Интеграция API — это работа по подключению вашей платформы к одному из таких интерфейсов, чтобы данные передавались, а действия выполнялись автоматически.

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

  • Обмен данными

    Тарифы, доступность, данные клиентов и обновления статусов передаются между системами в структурированном формате.

  • Автоматизация действий

    Поиск, бронирование, оплата, отмена и сверка выполняются как запросы, а не как шаги, которые кто-то повторяет вручную.

  • Отслеживание результатов

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

Запрос

POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{  "city": "DXB",  "check_in": "2026-11-12",  "check_out": "2026-11-14",  "guests": 2,  "currency": "USD"}

Ответ

HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{  "hotel": "Palm Marina Hotel",  "room": "Deluxe, 2 adults",  "rate": { "amount": 438.00, "currency": "USD" },  "refundable": true,  "rate_key": "rk_19d2c7"}
Пример вызова к вымышленному поставщику отелей. Имена полей, конечные точки и суммы у разных поставщиков отличаются.

Анатомия одного вызова API

  1. 1

    Конечная точка и метод

    Адрес операции и применяемый к ней глагол: POST к availability означает поиск номеров.

  2. 2

    Аутентификация

    Ключ, токен или подпись подтверждают, кто вызывает. Поставщики выдают отдельные учётные данные для песочницы и продакшена.

  3. 3

    Полезная нагрузка

    Структурированный ввод: город, даты, гости и валюта. Документация поставщика определяет каждое поле.

  4. 4

    Код состояния

    Число, показывающее, как прошёл вызов: 200 — успех, 4xx — проблема в запросе, 5xx — проблема на стороне поставщика.

  5. 5

    ID запроса

    Идентификатор, который хранят обе стороны. Когда поддержка спрашивает, что случилось с бронированием, ищут именно его.

  6. 6

    Тело ответа

    Ответ в формате поставщика, который ваша платформа сопоставляет со своими номерами, тарифами и политиками.

Одно бронирование, четыре системы

Что делает интеграция API во время бронирования отеля

Проследите за проживанием на две ночи от поиска до ваучера. Каждая стрелка — вызов API; путешественник видит только первую и последнюю.

  1. 01ПутешественникПлатформа бронированияИщет отели в Дубае, две ночи, два гостя
  2. 02Платформа бронированияAPI поставщикаЗапрос доступности с датами, гостями и валютой
  3. 03API поставщикаПлатформа бронированияНомера, тарифы, политики и ключ тарифа
  4. 04Платформа бронированияПутешественникРезультаты показаны с вашей наценкой и валютой
  5. 05Платформа бронированияAPI поставщикаПерепроверка цены по выбранному ключу тарифа перед оплатой
  6. 06Платформа бронированияПлатёжный шлюзАвторизация платежа на всю сумму
  7. 07Платёжный шлюзПлатформа бронированияАвторизовано, получен подписанный вебхук
  8. 08Платформа бронированияAPI поставщикаЗапрос бронирования с данными гостя
  9. 09API поставщикаПлатформа бронированияНомер подтверждения и условия отмены
  10. 10Платформа бронированияПутешественникВаучер, счёт и номер бронирования

Платформа в середине — это и есть место интеграции API: она переводит между экраном путешественника и форматом каждого поставщика и хранит каждую ссылку.

Та же последовательность работает для ПО для бронирования авиабилетов с GDS, Программа для туроператора с поставщиком экскурсий и Интеграция платёжных шлюзов с любым шлюзом; меняются только имена полей.

Стили интеграции

REST, XML, SOAP, вебхуки и GraphQL

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

  • REST и JSON

    JSON
    Формат данных
    Документы JSON
    Транспорт
    Методы HTTP: GET, POST, PUT, DELETE
    Типично в туризме
    Новые API авиабилетов, отелей, экскурсий и платежей
    Сильная сторона
    Компактные данные и широкий набор инструментов разработчика
    Обратите внимание
    Нестрогая спецификация; каждый поставщик трактует REST по-своему

  • XML и SOAP

    XML
    Формат данных
    Документы XML, часто со строгой схемой
    Транспорт
    HTTP POST с конвертом SOAP или чистым XML
    Типично в туризме
    GDS, бедбанки и устоявшиеся гостиничные и туровые системы
    Сильная сторона
    Формальные контракты, подписи и описания сервисов
    Обратите внимание
    Многословные сообщения и более тяжёлый разбор

  • Вебхуки

    EVENT
    Формат данных
    JSON или XML, отправляемые другой стороной
    Транспорт
    HTTP POST на зарегистрированный вами URL
    Типично в туризме
    Результаты оплаты, изменения статуса бронирования, обновления выписки билетов
    Сильная сторона
    Без опроса; платформу уведомляют, когда что-то происходит
    Обратите внимание
    Нужно проверять подписи и обрабатывать повторы

  • GraphQL

    QUERY
    Формат данных
    JSON в форме отправленного запроса
    Транспорт
    Одна конечная точка HTTP
    Типично в туризме
    Некоторые новые дистрибуционные платформы и внутренние API
    Сильная сторона
    Запрашивайте ровно те поля, что нужны
    Обратите внимание
    Поддержка у туристических поставщиков пока редка

Интеграция API против разработки API

Интеграция API

Подключает ваш продукт к уже существующему интерфейсу. API принадлежит поставщику; вы строите клиент, сопоставление и правила вокруг него.

Разработка API

Создаёт интерфейс, через который другие системы подключаются к вашему продукту, например B2B API, который могут вызывать инструменты ваших агентов. Контракт и его версии принадлежат вам.

Многим туристическим проектам нужно и то и другое: платформа интегрирует поставщиков с одной стороны и публикует собственный API для агентов и партнёров с другой.

До и после

Что меняется, когда системы интегрированы

Те же пять шагов бронирования: вручную через порталы поставщиков и через интеграцию API.

Поиск

Без интеграцииВручную

Агент открывает портал каждого поставщика и копирует цены в коммерческое предложение.

С интеграцией APIАвтоматически

Один поиск уходит ко всем подключённым поставщикам и возвращает единый список.

Цена

Без интеграцииВручную

Наценка добавляется в таблице; к моменту отправки предложения тариф мог измениться.

С интеграцией APIАвтоматически

Наценка, налоги и правила валют применяются при ответе; тариф перепроверяется перед оплатой.

Бронирование

Без интеграцииВручную

Данные гостя заново вводятся на портале поставщика; опечатки превращаются в ошибки бронирования.

С интеграцией APIАвтоматически

Данные отправляются один раз, проверяются и сохраняются вместе с подтверждением поставщика.

Оплата

Без интеграцииВручную

Оплата принимается отдельно и позже сопоставляется с бронированием.

С интеграцией APIАвтоматически

Авторизация, списание и возврат привязаны к номеру бронирования.

Обслуживание

Без интеграцииВручную

Отмены и изменения означают ещё один вход в систему и ещё одно письмо.

С интеграцией APIАвтоматически

Изменения и отмены проходят через то же соединение и обновляют запись.

Где интеграция API встречается в туристической платформе

Словарь

Термины, которые встретятся в документации API

Двенадцать слов, которые есть почти в каждом портале разработчика у поставщиков, в том значении, в каком их используют в туризме.

  • API

    Интерфейс прикладного программирования: опубликованные правила общения с системой.

  • Аутентификация

    Подтверждение того, кто вызывает: ключом API, bearer-токеном, подписью или одобренным IP-адресом.

  • Сертификация

    Проверка вашей интеграции поставщиком перед выдачей продакшен-учётных данных.

  • Конечная точка

    Один адрес для одной операции, например поиск, бронирование или отмена.

  • Идемпотентность

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

  • Сопоставление

    Перевод полей, кодов и названий поставщика в собственную модель данных вашей платформы.

  • Полезная нагрузка

    Данные внутри запроса или ответа, обычно JSON или XML.

  • Лимит запросов

    Число вызовов, которое поставщик допускает в секунду или в день, прежде чем начать их отклонять.

  • Запрос и ответ

    Один вызов: ваша платформа спрашивает, поставщик отвечает, и обе стороны ведут журнал.

  • Песочница

    Тестовая среда с фиктивным инвентарём и тестовыми картами, где ничего по-настоящему не бронируется и не списывается.

  • Код состояния

    Число HTTP, обобщающее результат: 200 успех, 401 не авторизован, 429 превышен лимит, 500 ошибка поставщика.

  • Вебхук

    Вызов в обратную сторону: поставщик или шлюз уведомляет вашу платформу, когда происходит событие.

Тестирование и объём работ

Как тестируют туристическую интеграцию API перед запуском

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

run integration tests

песочница поставщика, девять случаев

  • OK: Аутентификация с действующими и просроченными учётными данными
  • OK: Некорректный запрос отклонён с понятной ошибкой
  • OK: Тайм-аут поставщика обработан без зависшего бронирования
  • OK: Лимит запросов соблюдён, повтор после ожидания
  • OK: Изменение цены поймано при перепроверке и показано до оплаты
  • OK: Повторная отправка возвращает первое бронирование, а не второе
  • OK: Отмена применена, сборы рассчитаны
  • OK: Возврат выполнен по исходному платежу
  • OK: Ссылки бронирования, платежа и поставщика сходятся

Все случаи пройдены, готово к сертификации

Что нужно от вас для оценки объёма

  1. 1Договор с поставщиком, документация и учётные данные песочницы
  2. 2Рынки, валюты, продукты и роли пользователей
  3. 3Объём поиска, бронирования, изменения, отмены и возврата
  4. 4Требования сертификации и процедура доступа к продакшену

Готовы подключить поставщика

PHPTRAVELS интегрирует поставщиков, шлюзы и бизнес-инструменты в самостоятельно размещаемую платформу, поставляемую с исходным кодом. Смотрите Цены с тремя тарифами с разовой оплатой или спросите нас о конкретном API.

Запросить демоСвязаться с нами

Читать дальше

Вопросы

Вопросы об интеграции API с ответами

Короткие ответы на вопросы, которые задают перед первым проектом интеграции.

Отдел продаж

Интеграция API — это соединение, позволяющее двум программным системам автоматически обмениваться данными и запускать действия. Одна система отправляет структурированный запрос, другая возвращает структурированный ответ, и обе следуют согласованным правилам безопасности и данных.

В туризме она соединяет платформу бронирования с поставщиками авиабилетов, отелей, туров или автомобилей, платёжными шлюзами и бизнес-инструментами. Она поддерживает поиск, проверку цены, бронирование, отмену, возвраты и сверку без повторного ввода.

REST — архитектурный стиль, который обычно обменивается JSON по HTTP. XML — формат данных, всё ещё распространённый у GDS и бедбанков, часто обёрнутый в SOAP. Какой использовать, решают договор и документация поставщика.

Это зависит от доступа к поставщику, конечных точек в объёме, сертификации, правил сопоставления и граничных случаев бронирования. Надёжная оценка появляется после изучения документации, учётных данных и нужных вам процессов.

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

Нет. Интеграция подключает ваш продукт к существующему API; разработка создаёт интерфейс, к которому подключаются другие. Туристическим платформам часто нужно и то и другое: интегрированные поставщики с одной стороны и опубликованный для партнёров B2B API с другой.

Узнайте больше

Ещё о платформе