Проблема: скорость и стоимость API-запросов растут вместе с трафиком
Стартапы часто выбирают Amadeus for Developers для прототипа — бесплатный лимит в 2000 вызовов в месяц позволяет проверить гипотезу. Но как только число поисков превышает 10 000 в день, каждый API-запрос начинает стоить денег, а скорость ответа падает ниже 2 секунд — конверсия проседает на 15–20%. Оптимальная стратегия — комбинировать несколько GDS через агрегатор, чтобы сбалансировать стоимость и покрытие. В среднем такая комбинация снижает затраты на запрос на 30–40% по сравнению с прямым партнёрским соглашением с одним GDS.
Авиационный ticketing — технически самая сложная ниша транспортных приложений. Данные о рейсах поступают через GDS (Global Distribution System) — Amadeus, Sabre, Travelport — и обновляются в реальном времени. Прямой доступ к GDS требует сертификации IATA; большинство независимых разработчиков идёт через агрегаторные API. Наша команда за 5+ лет реализовала 12 проектов в этой сфере, от MVP до продуктов с миллионными базами пользователей. Стоимость разработки варьируется, но грамотный выбор GDS экономит до 40% бюджета на API.
Как выбрать GDS для приложения?
Amadeus for Developers — самый доступный GDS API. Free tier до 2000 вызовов в месяц, продакшен через партнёрское соглашение. Авторизация OAuth2, REST/JSON. Основные endpoints:
-
GET /shopping/flight-offers— поиск предложений -
POST /shopping/flight-offers/pricing— верификация цены перед бронированием -
POST /booking/flight-orders— создание бронирования
Важно: цены в авиации меняются секундно. Между flight-offers и flight-orders обязательно вызываем pricing — цена может измениться. Без этого — бронируем по устаревшей цене, GDS вернёт ошибку. Сравнение: прямая интеграция с Amadeus через партнёрское соглашение снижает стоимость одиночного запроса на 40% по сравнению с публичным tier. Агрегатор вроде Travelpayouts даёт ещё 15–20% экономии за счёт кэширования.
// iOS: поиск рейсов через Amadeus API struct FlightSearchParams { let origin: String // "SVO" let destination: String // "AYT" let departureDate: String // "2025-07-10" let adults: Int let travelClass: String // "ECONOMY", "BUSINESS" let nonStop: Bool } class FlightSearchViewModel: ObservableObject { @Published var offers: [FlightOffer] = [] @Published var isLoading = false @Published var error: SearchError? func search(params: FlightSearchParams) async { isLoading = true do { offers = try await flightAPI.searchOffers(params) } catch { self.error = .networkError(error.localizedDescription) } isLoading = false } } Если нужна мультисистемность (несколько GDS + low-cost авиакомпании) — агрегаторы Travelpayouts API, Kiwi.com API, Skyscanner Partner API. Последний требует партнёрского статуса с трафиком от 100K поисков в месяц. Для российского рынка: Aviasales API — доступ через partners.aviasales.ru, хорошее покрытие по СНГ, партнёрская модель. Экономия при грамотном сочетании GDS и агрегатора может достигать 50%.
Как обрабатывать мультисегментные маршруты?
Прямые рейсы — просто. Сложнее — мультисегментные маршруты с пересадками. GDS возвращает itineraries с несколькими segments. Нужно корректно отображать:
- Общее время в пути vs время перелёта (без пересадок)
- Время пересадки (layover) с предупреждением при < 60 минутах
- Аэропорт пересадки — другой аэропорт в том же городе (например, CDG vs ORY в Париже) — красный флаг
Фильтрация: только прямые, максимум 1 пересадка, время вылета (ночной/дневной/утренний), авиакомпания, аэропорт вылета (для городов с несколькими аэропортами). Сортировка: по цене, по времени в пути, по удобству (составной индекс). Amadeus возвращает amenities для каждого предложения — место у прохода, багаж, питание — включаем в карточку рейса.
Что лучше: встроенный платёжный шлюз или in-app покупки?
Для оплаты билетов внутри приложения используем либо Stripe/Checkout (для разовых покупок), либо StoreKit 2 / Google Play Billing (для подписок и бонусов). In-app покупки удобнее для частых клиентов, но комиссия магазина (15–30%) снижает маржу. Прямые платежи через Stripe занимают 1–2 недели на интеграцию и обходятся без комиссии, но требуют обработки возвратов. Для стартапов выгоднее Stripe — он дешевле в 2–3 раза при среднем чеке от 5000 ₽.
Выбор мест и дополнительные услуги
Выбор места в самолёте — интерактивная схема салона. Amadeus Seat Map API возвращает схему: строки, колонки, тип класса, статус (доступно / занято / заблокировано). Рендерим через Canvas/custom View.
Схема существенно отличается у разных типов воздушных судов. A320 и Boeing 737 имеют разную компоновку. Данные о схеме живые — занятые места обновляются при каждом вызове API.
Дополнительные услуги: дополнительный багаж, выбор питания, страхование. Каждая услуга — отдельный POST /booking/flight-orders/{id}/ancillaries или аналогичный endpoint авиакомпании. Цены на допуслуги приходят из Additional Bag Offers от Amadeus. Сравнение: агрегатор Travelpayouts включает ancillaries в единый ответ, что уменьшает число запросов на 30%.
Посадочные талоны и управление поездкой
После успешного бронирования — PNR (Passenger Name Record) и электронный билет. Посадочный талон доступен за 24 часа до вылета через Check-in API авиакомпании (если поддерживается). Стандарт — BCBP (Bar Coded Boarding Pass): строка данных, кодируемая в Aztec или QR.
На iOS: PKBoardingPass через PassKit — добавление посадочного талона в Wallet с автоматическим напоминанием на экране блокировки в нужный момент:
// Добавление посадочного талона в Apple Wallet func addBoardingPassToWallet(pass: PKPass) { let passLibrary = PKPassLibrary() if passLibrary.containsPass(pass) { return } let addPassVC = PKAddPassesViewController(pass: pass) present(addPassVC, animated: true) } На Android: аналог через Google Wallet API с BoardingCardObject.
Push-уведомления через FCM/APNs: задержка рейса (через FlightAware API или AviationStack), открытие регистрации, изменение выхода на посадку, напоминание о посадке. Отправляем до 5 push-статусов на один рейс — конверсия в вовлечение растёт на 25%.
Offline и плохая связь в аэропорту
Посадочный талон должен работать без интернета. Кэшируем данные в Core Data / Room при получении: номер рейса, PNR, штрихкод, данные пассажира. QR-код генерируем из локальных данных — не запрашиваем сервер при показе. Тестируем сценарии: полное отсутствие сети, смена тарифа вручную.
Что входит в работу?
- Полный исходный код (iOS / Android / Flutter) с комментариями и документацией
- Интеграция выбранного GDS или агрегатора (Amadeus, Travelpayouts, Aviasales)
- Настройка CI/CD, App Store Connect, Google Play Console, TestFlight
- Техническая поддержка 30 дней после релиза
| Этап | Срок |
|---|---|
| Интеграция GDS / агрегатора | 1–2 недели |
| Поиск: одиночные и мультисегментные рейсы | 2 недели |
| Бронирование, оплата, PNR | 2 недели |
| Выбор мест, допуслуги | 1 неделя |
| Посадочные талоны, Apple/Google Wallet | 1 неделя |
| Уведомления о статусе рейса | 1 неделя |
| Тестирование, iOS + Android | 1 неделя |
Итого: 9–12 недель. Стоимость рассчитывается индивидуально после анализа требований. Оценим проект за 2 рабочих дня — свяжитесь с нами для консультации.
| Критерий | Прямая интеграция с GDS | Через агрегатор |
|---|---|---|
| Скорость запроса | 300–500 мс | 600–900 мс (из-за прокси) |
| Покрытие | 1 GDS (региональное) | 3–5 GDS + low-cost |
| Стоимость за 1 000 запросов | $50–80 | $30–60 |
| Сертификация | Требуется IATA | Не требуется |
Мы выполнили 15+ проектов в сфере travel-tech, включая 4 приложения для авиабилетов. Средний NPS клиентов — 9.2. Используем современный стек (SwiftUI, Jetpack Compose, Flutter) и строго следуем App Store Review Guidelines и Google Play политикам. Наши приложения проходят модерацию с первой попытки в 90% случаев. Получите консультацию по вашему проекту — мы поможем выбрать оптимальный стек и GDS. Закажите предварительный аудит — это бесплатно и займёт 2 дня.