1. OTA bağlantı hatası yaşadığınızda hangi adımları izlemelisiniz?
Aşağıdaki liste, “önce şuna bak, sonra buna” mantığında hızlı teşhis verir:
Bu teşhis akışını daha geniş PMS & OTA yönetimi çerçevesinde okumak gerekir; çünkü görünen API hatası çoğu zaman kurulum, operasyon ve dağıtım disiplinlerinin birleştiği noktada oluşur.
- Durum kontrolü (status): OTA veya channel manager tarafında genel kesinti var mı? (Varsayım: panel/duyuru kontrolü)
- Auth/Yetki kontrolü: 401/403 görüyorsanız anahtar, token, IP whitelist, kullanıcı yetkilerini kontrol edin.
- Mapping kontrolü: “Room not found / Rate plan inactive” gibi mesajlarda room/rate mapping ve plan status’larını doğrulayın.
- Senkron testi: fiyat/müsaitlik güncellemelerinin gecikmesini ölçün (latency); cache/queue gecikmesi var mı?
- Log eşleştirme: aynı request’i PMS–channel manager–OTA log’larında requestId/timestamp ile eşleştirin.
- Test rezervasyonu / test update: küçük bir oda tipi ve tek rate plan ile kontrollü test yapın (prod’da riski azaltarak).
- Destek kaydı açma (evidence pack): ekran görüntüsü + hata kodu + request/response + zaman damgası + mapping listesi + log parçaları.
Mini Check : “İlk 15 dakika”
- • Hata kodu sınıflandı (auth/mapping/sync)
- • En az 1 log kaynağında request bulundu
- • Küçük bir test ile tekrar üretildi
- • Destek için kanıt paketi hazır
Ne yapmalıyım?
- • İlk 15 dakikada “kategori”yi bul (auth/mapping/sync).
- • Sonraki 30 dakikada “katmanı” daralt (PMS mi, channel manager mı, OTA mı?).
- • Kanıt paketiyle destek talebini aç; “anlatmak” yerine “göstermek” çözümü hızlandırır.
Bu hataların önemli bölümü ilk kurulum ve test disiplinindeki eksiklerden çıkar; bu yüzden Booking ve Expedia entegrasyonu adım adım rehberindeki mapping ve test rezervasyonu mantığını troubleshooting ile birlikte düşünmek gerekir.
2. OTA entegrasyonunda karşılaşılan tipik hata tipleri (semptom → kök neden)
Sorunları “semptoma” göre sınıflandırmak, doğru çözüm yoludur:
- •Bağlantı yok / yetkisiz: 401/403 → anahtar, token, kullanıcı rolü, IP, sertifika
- •Kaynak bulunamadı: 404 / “room not found” → mapping hatası veya yanlış ID
- •Plan pasif: “rate plan inactive / closed” → PMS/CM tarafında plan kapalı veya OTA tarafında eşleşme bozuk
- •Güncelleme gelmiyor: “inventory update delayed” → queue/caching, throttling, rate limit, batch job gecikmesi
- •Yanlış fiyat/müsaitlik: mapping + derived rate + kısıtlar (min stay/stop-sell) çakışması
- •Sunucu hatası: 500/502/503 → servis kesintisi, timeout, retry ihtiyacı
| Hata tipi / semptom | Olası kök neden | Hızlı çözüm | Kalıcı önlem |
|---|---|---|---|
| 401 / 403 yetkisiz | Token, API key, rol, IP whitelist veya sertifika problemi | Yetki ve anahtar bilgisini doğrula; token yenile; erişim rolünü kontrol et | Auth bilgileri için yenileme takvimi ve erişim kontrol listesi oluştur |
| 404 / Room not found | RoomMapping eksik, yanlış ID veya OTA tarafında pasif oda tipi | PMS internal ID ile OTA external ID eşleşmesini kontrol et | Oda × rate × kanal mapping matrisi tut ve değişiklikte audit yap |
| Rate plan inactive | RatePlanStatus pasif, publish edilmemiş plan veya yanlış oda bağlantısı | Planı aktif/publish yap; doğru oda tipine bağlı olduğunu test et | Rate plan değişikliklerinde yayın kontrol SOP’si oluştur |
| 429 rate limit | Aşırı istek, batch job yoğunluğu veya yanlış retry stratejisi | Batch/retry sıklığını düşür; yoğun saatleri kontrol et | Rate limit izleme ve kontrollü retry stratejisi kur |
| 500 / timeout | Servis kesintisi, queue/caching veya geçici altyapı problemi | Status kontrolü yap; requestId ile log topla; destek kaydı aç | Evidence pack standardı ve latency izleme metriği oluştur |
| Yanlış fiyat / müsaitlik | Derived rate, stop-sell, min stay veya override çakışması | Tek oda + tek rate plan ile minimum test yap | Tek kaynak gerçek kuralı ve kısıt çakışma kontrolü uygula |
GEO mini örnek
Antalya/Belek gibi yüksek hacimli tesislerde “güncelleme gecikmesi” daha sık “sorun” gibi görünür; ama kök neden bazen rate limit/throttling veya yoğun saatlerde queue birikmesidir. Bu yüzden log ve timestamp olmadan teşhis zorlaşır.
Mini Check : Semptom net mi?
- • Hata tek kanalda mı, tüm kanallarda mı?
- • Tek oda tipinde mi, tüm room type’larda mı?
- • Tek rate plan’da mı, tüm planlarda mı?
Ne yapmalıyım?
- • Tekil mi yaygın mı ayırın (scope).
- • Tek oda tipi + tek rate plan ile “minimum test” yapın.
- • Çakışma varsa “tek kaynak gerçek”i (kuralın nereden yazıldığını) netleştirin.
3. API hata kodları ve anlamları (HTTP + iş kuralı mesajları)
API hatalarında iki katman vardır:
- •HTTP/transport katmanı: 401, 403, 404, 429, 500, timeout
- •İş kuralı katmanı (business errors): “Room not found”, “Rate plan inactive” vb.
HTTP katmanı – pratik okuma
- •401 Unauthorized: token/anahtar geçersiz veya süresi dolmuş
- •403 Forbidden: yetki/rol, IP whitelist, erişim kısıtı
- •404 Not Found: endpoint doğru olsa bile “resource id” yanlış olabilir (room/rate)
- •409 Conflict: çakışan güncelleme veya geçersiz durum geçişi (sıklıkla “state” sorunu)
- •429 Too Many Requests: rate limit; batch job veya retry stratejisi gerekir
- •500/502/503: servis tarafı hata/kesinti; retry + status takibi gerekir
- •Timeout: ağ/servis gecikmesi; queue veya altyapı sorunu olabilir
Varsayım: Her OTA/CM sağlayıcısı aynı kodu aynı mesajla döndürmeyebilir; ama sınıflandırma mantığı büyük ölçüde sabittir.
İş kuralı mesajları – pratik okuma
- •“Room not found” → RoomMapping yanlış/eksik, oda tipi OTA’da farklı ID’de
- •“Rate plan inactive” → RatePlanStatus pasif/kapalı; PMS/CM’de plan kapalı veya eşleşme yanlış
- •“Inventory update rejected” → kısıt/limit/stop-sell çakışması veya geçersiz değer
- •“Invalid date range” → tarih formatı/zon, min stay kuralı, sezon kapama
Eğer hata iptal statüsü, sanal kart veya no-show akışıyla birlikte görünüyorsa teknik teşhisi OTA iptal ve no-show politikaları çerçevesiyle birlikte yapmak, sorunun policy mapping tarafını daha hızlı ortaya çıkarır.
Mini Check : Kod → aksiyon
- • 401/403 ise mapping’e geçmeden önce yetkiyi çöz
- • 404 ise “ID ve eşleşme” doğrula
- • 429 ise batch/retry planı koy
- • 500/timeout ise status + retry + log ile destek
Ne yapmalıyım?
- • Hata kodunu “katman”a çevir (Auth/Mapping/Sync).
- • Aynı isteği tekrar üret ve log’da requestId yakala.
- • Çözüm sonrası mutlaka test rezervasyon/test update ile doğrula.
4. Room/Rate mapping kaynaklı sorunlar (RoomMapping + RatePlanStatus)
Mapping hataları, “en çok tekrar eden” ve en çok “yanlış fiyat/yanlış stok” üreten hatalardır.
Burada teknik kurulum disiplini çok belirleyicidir; oda tipi ve rate plan yapısının nasıl kurulduğunu yeniden kontrol etmek için Booking ve Expedia entegrasyonu adım adım rehberine dönmek çoğu zaman gereksiz debug turunu kısaltır.
“Room not found” nasıl çözülür?
- •Oda tipinin PMS/CM’deki internal id’si ile OTA’daki external id eşleşiyor mu?
- •Oda tipi OTA tarafında pasif/kapalı mı?
- •Channel manager’da “oda tipi değişti/yeniden adlandırıldı” gibi revizyonlar var mı?
“Rate plan inactive” nasıl çözülür?
- •Rate plan’ın PMS’te aktif olduğundan emin olun (RatePlanStatus)
- •OTA tarafında plan yayınlanmış mı (publish) ve doğru oda tipine bağlı mı?
- •Derived rate (mobil/ülke/kampanya) ile base rate çakışıyor mu?
Mini örnek
Kemer’de bir tesiste “rate plan inactive” hatası çoğu zaman yeni oluşturulan planın OTA tarafında “publish” edilmemesinden gelir. Teknik ekip “API bozuk” zanneder; aslında plan statüsü kapalıdır.
Sorunun yalnız OTA ekranında değil, veri modelinin kökünde olup olmadığını ayırmak için otel PMS entegrasyonu mimarisine de bakmak gerekir; çünkü bazı mapping sorunları PMS tarafındaki yapı değişikliğinden doğar.
Mini Check : Mapping denetimi
- • RoomType listesi ve ID’ler eşleşiyor
- • Rate plan aktif ve doğru odaya bağlı
- • Oda/rate isim değişiklikleri dokümante
Ne yapmalıyım?
- • Mapping’i “oda × rate plan” matrisiyle dokümante edin.
- • Değişiklik olduğunda “mapping audit” yapın (aylık).
- • Mapping ve dağıtım etkisini birlikte görmek için kanal yönetimi kontrolünü aynı test akışına bağlayın.
5. Fiyat ve müsaitlik senkronizasyon problemleri (InventoryUpdate, latency, cache)
Senkron problemleri iki şekilde görünür:
Tek seferlik çözüm burada yeterli olmaz; sessiz veri bozulmalarını yakalamak için OTA entegrasyon sağlık kontrolü yaklaşımını düzenli audit rutini olarak kurmak gerekir.
- •Gecikme: doğru güncelleme var ama geç geliyor
- •Tutarsızlık: bir kanalda güncel, diğerinde değil
Gecikmenin tipik nedenleri
- •Rate limit (429) → batch update yoğunluğu
- •Queue birikmesi → yüksek saatlerde işleme sırası
- •Cache/TTL → OTA tarafında görünüm gecikmesi
- •Zaman dilimi/tarih formatı → yanlış gün, yanlış saat
Tutarsızlığın tipik nedenleri
- •İki farklı panelden kural yazımı (PMS + CM)
- •Derived rate çakışması (mobil/geo)
- •Stop-sell/min stay kuralı çakışması
- •Kanal bazlı override (sadece bir OTA’ya özel kural)
Overbooking bağlantısı
Senkron gecikmesi stop-sell’i geciktirirse, sistemsel overbooking doğurabilir. Bu yüzden senkron KPI’ı (latency) teknik KPI’dır.
Bu gecikme yalnız teknik bir mesele değildir; dağıtım kalitesini doğrudan etkilediği için kanal yönetimi kararlarına ve OTA görünürlüğüne de yansır.
Mini Check : Senkron sağlık testi
- • Tek oda tipi için 3 test: fiyat, stok, stop-sell
- • Güncelleme gecikmesi ölçüldü (dakika bazında)
- • Tek kanalda mı, çok kanalda mı ayrımı yapıldı
Ne yapmalıyım?
- • Latency ölçümü için basit bir “test günlüğü” tutun (tarih/saat/kanal).
- • 429 görüyorsanız batch ve retry stratejisini ayarlayın (aşırı tekrar değil).
- • Stop-sell ve kısıt çakışmalarını tek kaynakta toplayın.
6. Destek süreci ve log analizi (LogRecord) + karar ağacı
Entegrasyon sorunlarında “en pahalı hata”, eksik bilgiyle destek kaydı açmaktır. Doğru bilgiyle açılan destek kaydı, çözüm süresini dramatik azaltır.
Sorun tekrarlıyorsa bunu tek seferlik incident gibi değil, bakım ve destek süreciyle izlenen bir sağlık konusu olarak ele almak gerekir; aynı kontrol mantığını 90 günlük audit akışıyla periyodikleştirebilirsiniz.
PMS–channel–OTA log’ları nasıl okunur?
- •Ortak anahtar: timestamp + requestId + reservationId (varsa)
- •Katman belirleme: hata PMS’te mi oluşuyor, CM’de mi, OTA’dan mı dönüyor?
- •Minimal örnek: aynı oda tipi ve tek rate plan ile tekrar üret → log’u yakala
Karar ağacı (decision tree) – “önce şuna bak”
- •401/403? → Yetki/anahtar/token → düzelt → tekrar test
- •404 / Room not found? → RoomMapping → eşleştir → test update
- •Rate plan inactive? → RatePlanStatus/publish → aktif et → test rate
- •429? → rate limit → batch/retry → test
- •500/timeout? → status + retry + log → destek
- •Gecikme? → latency ölç → queue/cache → destek + kanıt
Destek kaydı açarken eklemeniz gereken bilgiler
- • Hata zamanı (timezone ile)
- • Hata kodu + ham mesaj (verbatim)
- • Request/response örneği (maskelenmiş)
- • Oda tipi ID’leri (PMS internal + OTA external)
- • Rate plan ID + status (aktif/pasif)
- • Kanal adı (Booking/Expedia vb.) ve environment (prod/test)
- • Log parçaları (PMS/CM) ve correlation id
- • Adım adım “nasıl tekrar ediyorum?” (repro steps)
- • Ekran görüntüleri (CM panelindeki mapping sayfası vb.)
Mini Check : Destek hızlandırma
- • Repro adımları yazılı
- • Mapping ve rate plan status kanıtlı
- • 1 requestId ile log eşleşti
Ne yapmalıyım?
- • Destek kaydını “kanıt paketi” ile açın.
- • Aynı sorunu tekrar ediyorsa “kök neden + kalıcı önlem” planı çıkarın.
- • Tekrarlayan vakaları bakım ve destek planına bağlayın.
7. OTA API & Mapping Hata Checklist’i — PMS & OTA Yönetimi
OTA API & Mapping Hata Checklist’i — PMS & OTA Yönetimi (v1.0)
Bu checklist, OTA API hatalarını (401/404/429/500 vb.) ve mapping/senkron sorunlarını hızlıca sınıflandırıp doğru katmana indirgemek için tasarlanmıştır. Amaç, tekrar eden hataları azaltmak, yanlış müsaitlik/fiyat güncellemelerini önlemek ve destek taleplerini “kanıt paketi” ile hızlandırmaktır. Sonuç: daha az manuel müdahale, daha düşük teknik ekip yükü ve daha stabil entegrasyon.
Kim Kullanır?
Otel IT/entegrasyon sorumlusu, RM, rezervasyon lideri, ajans/destek ekipleri.
Nasıl Kullanılır?
- Hata kodunu sınıflandır (Auth / Mapping / Sync).
- Minimum test ile tekrar üret (tek oda + tek rate plan) ve log eşleştir.
- 14 günlük sprint ile kalıcı önlemleri uygula; sonra KPI ile izle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Hata kodu sınıflandı: 401/403 (Auth), 404 (Mapping), 429 (Rate limit), 500/timeout (Service/Sync)
- ▢ ✅ Sorun scope’u belirlendi: tek kanal mı, tüm kanallar mı?
- ▢ ✅ Tek oda tipi + tek rate plan ile repro yapıldı
- ▢ ✅ RequestId/timestamp ile log eşleşti (PMS/CM)
- ▢ ✅ RoomMapping matrisi kontrol edildi (internal/external id)
- ▢ ✅ RatePlanStatus kontrol edildi (aktif/publish)
- ▢ ✅ Latency ölçüldü (dakika) ve eşik belirlendi
- ▢ ✅ Stop-sell testi yapıldı (overbooking risk kontrolü)
- ▢ ✅ Destek evidence pack hazırlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: API hatasını çözmenin yolu panik değil, kanıtlı teşhistir
OTA bağlantı ve API hataları çoğu zaman tek bir “sistem bozuldu” problemi değildir; auth, mapping veya senkron katmanlarından birinde oluşan spesifik bir kırılmadır. Bu yüzden ilk adım, hata kodunu sınıflandırmak; ikinci adım, PMS–channel manager–OTA log’larını requestId ve timestamp ile eşleştirmek; üçüncü adım ise minimum testle sorunu tekrar üretip çözümü doğrulamaktır.
Room not found gibi mesajlarda mapping, 401/403 kodlarında yetki, 429’da rate limit, 500/timeout durumlarında ise servis ve senkron katmanı öncelikli kontrol edilmelidir. Doğru evidence pack ile açılan destek kayıtları, hem çözüm süresini kısaltır hem de aynı hatanın tekrar etmesini önleyecek kalıcı playbook’un temelini oluşturur.
Bu çerçeveyi ana hizmet tarafında derinleştirmek için OTA entegrasyonu hizmeti sayfasına, uygulama öncesi sık soruları toplamak için de OTA entegrasyonu hakkında sık sorulan sorular katmanına geçebilirsiniz.
Bir Sonraki Adım
Mapping, yetki ve senkron problemlerini sistematik olarak azaltmak isteyen oteller için.
Sık Sorulan Sorular
OTA API hataları nelerdir, ne anlama gelir?▾
“Room not found” hatası nasıl çözülür?▾
“Rate plan inactive” hatası nasıl çözülür?▾
OTA bağlantı sorununda önce nerelere bakılmalı?▾
PMS–channel–OTA log’ları nasıl okunur?▾
Senkron gecikmesi nasıl teşhis edilir?▾
İlgili İçerikler