Seyahat rezervasyon API'si nedir? Acenteler için API destekli altyapı

Seyahat rezervasyon API'si, bir yazılımın uçuş, otel ve diğer seyahat ürünlerini başka bir sistemden aramasını, sepete eklemesini, rezervasyon ve ödeme yapmasını sağlayan programlama arayüzüdür. Acenteler için iki yönü vardır: tedarikçilere (havayolu, GDS, otel toptancısı) bağlanan API'ler ve acentenin kendi platformunu bir dış yazılımcıya açtığı entegrasyon API'si.

Eski yazımızın başlığı "kendi çözümünü geliştir" idi ve bu fikir hâlâ geçerli: hazır paket arayüzlere bağlı kalmak istemeyen acenteler, aynı altyapının üzerine kendi kanallarını kurabilir. Aşağıda bunun gerçekte nasıl işlediğini, hangi tarafın neye bağlandığını ve kurumsal portalın bu yapıdaki yerini anlatıyoruz.

API nedir ve seyahat sektöründe ne işe yarar?

API (Application Programming Interface), iki yazılımın birbiriyle belirli kurallarla konuşmasını sağlayan arayüzdür. Seyahatte bu, bir ekranda elle yapılan işlemin (uçuş aramak, fiyat almak, bilet kesmek, iptal etmek) programla yapılması demektir. Sonuçlar genellikle JSON veya XML biçiminde döner ve çağıran yazılım bunları kendi arayüzünde gösterir.

API'nin acenteye kazandırdığı şey içerik ve otomasyondur. Her havayolunun ya da otel toptancısının ekranına ayrı ayrı girmek yerine, tek bir platform birçok tedarikçiyi aynı anda sorgular, sonuçları birleştirir ve rezervasyonu ilgili tedarikçiye iletir. Arkada tedarikçi bağlantıları, ödeme hattı ve iş kuralları çalışır; önde kullanıcı tek bir arayüz görür.

Acenteler hangi API'lerle çalışır?

Bir acente altı API katmanıyla çalışır: havayolu NDC ve GDS bağlantıları, otel tedarikçileri, transfer, araç, villa, yat, etkinlik ve otobüs tedarikçileri, kart tahsilatı için sanal POS, muhasebe bağlantıları ve acentenin dışarıya açtığı entegrasyon API'si. Aşağıdaki tablo her katmanın rolünü özetler.

Havayolu tarafında NDC ayrı bir yer tutar. NDC, havayolunun kendi tekliflerini acenteye doğrudan ileten IATA standardıdır; kısa tanımı NDC sözlük maddesinde, GDS ile farkı GDS entegrasyonu yazısındadır.

Tedarikçi API'leri kurumsal portala nasıl yansır?

Kurumsal.pro kurumsal portalı, acentenin panelinde açık olan tedarikçileri ayrı bir bağlantı kurmadan kullanır. Portal, acentenin kurumsal kimliğiyle panelin aynı arama, sepet, ön rezervasyon ve ödeme nesnelerini çağırır. Bu yüzden kurumsal kanalın eriştiği tedarikçiler, o acente için aktif olan panel tedarikçileridir.

Bu yapının iki sonucu vardır. Birincisi, acente portalda açık bir modülde yeni bir tedarikçi etkinleştirdiğinde kurumsal müşterileri de onun sonuçlarını görür; ayrı bir entegrasyon işi gerekmez (tur modülünde portal yalnız acentenin kendi turlarını listeler). İkincisi, portal tedarikçiyi gizler: personel fiyatı ve sonucu görür, ama tedarikçi adı, net fiyat, markup ve komisyon portal yanıtlarından silinir. Ayrıştırılamayan bir yanıt portala hiç gönderilmez.

DIJI.TECH, altyapının 100+ API entegrasyonuna ve günlük 7 milyar+ sorgu kapasitesine sahip olduğunu beyan eder. Hangi tedarikçinin hangi acentede açık olduğu ise kurulumda belirlenir. Açılabilecek tedarikçilerin ürün bazında dökümü kurumsal seyahat entegrasyonları sayfasındadır. Kurumsal kanala özgü bir örnek THY NDC entegrasyonu sayfasında anlatılır: kurumun THY anlaşma kodu her aramaya otomatik eklenir, şirketin şubeleri de aynı kodu kullanır.

Acente kendi çözümünü API ile geliştirebilir mi?

Evet. Altyapıda acentenin bir dış yazılımcıya verebileceği, ayrı belgelenmiş bir entegrasyon API'si vardır. Bu API arama, rezervasyon ve satış sonrası uçlarını kapsar; acente bununla örneğin kendi web sitesine, bir iş ortağının sistemine ya da kendi iç aracına rezervasyon akışı ekleyebilir.

Kimlik doğrulama acente kullanıcısıyla yapılır: kullanıcı oturum açar ve dönen belirteç (Bearer token) her çağrıda gönderilir. Belgeler OpenAPI 3.1 biçiminde üretilir ve Scalar arayüzünde okunur. OpenAPI, HTTP API'leri için dilden bağımsız, standart bir arayüz tanımıdır; yazılımcı servisin ne yaptığını kaynak koda bakmadan belgeden öğrenebilir.

Bir rezervasyon API akışı hangi adımlardan oluşur?

Entegrasyon API'sindeki akış, bir rezervasyonun ekranda izlediği yolun aynısıdır. Adımlar sırayla şöyledir:

1. Oturum: Acente kullanıcısıyla oturum açılır, dönen belirteç saklanır.
2. Arama: Ürün araması başlatılır ve sonuçlar hazır oldukça sorgulanır; çok tedarikçili aramalar bu yüzden asenkron çalışır.
3. Sepet: Seçilen teklif ürününe göre sepete eklenir.
4. Ön rezervasyon: Yolcu bilgileriyle ön rezervasyon (prebook) oluşturulur.
5. Ödeme: Ön rezervasyon ödenir ve rezervasyonlar kesinleşene kadar ödeme durumu sorgulanır.
6. Satış sonrası: Her ürünün rezervasyonları listelenir ve okunur; iptalde önce iptal tutarı alınır, sonra iptal onaylanır ya da vazgeçilir.

Bu sıra, kendi arayüzünü yazan acentenin fiyat değişimi, ödeme beklemesi ve iptal cezası gibi durumları hangi adımda ele alacağını da gösterir.

Entegrasyon API'sinin konumu da bilinmelidir: bu API acentenin kendi satış yüzeyi için belgelenmiştir; kurumsal müşterinin onay akışı ve bütçe kontrolü ise kurumsal portalın akışında çalışır. Kurumsal müşteriye politika rozetleri, onay akışı ve bütçe kontrolüyle çalışan bir ekran gerekiyorsa doğru araç hazır kurumsal portaldır; API ise acentenin kendi web sitesi veya iş ortağı kanalları gibi başka satış yüzeyleri içindir.

Şirketin intraneti veya İK sistemi kurumsal portala bağlanabilir mi?

Eski yazımızda bir holdingin çalışan intranetine "uçak bileti al" düğmesi koyma senaryosu vardı. Bugünkü üründe bu hazır bir özellik değildir ve dürüstçe ayırmak gerekir: kurumsal portalın API'si yalnız portalın kendi sunucusu ve giriş yapmış personelin oturumuyla çağrılır. Üçüncü taraf bir istemci kimliği yoktur, dolayısıyla şirketin kendi sistemleri portal API'sine doğrudan bağlanmaz.

Şirket tarafındaki veri akışı bunun yerine dosya tabanlıdır. Personel listesi Excel ile en çok 5.000 satır olarak toplu yüklenir ve bir doğrulama raporuyla onaylanır; harcama, uyum ve satış dökümü gibi raporlar Excel, CSV veya PDF olarak dışa aktarılır ve zamanlanmış e-postayla gönderilebilir. Muhasebe tarafında ise kurumsal satışlar acentenin muhasebe entegrasyonu hattından geçer.

API altyapısı seçerken nelere bakılmalı?

Bir acente, kendi kanalını bir API üzerine kurmadan önce altyapının yalnız arama yapıp yapmadığına değil, rezervasyonun tamamını taşıyıp taşımadığına bakmalıdır. Aşağıdaki sorular iyi bir kontrol listesidir.

• Belgeleme: API standart bir biçimde (ör. OpenAPI) belgelenmiş mi, uç noktalar ve hata kodları açık mı?
• Kapsam: Arama ve rezervasyonun yanında ödeme ve satış sonrası (listeleme, iptal) da var mı?
• Kimlik doğrulama: Erişim kimin adına yapılıyor, yetkiler hangi kullanıcıyla sınırlanıyor?
• Asenkron arama: Çok tedarikçili aramada sonuçlar parça parça mı geliyor, bekleme nasıl yönetiliyor?
• Fiyat ve durum değişimi: Ödeme öncesi fiyat değişirse veya ödeme beklerse API bunu nasıl bildiriyor?
• Tedarikçi kapsamı: Hangi tedarikçiler açık, yenisi eklendiğinde ek geliştirme gerekiyor mu?
• Ödeme ve muhasebe: Kart tahsilatı ve fatura belgesi aynı hatta mı, yoksa ayrı entegrasyon mu gerekiyor?

Kendi API altyapını yazmak mı, hazır platform kullanmak mı?

Tedarikçi bağlantılarını sıfırdan yazmak her havayolu ve toptancı için ayrı geliştirme, test ve sürekli bakım demektir. Tedarikçiler sürüm değiştirdikçe bağlantıların da güncellenmesi gerekir. Bu yük, çoğu acente için asıl işi olan satıştan zaman çalar.

Hazır bir platform bu bağlantıları tek bir altyapıda toplar; acente ise üzerine kendi kanalını, ister hazır kurumsal portalla ister entegrasyon API'siyle kurar. Altyapının kiralanması ya da kaynak kodunun satın alınması arasındaki fark hazır yazılım mı kaynak kod mu yazısında anlatılır. Kendi tedarikçi ve ödeme kurgunuz için DIJI.TECH demo sayfasından görüşme talep edebilirsiniz.