Saat gece yarısı, Steam cüzdan kodu kampanyanız yayında ve siparişler art arda düşüyor. Bir anda tedarikçi API'nizden "429 Too Many Requests" hatası gelmeye başlıyor, müşteriler ödemesini yaptı ama kod gelmiyor. E-pin satış yazılımında API rate limit ve güvenlik konusu, çoğu satıcının site açılana kadar hiç düşünmediği ama kriz anında en çok can yakan başlıklardan biri. Bu yazıda hem tedarikçi API sınırlarının nasıl işlediğini hem de sisteminizi hem hız hem de güvenlik açısından nasıl koruyacağınızı ele alıyoruz — çünkü doğru kurulmamış bir teslimat altyapısında bu iki sorun genelde aynı anda, aynı gecede baş gösterir.
Tedarikçi API'niz Sizi Neden Bloke Ediyor?
Turkpin, Pinabi gibi e-pin tedarikçileri, kendi altyapılarını korumak için API isteklerine sınır koyar. Bu sınır genelde saniye başına veya dakika başına belirli sayıda istek şeklindedir ve aşıldığında sunucu isteğinizi işlemeden geri çevirir. Basit bir "sipariş geldiğinde direkt API'yi çağır" mantığıyla yazılmış bir sistemde, kampanya saatlerinde veya bir bayinin toplu sipariş girdiği anda bu sınır çok kolay aşılır.
Sorun sadece hız değil, sınırın hangi katmanda uygulandığını bilmemektir. Aynı tedarikçi farklı isteklere farklı kısıtlar koyabilir:
- IP adresi başına istek sınırı — paylaşımlı sunucularda başka bir müşterinin trafiği bile sizi etkileyebilir
- API anahtarı başına istek sınırı — hesabınıza özel, en sık karşılaşılan tür
- Endpoint başına ayrı sınır — örneğin stok sorgulama ile sipariş oluşturma farklı kotalara tabi olabilir
- Günlük toplam işlem sınırı — bazı tedarikçilerde saatlik değil günlük tavan da vardır
Bu sınırları bilmeden yazılmış bir entegrasyon, en yoğun ve en kazançlı saatlerde tam olarak çökme riski taşır. Daha da kötüsü, bazı basit entegrasyonlar hata aldığında isteği hemen tekrar atacak şekilde yazılır; bu da "thundering herd" denilen bir etkiye yol açar. Yüzlerce başarısız istek aynı anda tekrar denenince tedarikçi tarafındaki yük daha da artar ve engelleme süresi kısalacağına uzar. Turkpin ve Pinabi gibi farklı tedarikçilerin sınırları da birbirinden farklıdır; birinde saniyede 5 istek serbestken diğerinde bu sayı 2 olabilir, bu yüzden tek bir sabit hız ile her tedarikçiye aynı şekilde davranmak da hatalıdır.
Bir 429 Hatası Gerçekte Kaç Siparişe Mal Olur?
Rate limit hatası teknik bir detay gibi görünse de sonucu tamamen ticari. Müşteri ödemeyi tamamlamış, ekranda "kodunuz hazırlanıyor" yazıyor ama arka planda tedarikçi API'si isteği reddediyor. Bu noktada üç senaryodan biri yaşanır: sistem hatayı yutar ve sipariş askıda kalır, müşteri destek kanalına yazar ve operasyon yükü artar, ya da daha kötüsü müşteri kart iadesi (chargeback) talep eder.
Özellikle kampanya dönemlerinde — bayram, yılbaşı, oyun indirimleri gibi — trafik normalin kat kat üzerine çıkar. Tam bu anlarda rate limit duvarına çarpan bir sistem, en çok satış yapabileceğiniz saatlerde en çok müşteri kaybettiren sisteme dönüşür. Manuel takip eden bir ekip için onlarca askıdaki siparişi tek tek kontrol edip elle teslim etmek hem zaman kaybı hem hata riskidir.
Zarar sadece o anki siparişle sınırlı kalmaz. Sık chargeback alan bir mağaza, PayTR veya Shopier gibi ödeme sağlayıcılarının risk skorlamasında olumsuz not düşer; bu da ileride komisyon oranlarının yükselmesine ya da hesabın incelemeye alınmasına yol açabilir. Yani teknik bir rate limit sorunu, aylar sonra ödeme altyapısı seviyesinde bir soruna dönüşebilir.
Kuyruk ve Yeniden Deneme Mekanizması Olmadan Ne Olur?
Rate limit sorununun çözümü tedarikçiyi aramak değil, kendi tarafınızda akıllı bir istek yönetimi kurmaktır. Doğru kurulmuş bir sistemde sipariş anında API'ye direkt çarpmaz; önce bir kuyruğa girer, sonra kontrollü aralıklarla işlenir. Pinova'nın teslimat motoru bu mantıkla çalışır:
- Sipariş oluştuğunda önce dahili kuyruğa yazılır, tedarikçiye anında istek atılmaz
- İstekler tedarikçinin izin verdiği hızda, aralıklarla gönderilir
- 429 hatası alınırsa istek kaybolmaz, artan bekleme süresiyle (exponential backoff) otomatik yeniden denenir
- Her sipariş benzersiz bir işlem kimliğiyle işlenir, böylece bir yeniden deneme aynı kodun iki kez düşmesine yol açmaz
Bu sayede yoğun saatlerde tedarikçi API'si geçici olarak yavaşlasa bile müşteri "hata" değil, en fazla birkaç saniyelik bir bekleme görür. Sipariş kaybolmaz, sadece sıraya girer ve otomatik tamamlanır.
İdempotency, yani "aynı isteğin birden çok kez gönderilse bile yalnızca bir kez işlenmesi" ilkesi burada kritik rol oynar. Ağ kesintisi, tarayıcı yenilemesi veya kuyruğun yeniden denemesi gibi durumlarda sistem her istekte yeni bir kod düşürmez; aynı sipariş kimliğini tanır ve daha önce üretilmiş kodu tekrar döner. Bu detay küçük görünse de, elle yönetilen sistemlerde en sık rastlanan "fazladan kod gitti, zarar oluştu" vakalarının birebir kaynağıdır. Pinova panelinde ayrıca her siparişin kuyruk durumu (bekliyor, işleniyor, tamamlandı, yeniden deneniyor) canlı olarak görülebilir, böylece bir sorun anında elle araştırma yapmaya gerek kalmaz.
| Senaryo | Manuel / Elle | Pinova ile |
|---|---|---|
| Tedarikçi 429 hatası verdiğinde | Sipariş askıda kalır, ekip elle tekrar dener | Otomatik kuyruk + artan bekleme ile yeniden dener |
| Aynı sipariş iki kez işlenirse | Fazladan kod düşer, zarar oluşur | Benzersiz işlem kimliği çift işlemi engeller |
| API anahtarı saklama | Genelde düz metin, kod içinde veya notlarda | Şifreli, sunucu tarafında ayrı katmanda saklanır |
| Tedarikçi API'si tamamen düşerse | Site siparişi hiç işleyemez | Yedek tedarikçiye otomatik geçiş yapılabilir |
| Şüpheli işlem tespiti | Fark edilmesi günler sürebilir | Anlık loglama ve anomali bildirimi |
API Anahtarınız Sızarsa Ne Kaybedersiniz?
Rate limit bir performans meselesiyse, API anahtarının korunması doğrudan bir güvenlik meselesidir. Tedarikçi API anahtarı, sitenizin bakiyesine ve sipariş verme yetkisine giden anahtardır. Bu anahtar düz metin olarak bir dosyada, kaynak kodunda veya paylaşılan bir dokümanda dururken sunucunuz ele geçirilirse, saldırgan doğrudan tedarikçi hesabınızdan sınırsız kod çekebilir. Bu senaryo teorik değil; küçük ölçekli e-pin siteleri arasında en sık görülen kayıp sebeplerinden biri budur.
Doğru bir mimaride API anahtarları şu şekilde ele alınır: ortam değişkeni veya şifreli yapılandırma katmanında saklanır, veritabanına düz metin yazılmaz, sunucuya erişim yetkisi olsa bile anahtarı görüntülemek ayrı bir izin gerektirir. Ayrıca anahtar sızıntısı ihtimaline karşı periyodik anahtar yenileme (key rotation) alışkanlığı, hasarı sınırlı tutar.
Aynı hassasiyet admin panelinin kendisi için de geçerlidir. Bakiye yükleme, bayi komisyon oranı değiştirme veya tedarikçi anahtarı güncelleme gibi kritik işlemler yapan bir yönetici hesabı, sadece kullanıcı adı-şifre ile korunuyorsa tek bir sızdırılmış şifre tüm sistemi tehlikeye atar. Bu yüzden iki adımlı doğrulama (2FA), oturum zaman aşımı ve kritik işlemler için ayrı bir onay adımı, panel güvenliğinin ihmal edilmemesi gereken parçalarıdır. Sunucu ile tedarikçi arasındaki tüm trafiğin HTTPS/TLS üzerinden şifreli gitmesi de aynı şekilde tartışmaya kapalı bir zorunluluktur — açık metin (HTTP) üzerinden atılan bir API isteği, ağ üzerinde dinleme yapan biri için anahtarı doğrudan hediye etmek demektir.
Tedarikçi API anahtarınızı asla ön yüz (frontend) koduna, GitHub deposuna veya destek yazışmalarına yapıştırmayın. Anahtar bir kez internete sızarsa, tedarikçiden yeni anahtar talep etmek dakikalar sürer ama zararı geri almak mümkün olmayabilir.
Tek Tedarikçiye Bağımlı Kalmak Sizi Nasıl Kilitler?
Rate limit ve güvenlik dışında üçüncü bir risk daha var: tek noktadan bağımlılık. Sitenizin teslimat sistemi tek bir tedarikçinin API'sine bağlıysa, o tedarikçide yaşanacak bakım, kesinti veya stok tükenmesi anında tüm satışlarınızı durdurur. Müşteri açısından fark etmez — "site çalışmıyor" olarak algılanır, oysa sorun sizde değil, dışarıdaki bir bağlantıdadır.
Pinova, Turkpin ve Pinabi gibi birden fazla tedarikçi API'sini aynı anda tanımlayabilecek şekilde kurulur. Bir tedarikçide gecikme veya kesinti olduğunda sistem otomatik olarak ikinci tedarikçiye yönlenebilir ya da ürün bazında hangi tedarikçinin öncelikli kullanılacağı elle belirlenebilir. Bu, hem fiyat karşılaştırması hem de kesintisiz teslimat için pratik bir avantaj sağlar.
Ayrıca farklı tedarikçilerin aynı ürünü farklı fiyatlarla sunması da normaldir; çoklu tedarikçi desteği olan bir sistemde belirli bir ürün için hangi kaynağın o an daha uygun fiyatlı veya stokta olduğuna göre otomatik seçim yapılabilir. Tedarikçiden gelen stok bildirimleri (webhook) kullanılıyorsa bu bildirimlerin de imza doğrulaması (HMAC gibi) ile gelmesi gerekir; aksi halde sahte bir istekle sisteme yanlış stok veya sipariş durumu bilgisi enjekte edilebilir.
Bir Saldırıyı Fark Etmeden Kaç Gün Geçer?
Rate limit sadece tedarikçi tarafında değil, kendi sitenizin giriş noktalarında da düşünülmesi gereken bir kavramdır. Kart deneme saldırıları (carding), aynı IP'den art arda farklı kart numaralarıyla küçük tutarlı denemeler yaparak çalışan kartı bulmaya çalışır. Rate limit korumasız bir ödeme formu, farkında olmadan bu tür denemelere açık bir kapı haline gelir.
Bunu önlemenin yolu, hem sipariş hem de ödeme deneme sayısını IP ve oturum bazında sınırlamak, ardışık başarısız denemeleri geçici olarak engellemektir. Bunun yanında her API çağrısının, her sipariş durumu değişikliğinin ve her admin işleminin loglanması gerekir — çünkü loglama olmadan bir anomaliyi günler, hatta haftalar sonra fark edersiniz, o zaman da zarar çoktan oluşmuştur.
- Ardışık başarısız ödeme denemelerinde otomatik geçici engelleme
- Her API isteğinin zaman damgalı, geri dönülebilir log kaydı
- Anormal sipariş hacminde (örn. aynı hesaptan kısa sürede çok sayıda yüksek tutarlı sipariş) admin bildirimi
- Bayi/panel girişlerinde başarısız deneme limiti
Bu katmanlar tek başına "hacker'ları durdurmaz" ama saldırının maliyetini yükseltir ve sizi erken uyarır — çoğu küçük ölçekli saldırgan için bu caydırıcı yeterlidir.
Log kayıtlarının sadece tutulması yetmez, geriye dönük olarak okunabilir ve aranabilir olması da gerekir. Bir müşteri "param gitti, kod gelmedi" dediğinde destek ekibinin o siparişin tüm API çağrı geçmişini — hangi tedarikçiye, ne zaman, hangi yanıtla — saniyeler içinde görebilmesi hem müşteri memnuniyeti hem de olası bir anlaşmazlıkta elinizdeki en güçlü kanıt olur. Aksi durumda her anlaşmazlık, veritabanını elle tarayarak çözülmeye çalışılan bir dedektiflik işine dönüşür.
Sisteminiz Bu Sınavı Geçebilir mi?
Pinova, tedarikçi API kuyruğu, şifreli anahtar saklama, çoklu tedarikçi desteği ve anlık loglama gibi katmanları kurulum anından itibaren hazır sunar; bu yükü sizin kod yazarak çözmenize gerek kalmaz.
Rate limit hatası aldığımda müşteriye ne olur?
Doğru kurulmuş bir kuyruk sisteminde müşteri hata görmez; sipariş sıraya girer ve tedarikçinin izin verdiği hızda otomatik olarak tamamlanır. Kuyruk yoksa sipariş askıda kalır ve elle müdahale gerekir.
API anahtarımı kaç günde bir değiştirmeliyim?
Sabit bir kural yok, ancak birçok tedarikçi ve güvenlik uygulaması birkaç ayda bir anahtar yenilemeyi (key rotation) önerir. Anahtarın herhangi bir yerde açığa çıktığından şüpheleniyorsanız beklemeden değiştirin.
Tek tedarikçi kullanmak gerçekten risk mi?
Evet. Tedarikçi tarafında yaşanan bakım, kesinti veya stok sorunu tek tedarikçiye bağlı bir sitede tüm satışları durdurabilir. Çoklu tedarikçi desteği bu riski dağıtır.
Kart deneme saldırısını nasıl anlarım?
Genelde aynı IP veya oturumdan kısa sürede çok sayıda farklı kartla küçük tutarlı deneme yapılması tipik bir işarettir. Rate limit + loglama olmadan bu genelde ancak banka bildirimiyle fark edilir, bu da geç kalmak demektir.