PMS entegrasyonu nasıl çalışır? API’yi sade bir dille anlamak

PMS entegrasyonu, iki sistemin belirli verileri bir kişinin yeniden yazması gerekmeden, karşılıklı kabul edilmiş kurallarla otomatik olarak alışveriş yapmasını sağlayan bağlantıdır. API (uygulama programlama arayüzü) ise bir sistemin soru sorduğu, diğerinin yanıt verdiği bankodur. Asıl önemli olan kimin sorduğu, kimin bilgilendirildiği, bir mesaj başarısız olduğunda ne olduğu ve kimin düzelttiğidir.

Sabah saat dokuzda resepsiyonda bir oda fiyatı değiştiriliyor. Öğleden sonra otelin kendi web sitesi, bir seyahat acentesi ve bir satış kanalı üç farklı fiyat gösteriyor; kimse yanlış yazmadı. Açık, insanlarda değil, kullandıkları sistemler arasındaki bağlantılardadır. Bu yazıyı okuduktan sonra tek satır kod okumadan, herhangi bir yazılım sağlayıcısıyla yapılan toplantıda işe yarayan dört soruyla bu bağlantıları değerlendirebileceksiniz.

PMS entegrasyonu sade bir dille nedir?#

Entegrasyon, bir sistemin belirli verileri başka bir sisteme, bir kişinin yeniden yazması gerekmeden aktarmasını sağlayan, kabul edilmiş ve sınırlı bir bağlantıdır. API ise isteğin yapıldığı ve yanıtın geldiği bankodur.

Önce PMS'in kendisinden başlayalım: otel yönetim sistemi (PMS) rezervasyonları, odaları, misafir hesaplarını ve oda durumlarını tutar. Amerikan Otel ve Konaklama Birliğinin (AHLA) otel teknolojisi ağı HTNG'ye göre otellerde PMS, misafir, rezervasyon, misafir hesabı (folyo) ve oda verileri için birincil arayüzdür (AHLA / HTNG, "HTNG Completed Workgroups", 2026-11). Otelin teknoloji yığınındaki diğer her şey ona bağlanır; entegrasyonlarının yalnızca bilişim personelinin değil, yöneticinin de ilgisini hak etmesinin nedeni budur.

API, bir sistemin sormasına izin verilen sabit bir soru listesi ve karşılığında aldığı yanıtlardır. Resepsiyon bankosunu düşünün: oda, hesap veya anahtar isteyebilirsiniz; ama arka ofise girip mobilyaları taşıyamazsınız. Banko, nelerin hangi biçimde sorulabileceğini ve neyin geri geleceğini sınırlar.

PMS entegrasyonu ise o bankonun çevresindeki çalışma düzenidir: ne soruluyor, hangi sıklıkla, hangi biçimde ve yanıt yanlış çıktığında sorumlusu kim. Bu düzen olmayan bir API, arkasında kimsenin olmadığı bir kapıdır. Aynı AHLA / HTNG kaynağı, otellerde sistem entegrasyonlarının, özellikle PMS ile yapılanların, genellikle uzun ve karmaşık olduğunu belirtir. Bir entegrasyonu bir kez çevrilip unutulan bir anahtar gibi değil; sahibi, başlangıç ve bitiş tarihi olan bir proje gibi görün.

Her entegrasyonun bir de yönü vardır. Bazı veriler PMS'e akar, örneğin bir kanaldan gelen rezervasyon; bazıları dışarı akar, örneğin fiyatlar ve müsaitlik; bazıları iki yönlüdür. Başka hiçbir şeyi konuşmadan önce yönün hangisi olduğunu sorun, çünkü yön kimin kime bağımlı olduğunu belirler.

Daha geniş bir platform değişikliğini de değerlendiriyorsanız, otel işletim sistemi ile PMS arasındaki farkı incelerken aynı sorular geçerlidir: bir platform ne kadar çok sistemi yerine koyarsa, yönetilmesi gereken banko sayısı o kadar azalır.

Sormak ile bildirilmek: polling ve olay mesajları arasındaki fark nedir?#

Düzenli kontrolde (polling) bir sistem, diğerine birkaç dakikada bir herhangi bir değişiklik olup olmadığını sorar. Olay mesajında (event) ise değişikliği yapan sistem, diğerlerini hemen bilgilendirir.

Polling basit ve öngörülebilirdir: soran sistem aynı soruyu sabit aralıklarla yineler. Zayıf yanı, aralığın en kötü durum gecikmesini belirlemesi ve hiçbir şey değişmediğinde de sormaya devam etmesidir. Basitlik için genellikle kabul edilebilir bir bedeldir bu.

Olay mesajları abonelikle çalışır. HTNG'nin Olay Bildirim Spesifikasyonu (sürüm 3.0, 24 Nisan 2015), misafirin girişi, çıkışı veya bir odanın hizmet dışı kalması gibi önemli olaylar gerçekleştiğinde otel sistemlerinin veriyi otomatik paylaşması için bir yayınla-abone ol yöntemi tanımlar: bir sistem ihtiyaç duyduğu olaylara abone olur, kaynak sistem de olay gerçekleştiğinde onu bilgilendirir (AHLA / HTNG, 2015-04-24).

Denge, riski kimin taşıdığına ilişkindir. Olaylar daha hızlıdır ama karşı tarafın erişilebilir olduğunu varsayar; sistem kapalıysa mesajın saklanıp yeniden gönderilmesi gerekir. Polling ise soran sistemin sormaya devam ettiğini varsayar ve aradaki hiçbir şeyi fark etmez.

Örneğin: bir oda saat 07:00'te hizmet dışı bırakılıyor. Olay mesajıyla kanal yöneticisi saniyeler içinde öğrenir. On beş dakikalık bir polling döngüsüyle en geç on beş dakika sonra öğrenir; o boşlukta bir misafir odayı rezerve edebilir.

En kötü durum gecikmesi gerçekte ne demektir?#

Hiçbir yöntem soyut olarak daha iyi değildir. Sağlayıcıya hangi veri için hangi yöntemi kullandığını ve bir fiyat değişikliği, bir rezervasyon ve bir oda durumu değişikliği için en kötü durum gecikmesinin ne olduğunu sorun. Bu üç yanıt çoğu zaman farklıdır, çünkü rezervasyonlar olay olarak gelirken fiyatlar polling döngüsüyle çıkabilir.

"Gerçek zamanlı" yanıtını veren sağlayıcı soruyu yanıtlamamıştır. Gerçek zamanlı bir sayı değildir; en kötü durum gecikmesidir.

Aynı fiyatın kopyaları neden birbirinden kopar?#

Çünkü aynı sayı için birden fazla sistemin yetkili olmasına izin verilmiştir ve her kopya kendi takvimine göre yenilenir.

Yetkili kaynak, bir değerin düzenlendiği tek yerdir; diğer her yer, oradan yenilenen bir kopya tutar. Kavram basittir; asıl iş hangi verinin hangi sistemde tutulduğunu yazılı hale getirmektir.

Kopmanın dört yaygın nedeni vardır: bir değerin iki sistemde düzenlenmesi, resepsiyonda yapılan ve karşı tarafa hiç ulaşmayan manuel bir müdahale, başarısız olup hiç yeniden gönderilmeyen bir mesaj ve bir kişinin tek bir kopyayı elle düzeltmesi. Her biri sessizcedir. Kaybolan bir rezervasyon, resepsiyondaki öfkeli bir misafir olarak ortaya çıkar; bayat bir fiyat ise ancak biri dünkü fiyattan rezervasyon yaptığında ortaya çıkar.

Bunun çoğunu önleyen kural şudur: her veri türü için tek yetkili. Oda durumu ve misafir hesabı PMS'e aittir. Yayımlanan satış fiyatı tek bir sisteme aittir ve diğer her sistem onu düzenlemek yerine okur.

Kopya olmak sorun değildir; adı konulmamış kopya olmaktır sorun. Bir kopya varsa, yenilenme kuralına ve görünür bir zaman damgasına ihtiyacı vardır; böylece ekrandaki sayının ne kadar eski olduğunu kişi görebilir. Pratik bir denetim: fiyatlar, müsaitlik, misafir kimlik verileri ve satış noktası harcamaları için "bu nerede düzenleniyor?" diye sorun. Aynı kalem için iki yanıt gelirse, size bir rezervasyona mal olmadan önce bir kopma kaynağı bulmuşsunuzdur. Sistemlerin birbirine nasıl bağlandığını daha geniş görmek için otel teknoloji altyapısını ele alan yazıya bakabilirsiniz.

Bir mesaj başarısız olduğunda ne olur?#

Başarısız bir mesaj olağandır. İyi bir entegrasyonu kötü olandan ayıran şey, birinin bunu fark edip etmediği, mesajın nasıl yeniden gönderildiği ve düzeltmenin kime ait olduğudur.

Yeniden denemeler ilk savunma hattıdır: gönderen sistem bir takvime göre tekrar dener. Tehlike, sonsuza dek deneyip kimseye söylemeyen bir sistemdir; böylece başarısızlık hata gibi değil, sessizlik gibi görünür. Korkulacak başarısızlık biçimi sessizliktir.

Uyarılar ikinci hattır. Bir başarısızlık bir insana ulaşmalıdır, bir günlük dosyasına değil. Uyarının nereye gittiğini, kimin okuduğunu ve o kişinin cumartesi 23:00'te ne yaptığını sorun.

Günlük mutabakat üçüncü hattır. Günde bir kez iki sistem arasındaki sayı ve toplamları karşılaştırın: her iki tarafta oluşturulan rezervasyonlar, misafir hesaplarına işlenen harcamalar ile satış noktasının kendi kaydı, hazırlanan kimlik bildirimleri ile varışlar. Farklar ay sonunda değil, aynı gün araştırılır; çünkü aynı gün bulunan fark bir düzeltmedir, ay sonunda bulunan fark bir anlaşmazlıktır.

Yeniden gönderme, uyarı kadar önemlidir. Başarısız bir mesajın, yinelenen bir kayıt oluşturmadan tekrar gönderilip gönderilemediğini sorun; çünkü yinelenen bir rezervasyon çoğu zaman eksik olandan daha kötüdür. Ve geçiş öncesinde başarısızlık yolunu yazın: dört yanıtın yazılı olduğu tek sayfalık bir not, kimsenin açmadığı uzun bir sözleşme ekinden daha değerlidir.

Sürümler ve kapsamlı erişim bir entegrasyonu nasıl korur?#

Sürüm, banko kurallarının sabit bir baskısıdır; böylece bir taraf, diğerini bozmadan değişebilir. Kapsamlı erişim ise her bağlantının yalnızca kendisine verilen belirli işleri yapabilmesi demektir.

Sürümler şöyle çalışır: bir sistem yanıtlama biçimini değiştirdiğinde yeni bir sürüm yayımlar ve eskisini bir süre daha çalıştırır. Eski sürümlerin ne kadar süre desteklendiğini ve bir sürüm emekliye ayrılmadan önce nasıl bilgilendirildiğinizi sorun; çünkü emeklilik tarihi sağlayıcınız için bir son teslim tarihidir, sizin için değil.

Kapsamlı erişimi sade sözlerle anlatmak gerekirse: binayı değil, iki kapıyı açan bir anahtardır. IETF standardı OAuth 2.0 (RFC 6749, Ekim 2012), üçüncü taraf bir uygulamanın bir web hizmetine sınırlı erişim almasını sağlar: ya kaynağın sahibi adına, onun onayını alan bir adımla ya da kendi adına; uygulama istediği erişimin kapsamını da belirtir (IETF / RFC Editor, 2012-10). Otel diliyle en az yetki ilkesi şudur: kanal yöneticisinin fiyat ve müsaitliğe ihtiyacı vardır, misafir hesaplarına değil. Bir e-belge entegratörünün fatura verisine ihtiyacı vardır, tüm misafir geçmişine değil. Bir bağlantı işinin gerektirdiğinden fazlasını istiyorsa, nedenini yazılı olarak sorun.

İki denetim daha: imzalı mesajlar, alan sistemin mesajın gerçekten gönderenden geldiğini ve yolda değiştirilmediğini doğrulamasını sağlar; mekanizmayı bilmeniz gerekmez, yapılıp yapılmadığını bilmeniz yeter. Ve erişimin geri alınması: sözleşme sona erdiğinde, sağlayıcı değiştiğinde veya erişimi olan bir personel ayrıldığında erişim nasıl kapatılıyor, sorun. Hızla geri alınamayan bir erişim, süregelen bir risktir.

En temiz düzenler, aynı kuralı her bağlantı için yeniden kurmak yerine her eylemi bir kez tanımlayıp ihtiyaç duyan her sisteme sunar. Aynı fikir, yapay zekâ için otel sistem mimarisinin de temelidir: tek tanım, çok sayıda kapı.

Türkiye'de her otelin uğraştığı PMS entegrasyonları hangileridir?#

Pratikte dört tanesidir: kanal yöneticisi, e-belge entegratörü, misafir kimlik bildirimi (KBS) ve merkezi turizm veri tabanı. Her biri farklı türde veri taşır ve farklı biçimde başarısız olur.

Temel çerçeve şudur: Türkiye'de her konaklama; ödeme, mali belge (fatura ya da e-belge), misafir kimlik bildirimi (KBS) ve kişisel veri (KVKK, kişisel verilerin korunması kanunu) adımlarını içerir. Satın aldığınız her entegrasyon bu yolun bir yerinde durur.

Kanal yöneticisi, fiyat ve müsaitliği satış kanallarına taşır. Sorulacak sorular kaç kanal listelendiği değil, fiyat için hangi sistemin yetkili olduğu ve en kötü durum gecikmesinin ne olduğudur. E-belge entegratörü, e-Fatura ve e-Arşiv (elektronik fatura) düzenleyen yetkili taraftır: otelin sistemi belgeyi hazırlar, bir kişi gözden geçirir, entegratör düzenler. Gönderim öncesi insan incelemesi iyi bir uygulamadır ve aynı zamanda yanlış bir tutarın yakalanabileceği son yerdir.

KBS, misafir kimlik bildirimi, check-in (giriş) akışının içinden hazırlanıp gönderilir. Çevresindeki teknik kurallar buradaki kaynaklarda kamuya açık ve kesin biçimde belirlenmiş değildir; ayrıntıları bir forum yazısına değil, sağlayıcınıza sorarak doğrulayın.

Merkezi turizm veri tabanı en yeni yükümlülüktür. Kültür ve Turizm Bakanlığı genelgesi 2026/1 (16.04.2026), konaklama tesislerini ve yazılım sağlayıcılarını, verilerini bir web servis API'si üzerinden merkezi turizm veri tabanına göndermekle yükümlü kılar (alomaliye.com, 6 Mayıs 2026; Dünya'daki TGA Genel Müdürü açıklaması, 18 Mayıs 2026). Bu haberler akış otomatikse günlük, manuelse ayın 15'ine kadar aylık periyottan söz eder. Periyodu, kapsamı ve kendi durumunuzu genelge metniyle ve sağlayıcınızla doğrulayın. Burada okunan kaynaklarda bir yaptırım belirtilmemiştir.

Otomatik akış mı, manuel giriş mi?#

Otomatik akış, verileri sisteminizden bir takvime göre gönderir; manuel giriş, bir kişinin verileri bir portala yazması demektir. Manuel giriş, o kişi izne ayrılana kadar çalışır; sonra da biri kaydı isteyene kadar boşluk görünmez kalır.

Bu sistemlerin rolleri kafanızda netleşmediyse, PMS, kanal yöneticisi ve rezervasyon motoru karşılaştırmasıyla başlayın.

Geliştirildi, sınandı ya da faaliyette: bir entegrasyon iddiasına güvenmeden önce ne sormalısınız?#

Üç durumu ayrı ayrı sorun; çünkü "onlarla entegreyiz" cümlesi, bir tasarım belgesinden bugün bir otelde çalışan bir bağlantıya kadar her şey anlamına gelebilir.

Geliştirildi, kodun var olduğu ve bir test ortamında çalıştığı anlamına gelir. Bu gerçek bir emektir; ama çalışan bir bağlantıyla aynı şey değildir. Sınandı, karşı tarafın kendi test ortamında, o tarafın gerçekten gönderdiği mesaj biçimleriyle, yalnızca sağlayıcının kendi örnek verisiyle değil, çalıştırılmış olması demektir. Hangi ortam olduğunu ve karşı tarafta kimin onayladığını sorun. Faaliyette ise bağlantının en az bir gerçek tesis için çalıştığı, bunu doğrulayabilecek ve başarısızlık anında ne olduğunu anlatabilecek adı bir kişinin olduğu anlamına gelir. O adı isteyin ve son başarısızlığın nasıl göründüğünü sorun.

Her toplantıya taşımaya değer yedi soru: veri hangi yönde akıyor, hangi sistem yetkili, en kötü durum gecikmesi ne, uyarılar nereye gidiyor, bir başarısızlığı kim düzeltiyor, erişim nasıl geri alınıyor ve eski sürümler ne kadar süre destekleniyor.

Bu üç durumu dürüstçe ayıran bir sağlayıcıyla çalışmak, her şeyi aynı anda iddia edenden daha kolaydır; çünkü neyi, ne zaman satın aldığınızı tam olarak bilirsiniz.

Şimdi ne yapmalı#

Sessizce başarısız olsa en çok canınızı yakacak tek entegrasyonu seçin, onun dört yanıtını (kim soruyor, kim bilgilendiriliyor, bir mesaj başarısız olursa ne oluyor, kim düzeltiyor) yazın ve o sayfayı sağlayıcınıza götürün. Yazının bölümleri tam bu sırayla birbirine bağlanır: banko API'nin ne olduğunu, polling ve olaylar gecikmeyi, yetkili kaynak kopmayı, başarısızlık yolu ise bir PMS entegrasyonunun bir özellikten önce bir sorumluluk olduğunu açıklar.