Демоверсія

Посібник

Що таке інтеграція API, пояснення для туристичного бізнесу

Інтеграція API — це з'єднання, яке дає змогу двом програмним системам обмінюватися даними й запускати дії без того, щоб хтось щось передруковував. Цей посібник пояснює, як це працює, на прикладі одного бронювання готелю, що проходить між мандрівником, платформою бронювання, API постачальника та платіжним шлюзом.

  • Один запит, одна відповідь
  • REST, XML, SOAP і вебхуки
  • Одне бронювання, простежене в чотирьох системах
  • Як тестують інтеграції

Визначення

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

API означає application programming interface: набір правил, які система публікує, щоб інше програмне забезпечення могло з нею спілкуватися. Інтеграція 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

    Автентифікація

    Ключ, токен або підпис підтверджує, хто викликає. Постачальники видають окремі облікові дані для sandbox і продакшену.

  3. 3

    Payload

    Структуровані вхідні дані: місто, дати, гості та валюта. Документація постачальника визначає кожне поле.

  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 авіаквитків, готелів, активностей і платежів
    Перевага
    Компактні payload і широкий набір інструментів для розробників
    На що зважати
    Нестрога специфікація; кожен постачальник трактує 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

    Application programming interface: опубліковані правила спілкування із системою.

  • Автентифікація

    Підтвердження того, хто викликає, за допомогою ключа API, bearer-токена, підпису або схваленої IP-адреси.

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

    Перевірка вашої інтеграції постачальником перед видачею продакшен-облікових даних.

  • Ендпоінт

    Одна адреса для однієї операції, як-от пошук, бронювання чи скасування.

  • Ідемпотентність

    Надсилання того самого запиту двічі дає один результат, що запобігає дублюванню бронювань і списань.

  • Зіставлення

    Переклад полів, кодів і назв постачальника у власну модель даних вашої платформи.

  • Payload

    Дані, що передаються всередині запиту або відповіді, зазвичай JSON або XML.

  • Ліміт запитів

    Кількість викликів, яку постачальник дозволяє за секунду або за день, перш ніж почне їх відхиляти.

  • Запит і відповідь

    Один виклик: ваша платформа запитує, постачальник відповідає, і обидві сторони це логують.

  • Sandbox

    Тестове середовище з вигаданим інвентарем і тестовими картками, де нічого насправді не бронюється й не списується.

  • Код статусу

    Число HTTP, що підсумовує результат: 200 — успіх, 401 — не авторизовано, 429 — перевищено ліміт, 500 — помилка постачальника.

  • Вебхук

    Виклик у зворотному напрямку: постачальник або шлюз повідомляє вашу платформу, коли стається подія.

Тестування та обсяг робіт

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

Інтеграція завершена лише тоді, коли сценарії помилок поводяться правильно. Тестовий прогін на sandbox постачальника охоплює наведені нижче випадки перед сертифікацією та переходом на продакшен-облікові дані.

запустити інтеграційні тести

sandbox постачальника, дев'ять випадків

  • OK: Автентифікація з дійсними та простроченими обліковими даними
  • OK: Недійсний запит відхилено зі зрозумілою помилкою
  • OK: Тайм-аут постачальника оброблено без зависання бронювання
  • OK: Ліміт запитів дотримано, повторна спроба після очікування
  • OK: Зміну ціни виявлено під час повторної перевірки й показано перед оплатою
  • OK: Повторне надсилання повертає перше бронювання, а не друге
  • OK: Скасування застосовано, збори обчислено
  • OK: Повернення виконано на початковий платіж
  • OK: Референси бронювання, платежу та постачальника збігаються

Усі випадки пройдено, готово до сертифікації

Що потрібно від вас для визначення обсягу робіт

  1. 1Угода з постачальником, документація та облікові дані sandbox
  2. 2Ринки, валюти, продукти та ролі користувачів
  3. 3Обсяг пошуку, бронювання, змін, скасування та повернень
  4. 4Вимоги сертифікації та процес отримання доступу до продакшену

Готові підключити постачальника

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

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

Читати далі

Запитання

Відповіді на запитання про інтеграцію API

Короткі відповіді на запитання, які ставлять перед першим інтеграційним проєктом.

Відділ продажів

Інтеграція API — це з'єднання, яке дає змогу двом програмним системам автоматично обмінюватися даними й запускати дії. Одна система надсилає структурований запит, інша повертає структуровану відповідь, і обидві дотримуються узгоджених правил безпеки та даних.

У туризмі вона з'єднує платформу бронювання з постачальниками авіаквитків, готелів, турів або автомобілів, платіжними шлюзами та бізнес-інструментами. Вона підтримує пошук, перевірку цін, бронювання, скасування, повернення та звірку без передруковування.

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

Це залежить від доступу до постачальника, ендпоінтів в обсязі робіт, сертифікації, правил зіставлення та крайніх випадків бронювання. Надійна оцінка з'являється після перегляду документації, облікових даних і потрібних вам робочих процесів.

Тестуйте автентифікацію, дійсні й недійсні запити, тайм-аути, ліміти запитів, зміни цін, повторні надсилання, скасування, повернення та звірку. У продакшені кожен запит має простежуватися до референсу бронювання.

Ні. Інтеграція підключає ваш продукт до наявного API; розробка створює інтерфейс, до якого підключаються інші. Туристичним платформам часто потрібно обидва: інтегровані постачальники з одного боку та B2B API, опублікований для партнерів, з іншого.

Дізнайтеся більше

Ще про платформу