White label biletleme: İmzadan önce teknik ekibinizin doğrulaması gereken API'ler ve entegrasyonlar

Bilgiler Ağustos 2026 itibarıyla doğrulanmıştır

"Sizin markanız, onların motoru" vaadinin geçerliliğine neden API katmanı karar verir?

Biletlemede white label, vitrinde sizin markanız, altta bir iş ortağının motoru demektir, webook.com'un white label çözümünün modeli budur. Ancak bu vaadin CRM'inizle, turnikelerinizle ve veri ambarınızla temas ettiğinde ayakta kalması, tamamen tedarikçinin entegrasyon yüzeyine bağlıdır; bu yüzey de imza günü sabitlenir. Henüz stratejik sorudaysanız, white label biletlemede kur, satın al veya iş ortaklığı yap karar çerçevesinden başlayın; bu kontrol listesi, kısa listenizin hazır olduğunu ve teknik incelemeye geçtiğinizi varsayar.

Kurumsal değerlendirmelerde görülen örüntü hep aynıdır: ekipler, demoda görünen iki yüzey olan ödeme akışını ve bilet okutmayı test eder; diğer dört yüzeyi, envanter otomasyonu, CRM senkronizasyonu, ham veri aktarımı, kimlik, imzadan sonra, ticari koz bittiğinde keşfeder. İşlevsel genişlik ayrı bir konudur ve bir biletleme platformunun sunması gereken 12 yetenek yazısında ele alınmıştır; aşağıdaki bölümler, bu yeteneklerin altındaki teknik katmandır.

White label bir biletleme platformu hangi API'leri sunmalı? Altı yüzeyli entegrasyon testi

Eksiksiz bir entegrasyon yüzeyi altı alanı kapsar: etkinlik ve envanter yönetimi, ödeme ve siparişler, müşteri-CRM senkronizasyonu, erişim kontrolü ve bilet okutma, webhook'larla veri dışa aktarımı ve kimlik. Buna altı yüzeyli entegrasyon testi diyoruz. Yalnızca ödeme ve okutma yüzeylerini geçen bir tedarikçi size platform değil, vitrin satıyordur, kısa listenizdeki her adayı altı yüzeyin tamamından geçirin.

1. Etkinlik ve envanter yönetimi API'leri

Sistemleriniz etkinlikleri programatik olarak oluşturup değiştirebiliyor mu, etkinlikler, bilet kategorileri, fiyatlar, koltuk tahsisleri, geçici bloklar, yoksa her şey yönetim panelinden mi geçiyor? Yılda tek etkinlik için panel yeterlidir. Tam maç takvimi olan bir kulüp ya da yüzlerce satış açılışı yöneten bir portföy içinse yalnızca elle yönetilen envanter, sonsuza dek manuel operasyon demektir. Etkinlik ve kategori yönetimi uç noktaları, tahsis ve blok kontrolü ile gerçek zamanlı müsaitlik okumaları talep edin.

2. Ödeme ve sipariş API'leri

İki şeyi doğrulayın: ödeme sayfasının gerçekten sizin alan adınızda ve sizin markanızla çalıştığını, satın aldığınız vaat tam olarak budur, ve sipariş yaşam döngüsünün tamamının (oluşturuldu, ödendi, iade edildi, iptal edildi, devredildi) sistemlerinize gece raporu olarak değil, anlık olaylar olarak ulaştığını. API üzerinden iade başlatabilmek göründüğünden önemlidir; bu olmadan her müşteri talebi tedarikçinin arka ofisinden geçer ve yanıt süreleriniz onların kuyruğuna emanet kalır.

3. Müşteri ve CRM senkronizasyonu

Her satın alma, gerçekten kullanabileceğiniz bir müşteri kaydı oluşturmalı veya güncellemelidir. CRM'inize alan eşlemesini, yinelenen kayıt temizliğini, senkronizasyon sıklığını ve, en sık atlanan maddeyi, ödeme sırasında alınan pazarlama izninin kayıtla birlikte taşınıp taşınmadığını kontrol edin. İzin işaretlerini düşüren bir senkronizasyon, size yasal olarak mesaj gönderemeyeceğiniz kişiler teslim eder. Bu yüzeyin sözleşme tarafı ayrı bir müzakeredir: mühendisleriniz uç noktaları test etmeden önce biletleme verilerinizin sahipliği sorusunu netleştirin.

4. Erişim kontrolü ve bilet okutma

Kapıda ne olacağını sorun: Tedarikçi okutma uygulamaları ve SDK'lar sağlıyor mu? Mekânın bağlantısı koptuğunda doğrulama çevrimdışı çalışmaya devam ediyor mu? Platform, hâlihazırda sahip olduğunuz erişim donanımıyla entegre olabiliyor mu? Ardından biletin kendisinin kötüye kullanıma nasıl direndiğini sorun. Kendini yenileyen ve süresi dolan dinamik QR kodları ekran görüntüsüyle çoğaltmayı sınırlar, okutma anında doğrulama ise yeniden kullanımı engeller, webook.com'un güvenli biletleme yaklaşımı budur.

5. Veri dışa aktarımı ve webhook'lar

Kendi verinize iki yol gerekir: gerçek zamanlı akışlar için yeniden deneme kuralları belgelenmiş bir webhook kataloğu (sipariş, iade, devir, giriş olayları) ve kontrolü sizde olan bir takvimle, veri ambarına uygun formatlarda eksiksiz ham dışa aktarım, siparişler, müşteriler, katılım. Dışa aktarım yalnızca destek talebi açarak yapılabiliyorsa, sözleşme ne derse desin veriniz operasyonel olarak sizin değildir.

6. Tek oturum açma ve kimlik

Taraftarlarınızın hesapları kime ait? Üyelik, kombine veya bir taraftar uygulaması işletiyorsanız platform, kimlik sağlayıcınızı standart protokollerle, OAuth 2.0 ve OpenID Connect, kurumsal bağlamlarda SAML, kabul etmelidir; böylece tek bir oturum açma hem uygulamanızı hem bilet mağazanızı kapsar. Üye fiyatları veya ön satış erişimi gibi haklar da tedarikçinin sisteminde elle yeniden kurulmamalı, sizin kimlik özniteliklerinizden türetilmelidir.

Hangi entegrasyon kalıplarını ve teknik güvenceleri talep etmelisiniz?

Uç noktalar tek başına yetmez. Entegrasyonun gerçek yük altında ayakta kalıp kalmayacağını beş operasyonel güvence belirler: sürekli sorgulama yerine webhook'lar, değerlendirme sırasında açık bir test ortamı, satış açılışı zirvesinde dayanan çağrı limitleri, ilan edilmiş bir sürüm ve kullanımdan kaldırma politikası ve API'nin kendisini kapsayan bir SLA.

• Polling yerine webhook. Yüksek talepli bir satış sırasında API'yi döngüyle sorgulamak ya çağrı limitini tüketir ya da gerçeğin gerisinde kalır. Yeniden deneme ve sıralaması belgelenmiş anlık olay bildirimleri doğru kalıptır.
• İmzadan önce test ortamı. API'sine güvenen tedarikçi, değerlendirme sırasında mühendislerinizin üzerinde geliştirme yapmasına izin verir. Yalnızca sözleşmeden sonra açılan sandbox riski tersine çevirir: eksikler, koz bittikten sonra ortaya çıkar.
• Zirvenize göre boyutlandırılmış çağrı limitleri. Dakikalar içinde binlerce sipariş işleyen bir satış, sıradan kullanım için tasarlanmış her limiti kırar. Belgelenmiş limitleri, ani yük davranışını ve benzer bir yüksek talepli etkinlikten kanıt isteyin.
• Sürüm ve kullanımdan kaldırma politikası. Yıllarca sürecek bir imza atıyorsunuz ve API değişecek. İlan edilmiş bir kaldırma bildirimi süresi ve herkese açık bir değişiklik günlüğü talep edin.
• API düzeyinde SLA. Vitrinin çalışma süresi pazarlamayla anlatılır; API'ninki müzakere edilir. Kapılarınız ve CRM'iniz API'ye bağlıysa, API'nin erişilebilirliği sözleşmede yer almalıdır.

Güvenlik, PCI kapsamı ve veri koruma uyumu nasıl değerlendirilir?

Üç kontrol: PCI DSS kapsamını kim taşıyor, müşteri verileri nerede tutuluyor ve tedarikçi, pazarlarınızdaki veri koruma mevzuatı kapsamındaki yükümlülüklerinizi nasıl destekliyor? Her biri bir haftada doğrulanabilir ve hiçbiri demoda görünmez.

PCI DSS kapsamı. PCI veri güvenliği standardı, ödeme kartı verilerini saklayan, işleyen veya ileten her kuruluşa uygulanır. Doğru kurulmuş bir white label, kart işlemlerinin tamamını tedarikçinin sertifikalı ortamında tutar; kuruluşunuz bu kapsamın büyük bölümünün dışında kalır, webook.com'un white label çözümünün üzerine kurulduğu model budur. Önerilen mimari, ödeme verilerini sizin işlettiğiniz sayfa veya sunuculardan geçiriyorsa, az önce bir uyum programı satın aldınız demektir ve yeri maliyet modelinizdir.

Verinin tutulduğu yer ve uygulanacak hukuk. Müşteri verilerinin nerede saklanıp işlendiğini ve hangi rejime tabi olduğunu netleştirin. Suudi Arabistan'daki etkinlikler, SDAIA'nın ulusal veri yönetişimi platformu üzerinden denetlediği kişisel verileri koruma kanununa (PDPL) tabidir; bu kanun veri sorumlusunun yükümlülüklerini ve Krallık dışına veri aktarım kurallarını belirler. AB'de yerleşik kişilere satış yapmak ise GDPR'ı devreye sokar. Standart kurguda veri sorumlusu sizsiniz, tedarikçi veri işleyendir, veri işleme sözleşmesinin bunu aynen söylediğini ve çıkışta verilerin iadesi ile silinmesini kapsadığını doğrulayın.

Sahtecilikle mücadele duruşu. Botlar ve organize kötüye kullanım, tam da dışarıya devrettiğiniz ödeme ve hesap katmanını hedefler: platformun savunması, markanızın savunması hâline gelir. Yapay zekâ destekli sahtecilik tespiti gibi platform düzeyinde koruma, şüpheli davranış izleme, talep zirvelerinde bot tespiti, güvenlik değerlendirmesinin parçasıdır, pazarlama süsü değildir.

Tedarikçi API dokümantasyonundaki kırmızı bayraklar nelerdir?

Dokümantasyon delildir. Tedarikçinin satış mühendisleriyle görüşmeden önce ekibinize dokümanları ön bilgisiz okutun ve yedi kırmızı bayrağa göre puanlatın:

• Dokümantasyonun yalnızca PDF olarak veya gizlilik sözleşmesi arkasında sunulması, herkese açık, sürümlenmiş doküman, gerçekten kullanılan bir API'nin işaretidir.
• Sözleşme imzalanmadan sandbox erişimi verilmemesi.
• CRM senkronizasyonu veya webhook aboneliği gibi standart taleplere "Bu özel entegrasyon olur" yanıtı.
• Yeniden deneme, sıralama veya imza doğrulama kuralları belgelenmemiş webhook'lar.
• Belirtilmemiş çağrı limitleri, ya da dakika yerine gün bazında tanımlanmış limitler; oradan hiç gerçek satış geçmediğinin işareti.
• Veri dışa aktarımının self servis uç nokta veya zamanlanmış akış yerine servis talebi olarak tarif edilmesi.
• Herkese açık değişiklik günlüğü veya durum sayfası olmaması, bunlar olmadan API'nin istikrar geçmişi değerlendirilemez.

İmza öncesi doğrulama listesi

Mühendislerinize sandbox'ta bir hafta verin ve sözleşme imzalanmadan önce şu on maddenin her biri için kanıt isteyin:

• Bir test etkinliğini tamamen API üzerinden oluşturun, değiştirin ve satışa açın.
• Kendi alan adınızda ve markanızla çalışan bir ödeme sayfasında satın alma tamamlayın.
• Sipariş webhook'larını alın; test ortasında uç noktanızı kapatın ve yeniden denemelerin her olayı teslim ettiğini doğrulayın.
• Bir satın almayı, izin işaretleri bozulmadan, CRM'inizin test kopyasına senkronize edin.
• Simüle bir kapıda bileti çevrimdışı doğrulayın; ardından aynı kodun yeniden kullanılamadığını teyit edin.
• Sipariş ve müşterilerin eksiksiz ham dışa aktarımını, veri ambarınızın işleyebildiği bir formatta çekin.
• Bir test kullanıcısını kendi kimlik sağlayıcınız üzerinden doğrulayın.
• Belgelenmiş çağrı limitlerini ve benzer bir satış zirvesinden kanıtları alın.
• Veri işleme sözleşmesini inceleyin: sorumlu ve işleyen rolleri, verinin yeri, PCI sorumluluğu, çıkışta verilerin iadesi ve silinmesi.
• Kullanımdan kaldırma politikasını ve son on iki ayın değişiklik günlüğünü inceleyin.

On maddenin tamamını geçen tedarikçi var, bu yüzey, webook.com'un her gün işlettiği yüzeydir: 180'den fazla ülkede 18 milyonu aşkın kullanıcı için 40 milyondan fazla bilet işlendi ve envanter, iş ortağı API'leri üzerinden 50'den fazla iş ortağı kanalından oluşan dağıtım ekosistemiyle gerçek zamanlı senkronize çalışıyor. Bu listeyi temiz geçmek, kısa bir devreye alma sürecinin de en iyi göstergesidir; projeleri uzatan şey, imzadan sonra keşfedilen entegrasyon kapsamıdır.

Sık sorulan sorular

Testi gerçek bir platformda çalıştırın

Bu listeyi kalibre etmenin en hızlı yolu, kurumsal ölçekte hâlihazırda çalışan bir platformda uygulamaktır. webook.com'un white label çözümü için kurumsal ekibimizle iletişime geçin: vitrinde sizin markanız, altta dinamik QR ve sahtecilik kontrolü, kitle ve satış verileriniz de sizde kalır.

Tüm makaleler