--- title: "Booking.com Connectivity Entegrasyon Rehberi" description: "Booking.com Connectivity entegrasyonunu token auth, canonical hotel modeli, ARI, reservation delivery, idempotency, reconciliation ve monitoring ile tasarlayın." slug: "booking-connectivity-integration" translationKey: "integration-booking-connectivity" locale: "tr" type: "guide" category: "integration" tags: ["booking.com","connectivity","ari","hotel","availability","reservation"] vertical: ["hotel"] platform: "Booking.com Connectivity" domain: "developers.booking.com" publishedAt: "2026-09-20" updatedAt: "2026-09-26" reviewedAt: "2026-09-26" technicalVerifiedAt: "2026-09-26" sourceVersion: "Booking.com Connectivity public docs reviewed 2026-09-26" testedAgainst: "Official public documentation; not a live Connectivity Partner account" codeExampleStatus: "illustrative" changelog: - "2026-09-26 — Provider companion standard applied; token auth, endpoint limits, queue/pagination and lifecycle boundaries clarified." sources: - title: "Booking.com Connectivity APIs" url: "https://developers.booking.com/connectivity/docs" - title: "Authentication" url: "https://developers.booking.com/connectivity/docs/authentication" - title: "Understanding pricing types" url: "https://developers.booking.com/connectivity/docs/understanding-pricing-types" - title: "Understanding the Reservations API" url: "https://developers.booking.com/connectivity/docs/reservations-api/reservations-overview" - title: "Going Live" url: "https://developers.booking.com/connectivity/docs/going_live" - title: "Authentication best practices" url: "https://developers.booking.com/connectivity/docs/authentication-best-practices" --- Booking.com Connectivity entegrasyonu birkaç XML veya JSON endpoint'ine veri göndermek değildir. Property setup, room-rate product, fiyat, inventory, restriction ve reservation mesajları iki sistem arasındaki ortak satış durumunu oluşturur. Production tasarımının işi bu durumu sıralı, tekrar çalıştırılabilir ve reconcile edilebilir biçimde senkronize etmektir. Platform sınırları ve operasyonel sahiplik için [Booking.com Connectivity profilini](/tr/metasearch/ecosystem/booking-connectivity) okuyun. Bu rehber uygulama ayrıntılarına odaklanır. En kritik sınır şudur: PMS/channel manager kendi operasyonel modelinin source of truth'u olarak kalır; Booking.com ID'leri external identity olarak tutulur; Booking.com'a gönderilen projection ile geri alınan reservation lifecycle ayrı kayıtlar halinde izlenir. Aksi halde başarılı HTTP cevapları zaman içinde yanlış fiyat, kapalı oda veya çift inventory adjustment üretebilir. ## Provider companion özeti | Alan | Durum | |---|---| | Erişim | Connectivity Partner onboarding + Connectivity Portal + machine account + property connection | | Auth | Token-based machine account auth; credential-based auth 31 Aralık 2025'te sunset edildi | | Token | Token exchange endpoint; access token yaklaşık 1 saat geçerli | | Token rate limit | Exchange endpoint machine account başına 30 token/saat | | Generic API rate limit | Public docs'ta tüm endpointler için 10.000 çağrı/dk üst default; bazı endpoint'lerde daha düşük özel limitler var | | Data direction | Outbound property/product/ARI + inbound reservations/messages | | Pagination | Endpoint-specific; reservation message queue pagination gibi değil, queue/latest semantics kullanabilir | | Polling | Reservation retrieval/message consumption worker-driven; polling interval provider docs ve queue-age SLO'ya göre | | Reprice | Connectivity shopping/reprice API değildir; ARI projection ve reservation lifecycle farklı bounded context | | Booking ownership | Booking.com reservation lifecycle downstream property/PMS'e teslim edilir | | Evidence level | Official public docs reviewed; live partner account test iddiası yok | | Code examples | Illustrative | ### Güncel authentication contract Yeni implementation token-based auth kullanmalıdır: ```text machine account client_id + client_secret | v POST /token-based-authentication/exchange | v short-lived access token (~1 hour) | v Connectivity API calls ``` Credential-based authentication 31 Aralık 2025 itibarıyla sunset edilmiştir. Token'ı her business request için yeniden üretmeyin; cache + expiry margin + single-flight refresh kullanın. ### Rate limit contract Booking.com'un public Connectivity docs'u genel limit olarak **10.000 çağrı/dk** belirtir; bazı endpoint'lerde daha düşük özel limitler vardır. Örnekler: - `/xml/reservationssummary`: 700/dk, - bazı OTA content/inventory notification endpoint'leri: 75/dk, - token exchange: 30/saat / machine account. Bu limitler değişebilir ve account-specific ek limit uygulanabilir. Bu nedenle hard-coded global assumption yerine endpoint + account bazlı quota config kullanın. ### Polling / pagination boundary Connectivity ailesi tek bir pagination modeli kullanmaz. Reservation/message retrieval queue semantics'e sahip olabilir; diğer resource API'leri endpoint-specific pagination uygulayabilir. Generic `page++` abstraction'ını tüm provider'a zorlamayın. Reservation worker için asıl kontrol değişkenleri: ```text queue age oldest unprocessed message pull latency persist latency ack latency duplicate delivery rate ``` ### Booking / reprice lifecycle sınırı Connectivity API'nin ana işi Booking.com kanalına distribution state göndermek ve reservation state'ini geri almaktır. Bu yüzden generic metasearch `search -> reprice -> book` lifecycle'ı burada uygulanmaz. ```text PMS/CM ARI -> Booking.com sellable state -> consumer booking on Booking.com -> reservation message -> durable persist -> PMS/downstream processing -> acknowledgement ``` Request to Book gibi ayrı Booking.com ürünleri kendi versioned contract'ına sahiptir; bunları generic Connectivity ARI flow'una karıştırmayın. ## Production senaryosu Gerçek bir production senaryosunda PMS önce bir room-rate'i kapatır, birkaç saniye sonra fiyatını değiştirir ve aynı anda Booking.com'dan modification mesajı gelir. Event'ler sırasız işlenir veya reservation durable kayda geçmeden acknowledge edilirse uzakta açık görünen inventory ya da kayıp booking oluşabilir. Bu rehberin amacı bu tür state drift'ini önleyen sınırları kurmaktır. ## Entegrasyon neyi kapsar, neyi kapsamaz? Connectivity API ailesi erişim kapsamınıza göre property onboarding, room type/rate plan, rates and availability (ARI), reservation delivery ve payments/messaging/promotions gibi ek yetenekler sağlayabilir. Erişim otomatik veya tek tip değildir: machine account'un property bağlantıları, connection type'ı, permission'ları, certification ve compliance durumu kullanılabilir yüzeyi belirler. Connectivity API şu sorumlulukları sizin yerinize almaz: - internal canonical property/room/rate identity, - PMS ile channel state arasındaki source-of-truth kararı, - change detection ve outbound ordering, - duplicate reservation/event koruması, - drift detection ve reconciliation, - PII/payment güvenlik politikası, - diğer kanallara inventory propagation. ## Erişim ve authentication nasıl kurulmalı? Machine account Connectivity Portal üzerinden oluşturulur ve property/connection bazında yetkilendirilir. Test ve production için ayrı machine account, credential ve property set'i kullanarak yanlış ortama update gönderme riskini azaltın. Yeni implementation token-based authentication kullanmalıdır. Credential-based authentication 31 Aralık 2025'te sunset edildi. Machine account credential'larını her iş isteğine eklemek yerine kısa ömürlü token üretin, server-side cache edin ve expiry'den önce kontrollü yenileyin. ```text Secret Store | v Token Manager ----> short-lived token cache | | +-----------------------+ v Connectivity Adapter ``` Token üretimini user-facing veya batch request'in içine gömmeyin. Aynı anda token süresi dolduğunda tek bir refresh çalıştırmak için single-flight/lock kullanın. `AUTH_TOKEN_FETCH_FAILED`, `AUTH_TOKEN_EXPIRED` ve `PROPERTY_NOT_AUTHORIZED` ayrı operasyonel sınıflar olmalıdır. ## Production data flow nasıl görünmeli? ```text PMS / Channel Manager | v Canonical Hotel Model | +--> Change Detector --> Transactional Outbox | v Booking Adapter | +------------------------+-------------------+ | | | v v v Property/Product Rates & ARI Remote responses | | | +------------------------+-------------------+ | v Delivery Ledger Booking Reservation Queue | v Pull / Decode / Validate / Persist | +--> inventory and downstream events | v Acknowledgement + Reconciliation ``` Outbound update kabul edilmiş olsa bile Booking.com'daki business state'in hedeflediğiniz state olduğu varsayılmamalıdır. Delivery ledger ile request, affected entities, response, RUID/correlation data ve item-level sonucu saklayın. ## Canonical ID ile Booking.com ID nasıl ayrılmalı? Provider ID'yi domain'in tek kimliği yapmayın: ```text internal_property_id != booking_property_id internal_room_type_id != booking_room_id internal_rate_plan_id != booking_rate_id ``` Örnek mapping yapısı: ```text provider_properties - internal_property_id - provider_property_id - connection_status - credential_scope provider_room_rates - internal_room_type_id - internal_rate_plan_id - provider_room_id - provider_rate_id - pricing_type - mapping_version ``` Room-rate, room type ile rate plan'ın commercial birleşimidir. Sadece room ID üzerinden update üretmek meal plan, cancellation policy veya booking rule farklarını kaybettirir. ## Pricing model neden migration kararıdır? Booking.com Standard, derived, Occupancy-Based Pricing (OBP), Length of Stay (LOS) ve belirli room-rate senaryolarında RLO davranışlarını destekler. - **Standard:** tanımlı occupancy için fiyat iletir. - **Derived:** base price'tan fixed veya percentage offset üretir. - **OBP:** date/room/rate/occupancy kombinasyonları için absolute amount ister. - **LOS:** check-in, occupancy ve night count'e göre fiyat matrisi taşır. Property üzerinde pricing type değiştirmek price, closure, restriction veya inventory'nin yeniden tanımlanmasını gerektirebilir. Değişikliği sıradan metadata update değil, kontrollü migration olarak ele alın: 1. outbound ARI'yi durdur, 2. remote state snapshot al, 3. yeni model için tam projection üret, 4. test property'de doğrula, 5. certification gereksinimini tamamla, 6. inventory ve bookability'yi yeniden kontrol et. OBP ve LOS gibi modeller için güncel certification gereksinimini rollout öncesi resmi go-live dokümanından doğrulayın. ## Normalized ARI modeli nasıl kurulmalı? Adapter öncesindeki contract provider endpoint shape'inden bağımsız olmalıdır: ```ts interface HotelDistributionUpdate { eventId: string; propertyId: string; roomTypeId: string; ratePlanId: string; dateFrom: string; dateTo: string; inventory?: number; open?: boolean; price?: { currency: string; amount: number; occupancy?: number; lengthOfStay?: number; }; restrictions?: { minStay?: number; maxStay?: number; closedToArrival?: boolean; closedToDeparture?: boolean; minAdvance?: number; maxAdvance?: number; }; sourceVersion: number; occurredAt: string; } ``` Inventory, availability ve restriction aynı şey değildir. Bir room-rate fiziksel inventory'ye sahip olduğu halde closed olabilir veya minimum stay nedeniyle belirli itinerary için satılamayabilir. Overlapping restriction'lar ayrıca risklidir: Booking.com dokümanı bazı çakışan restriction kombinasyonlarının API tarafından hata veya warning üretilmeden odayı unavailable yapabileceğini belirtir. Local preflight evaluator gönderimden önce örnek stay senaryolarında effective availability hesaplamalıdır. ## Full sync ve delta update nasıl birlikte kullanılmalı? Normal operasyon için delta üretin; onboarding, mapping değişikliği veya drift recovery için bounded full sync destekleyin. ```text property + room + rate + date-range + change-type + source-version ``` Transaction/outbox düzeni: 1. local source transaction içinde domain değişikliğini ve outbox event'ini yaz, 2. worker event'i provider projection'a çevirsin, 3. schema ve business precondition'ları local doğrulasın, 4. provider'a göndersin, 5. delivery sonucunu ledger'a kaydetsin, 6. transient hatayı retry etsin, permanent rejection'ı dead-letter'a alsın. Ordering entity/date window bazında korunmalıdır. Eski bir `open=true` event'inin yeni `closed=true` sonrasında uygulanması teknik olarak geçerli fakat ticari olarak yanlış state yaratır. ## Hangi data durable, hangisi ephemeral? ### Durable saklayın - canonical ve provider ID mapping'leri, - property/room/rate config version'ları, - pricing type ve currency, - outbound event ve delivery ledger, - provider response code ve RUID/correlation reference, - reservation ID, revision/status ve lifecycle event'leri, - acknowledgement sonucu, - reconciliation snapshot ve discrepancy. ### Kısa ömürlü veya secret olarak ele alın - access token, - raw machine-account credential, - unmasked card/PII alanları, - reservation acknowledgement token'ları, - geçici cursor ve worker lock'ları. Raw payload debugging için gerekiyorsa encrypted, access-controlled ve retention-limited storage kullanın. Payment card veya gereksiz PII'yi genel application log'una yazmayın. ## Reservation delivery idempotent nasıl işlenmeli? Reservations API yeni booking, modification ve cancellation mesajlarını queue üzerinden sunar. OTA akışında mesajlar acknowledge edilene kadar tekrar dönebilir; duplicate delivery normal davranıştır. B.XML akışında ayrı acknowledgement yoktur ve başarılı retrieval sonrasında provider'ın işlemeye hazır olduğu varsayılır. ```text Pull message | v Persist raw envelope + reservation revision | v Idempotent business processing | +--> inventory adjustment +--> PMS/downstream event | v Acknowledge only after durable acceptance ``` Dedup key yalnız reservation ID olmayabilir; modification/cancellation sequence veya response token gibi revision bilgisi de gerekir. Replay ikinci booking, cancellation veya inventory decrement üretmemelidir. Booking.com varsayılan olarak creation/modification/cancellation sonrasında 30 dakika içinde başarılı acknowledgement/retrieval görmezse property'ye fallback email gönderebilir. Bu süreyi operasyonel SLO olarak izleyin; email fallback'i başarı yolu saymayın. ## Freshness ve reconciliation nasıl tasarlanmalı? Üç ayrı freshness ölçün: - **source freshness:** PMS değişikliğinin yaşı, - **delivery freshness:** provider acceptance'a kadar geçen süre, - **remote-state freshness:** son read-back/reconciliation zamanı. Periyodik reconciliation şunları örneklemeli veya karşılaştırmalıdır: - connected/active property durumu, - room-rate mapping ve pricing type, - ileri tarih inventory ve closure window'ları, - rate/restriction projection'ları, - unacknowledged ve recently changed reservations, - rejected veya uzun süre pending update'ler. Drift bulunduğunda tüm property'yi hemen overwrite etmeyin. Discrepancy'yi sınıflandırın, authoritative side'ı belirleyin ve scoped repair event üretin. ## Error taxonomy ve retry policy nasıl olmalı? ```text AUTH_TOKEN_FAILED AUTH_SCOPE_DENIED PROPERTY_NOT_CONNECTED SCHEMA_INVALID MAPPING_MISSING PRICING_MODEL_MISMATCH BUSINESS_RULE_REJECTED RATE_LIMITED PROVIDER_5XX PROVIDER_TIMEOUT UPDATE_STATE_UNKNOWN RESERVATION_DECODE_FAILED RESERVATION_ACK_FAILED RECONCILIATION_DRIFT ``` Network failure, seçilmiş 5xx, server guidance'a uyan rate-limit ve idempotent read/pull çağrıları bounded retry alabilir. Schema hatası, missing mapping, unauthorized property, pricing conflict ve business rejection kör retry edilmemelidir. Timeout sonrası “cevap gelmedi” ile “update uygulanmadı” aynı değildir. Sonuç bilinmiyorsa correlation/RUID ile araştırın veya read-back yapın; aynı payload'ı sınırsız tekrar göndermeyin. Booking.com reservation dokümanı pull ve OTA acknowledgement çağrıları için geniş bir client timeout tavsiye eder. Bu değeri user-facing HTTP timeout'larına kopyalamayın; reservation worker'ını ayrı resource pool, bounded concurrency ve queue-age SLO ile çalıştırın. ## Failure mode'lar nelerdir? ### Out-of-order delta Geç gelen eski event daha yeni inventory veya closure state'ini geri alır. Source version ve entity-level serialization gerekir. ### Mapping drift Room/rate yeniden oluşturulur fakat local mapping eski provider ID'yi kullanır. Rejection kadar sessiz yanlış projection da izlenmelidir. ### Restriction collision Ayrı ayrı geçerli restriction'lar birlikte room-rate'i satılamaz yapar. Synthetic stay testleri gerekir. ### Partial batch acceptance Transport başarılı görünür fakat batch içindeki bazı item'lar reddedilir. Her item'ın business sonucunu kaydedin. ### Reservation acknowledged too early Mesaj durable şekilde işlenmeden ack edilirse crash sonrasında booking local sisteme hiç girmeyebilir. ### Duplicate delivery Ack gecikmesi mesajın tekrar gelmesine yol açar. Deduplication normal akışın parçası olmalıdır. ## Monitoring ve KPI'lar ### Authentication ve erişim - token refresh success/failure, - auth rejection by machine account, - unauthorized property count, - token age/expiry margin. ### Outbound synchronization - update lag p50/p95, - accepted/rejected item rate, - pending outbox age, - retry ve dead-letter volume, - mapping-missing rate, - ARI coverage horizon. ### Reservation delivery - oldest unprocessed message age, - pull-to-persist ve persist-to-ack latency, - duplicate delivery rate, - acknowledgement failure, - fallback-email risk window breaches, - modification/cancellation processing lag. ### Business quality - overbooking incident rate, - unexpectedly closed room-rate count, - price/restriction drift, - reconciliation gap age, - property/room-rate bookability coverage. HTTP 2xx oranı tek başına provider health değildir. Item-level kabul, queue freshness ve effective bookability birlikte izlenmelidir. ## Go-live checklist - Machine account scope ve property connection'ları doğrulandı mı? - Token-based authentication ve expiry-aware refresh çalışıyor mu? - Test/production credential ve property'leri ayrıldı mı? - Canonical property/room/rate ID'leri provider ID'lerden ayrıldı mı? - Pricing type ve certification kapsamı net mi? - Room-rate, occupancy, tax, meal ve cancellation semantics korunuyor mu? - Delta ordering ve transactional outbox uygulanıyor mu? - Payload ve effective restriction preflight validation var mı? - Partial batch sonucu item bazında işleniyor mu? - Reservation durable persist sonrasında ack ediliyor mu? - Duplicate modification/cancellation replay test edildi mi? - Queue age ve fallback-email risk alarmı var mı? - Retry error class ve operation idempotency'sine göre mi? - Remote/local reconciliation ve scoped repair çalışıyor mu? - PII/payment log masking ve retention policy uygulandı mı? - Certification, self-assessment ve beta rollout tamamlandı mı? ## Meta Search yorumu Booking.com Connectivity doğrudan bir metasearch shopping API'si değildir; source distribution state'ini Booking.com kanalına taşır ve reservation state'ini geri getirir. Yine de upstream room, rate, occupancy, restriction ve price semantics ne kadar doğru korunursa metasearch katmanına ulaşan offer o kadar karşılaştırılabilir olur. Sağlam entegrasyonun ölçüsü gönderilen request sayısı değil, local source ile remote bookability arasındaki açıklanabilir ve reconcile edilmiş eşleşmedir.