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:
- 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ı.
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.
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.
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
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.
“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.
Ne yapmalıyım?
- • Mapping’i “oda × rate plan” matrisiyle dokümante edin.
- • Değişiklik olduğunda “mapping audit” yapın (aylık).
- • Kurulum referansı: https://dgtlface.com/tr/pms-ota/pms-kurulum ve https://dgtlface.com/tr/pms-ota/kanal-yonetimi
5. Fiyat ve müsaitlik senkronizasyon problemleri (InventoryUpdate, latency, cache)
Senkron problemleri iki şekilde görünür:
- •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.
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.
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.)
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.
- • Bakım ve destek otoritesi için iç link: https://dgtlface.com/tr/yazilim/bakim-ve-destek
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.
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