Uygulamanız için link kısaltma API'si nasıl seçilir

Bir servis fiyatına ya da özellik listesinin uzunluğuna göre değil, altı ölçüte göre seçilir — ve her ölçüt ya entegrasyondan önce doğrulanabilir ya da doğrulanamaz. Bir ölçüt doğrulanamıyorsa, bu zaten cevabın kendisidir.

Yaygın hata, istek sınırına bakıp onun kapasiteyi tarif ettiğini sanmaktır. Tarif etmez: kısaltıcılarda genelde birbirinden bağımsız iki sınır bulunur ve sizi durduran, aklınıza gelmeyen o öteki olur.

Aşağıda her ölçüt için: neye bakılacak, Bitly belgelerinde ne yazıyor ve bizim sayılarımız neler.

Ölçüt 1. İstek sınırı bir sayı olmalı

İşe yarar belge şöyle der: «dakikada 35 istek, saatte 2000». İşe yaramayan belge şöyle der: «sınırlar planınıza bağlıdır, hesap ayarlarınızdan kontrol edin».

Fark ifadede değil, kapasiteyi önceden hesaplayıp hesaplayamamanızda. Bağlantılar bir kullanıcı eylemiyle oluşuyorsa, kaç eşzamanlı kullanıcıda tavana vuracağınızı bilmeniz gerekir. Herkese açık bir sayı yoksa bu, canlı trafikte öğrenilir.

Bitly'nin belgelediği şunlar: tek bir IP adresinden en çok beş eşzamanlı bağlantı; dakika sınırı saat sınırının onda birine eşit; /v4/shorten için örnek olarak saatte 1000 çağrı veriliyor. Planlara göre kesin değerler o sayfada yok — belge sizi hesap ayarlarına yönlendiriyor.

IP başına beş bağlantı sınırı göründüğünden daha önemli. Uygulamanız tek bir çıkış adresinin arkasında yaşıyorsa — konteyner altyapısında genellikle öyledir — istemcinizin paralelliği beşte kalır, size saatte kaç istek satılmış olursa olsun.

Ölçüt 2. Sınırlanan istekler mi, bağlantılar mı

İşte o ikinci sınır; ve işi genellikle durduran da odur.

Bitly'nin plan tablosunda bu iki sayı ayrı bölümlerde duruyor, eşleştirmeyi kendiniz yapmanız gerekiyor. Ücretsiz planda: ayda 1000 API isteği — ve ayda 5 kısa bağlantı. İstek kotası süsten ibaret: API'yi bin kez çağırabilir, yine de altıncı bağlantıyı oluşturamazsınız.

Dolayısıyla herhangi bir servise sorulacak ilk soru şudur: ne sayılıyor, çağrılar mı, oluşturulan bağlantılar mı? İkisi de sayılıyorsa, sizin yük profilinizde hangisi daha önce tükeniyor.

Ölçüt 3. Sınır tükendiğinde ne olur

Sınır yalnızca bir sayı değil, bir davranıştır da. Entegrasyondan önce netleştirin:

• hangi kod dönüyor. 429 beklenir, ama servisin dakika sınırını aylık kotadan ayırt edip etmediği önemlidir: bunlar farklı arızalardır ve çözümleri de farklıdır;
• yanıtta kalan miktar var mı. Servis kalanı döndürüyorsa önceden yavaşlayabilirsiniz. Döndürmüyorsa sorunu ancak reddedildiğinizde öğrenirsiniz;
• toplu çağrılar nasıl sayılıyor. En sık rastlanan tuzak. Bir metot tek istekte 100 bağlantı oluşturuyorsa, bir birim mi harcıyor yoksa yüz mü? Bizimki yüz harcıyor: 100 bağlantılık parti 100 birim düşer, çünkü aksi halde toplu metot hız sınırını dolanmanın yolu olurdu. Adayınızın bunu nasıl ele aldığını kontrol edin, yoksa kapasite hesabınız yüz kat yanlış olur.

Ölçüt 4. Kimlik doğrulama yöntemi

Kural basit: üçüncü taraf yoksa anahtar yeter ve OAuth güvenlik katmadan iş yükü ekler. Sunucunuz API'yi kendi hesabıyla çağırıyorsa — bu, başlıktaki bir anahtardır. Başkasının uygulaması sizin kullanıcılarınızın adına çağırıyorsa — bu OAuth'tur.

Adayın belgelerinde aranacaklar:

• sır nasıl taşınıyor. Başlıkta olması iyi. Sorgu dizesinde parametre olarak olması kötü: adresler web sunucusu günlüklerine, Referer başlığına ve tarayıcı geçmişine yerleşir;
• bir anahtar diğerlerini bozmadan iptal edilebiliyor mu. Entegrasyon başına bir anahtar, ele geçeni her şeyi durdurmadan iptal etme imkânı demektir;
• OAuth varsa şeması ne kadar güncel.

Bu son maddeyi açmaya değer. Ocak 2025'te IETF, OAuth 2.0 güvenliğinin yürürlükteki uygulama derlemesi olan RFC 9700 belgesini yayımladı. Belge, implicit grant ile resource owner password credentials akışlarını, yani uygulamanın kullanıcıdan doğrudan kullanıcı adı ve parola istediği akışı resmen kullanımdan kaldırdı.

Bitly'nin kimlik doğrulama sayfası ise Resource Owner Credentials Grant'i hâlâ desteklenen bir yöntem olarak anlatıyor; yanında POST /oauth/access_token üzerinden kullanıcı adı ve parolayı belirteçle değiştirmeyi ve konsol uygulamaları için HTTP Basic'i de. Bu kendi başına bir güvenlik açığı değil, ama belgelerin uygulamaların güncel sürümünün gerisinde kaldığının işareti.

Ölçüt 5. Yanıt hızı ve başkasının sayılarına neden güvenilmez

Birbirinden tamamen farklı iki büyüklük düzenli olarak karıştırılıyor. Yönlendirme gecikmesi, kısa bağlantıya tıklayan kişinin beklediği süredir. API gecikmesi, bağlantı oluştururken kodunuzun beklediği süredir. İlki dönüşümü etkiler, ikincisi kendi işleyicinizin zaman aşımına sığıp sığmadığınızı belirler.

Pazarlama materyallerindeki sayılara burada inanılacak bir şey yok: sizin bölgenizden değil, sizin hacminizde değil, sizin planınızda ölçülmemişler. Bu, on dakikada ölçülür ve ancak kendiniz ölçebilirsiniz:

1. İki üç adaydan deneme anahtarı alın.
2. Yüz bağlantıyı sırayla oluşturup her isteğin süresini kaydedin.
3. Ortalamaya değil, 95. ve 99. yüzdeliklere bakın. Ortalama, tam da işleyicinizi deviren durumları saklar.
4. Dizüstünüzden değil, canlı ortamınızın bulunduğu bölgeden tekrarlayın.
5. Yönlendirme gecikmesini ayrıca ölçün — API yanıtıyla ilgisi yoktur.

Bir aday satış temsilcisiyle görüşmeden deneme erişimi vermiyorsa, bu da bir ölçüm sonucudur.

Ölçüt 6. Doğrulanabilir belgeler

Son madde dışarıdan beş dakikada doğrulanır: belgelerden üç dört uç nokta alın ve anahtarsız çağırın. 401 yanıtı rotanın var olduğunu ve yetki istediğini gösterir. 404 yanıtı, belgelerin var olmayan bir şeyi anlattığını gösterir.

Sayılarla yan yana

Bitly verileri, Ekim 2026 itibarıyla fiyatlandırma sayfasından alındı; fiyatlar ve sınırlar değişir, karar vermeden önce güncel sayfayla karşılaştırın. Bizim veriler servisin kodundan.

Bu tabloda dikkatle okunması gereken üç şey var.

İki servis farklı eksenlerde sınırlıyor. Bitly aylık çağrıyı kısıtlıyor, biz dakika ve saat frekansını. Soyut olarak biri diğerinden iyi değil; bunlar farklı rejimler. Aylık kota ayın birine kadar tamamen tükenir, dakika sınırı bir dakikada kendini toplar. İkincisi tepeli yüke, birincisi düzgün akan arka plan trafiğine uygun.

Bitly'nin webhook'ları yalnızca Enterprise'da, yani teklif usulü. Ayda 199 dolarlık kademe bile içermiyor. Uygulamanız tıklama olaylarına ihtiyaç duyuyorsa, bu satışla yapılacak bir görüşme demektir.

Bizim taraftan dürüst uyarılar. Bizim webhook'lar da her planda yok — yalnızca Premium'da. Ücretsiz planda dosyadan toplu yükleme bulunmuyor. Ücretsiz planda analitik geçmişi bir yıl değil, 30 gün.

Lix.li tam olarak ne veriyor

Sınırlar yayımlanmış ve plana bağlı: ücretsiz planda dakikada 15 istek ve saatte 600; Pro'da 35 ve 2000; Premium'da 60 ve 3600. API üzerinden ayda ücretsiz planda 150 bağlantı, Pro'da 500, Premium'da sınırsız sayıda oluşturulabilir.

Özel sınırlar talep üzerine veriliyor. Bu pazarlama kaçamağı değil, ayrı bir mekanizma: belirli bir müşterinin sınırı plandan ayrı saklanıyor, kendi geçerlilik süresi var ve plan sınırından önce kontrol ediliyor. Yük profiliniz standart ızgaraya sığmıyorsa — diyelim bir milyon bağlantılık tek seferlik bir geçiş ya da takvime bağlı yinelenen bir tepe — bize yazın, tavanı sizin durumunuza göre yükseltelim; ayın geri kalan yirmi dokuz gününde ihtiyacınız olmayan bir kademeye sizi itmek yerine.

Kimlik doğrulama X-Api-Key başlığındaki bir anahtarla yapılıyor. Anahtarlar panelden oluşturulup iptal ediliyor, her birinin kendi sınırı var, eşleştirme özet üzerinden gidiyor. OAuth yok ve bu bilinçli: senaryolar sunucu tarafında ve içlerinde kullanıcının rıza vermesi gereken bir üçüncü taraf çıkmıyor.

Belgeler bir OpenAPI 3.1 spesifikasyonu ve etkileşimli bir sayfa. Uç noktalar bağlantıları, grupları, A/B testlerini ve dönüşümleri kapsıyor. Yanıt kodları API belgelerinde, servisin bunun çevresinde yaptıkları ise bağlantı kısaltma API sayfasında.

Bir akşamda nasıl karar verilir

Bağlantılar arka uçtan oluşuyor, üçüncü taraf uygulama yok
    → başlıkta anahtar, OAuth gerekmiyor

Bağlantılar bir kullanıcı eylemiyle oluşuyor
    → dakika sınırını ortalamaya değil tepeye göre ölçün

Katalog ve dışa aktarma yüklüyorsunuz
    → toplu metot arayın ve sınırı nasıl harcadığını sorun

Tıklama olayları gerekiyor
    → webhook'ların hangi planda olduğuna ve o planın Enterprise olup olmadığına bakın

Yük profiliniz fiyat ızgarasına sığmıyor
    → üst kademeye para vermeden önce özel sınırı sorun

Servis sınırları sayıyla yayımlamıyor
    → size hiçbir sınır vaat edilmediğini varsayın

Entegrasyon aşaması için iki yazı: webhook nedir, istatistiği sorgulamak yerine olay almayı tercih ediyorsanız; ve 301, 302, 307, 308 yönlendirmeleri ile istek yöntemi çözümlemesi — 301'in POST'u neden GET'e çevirdiğini ve bunun postback alımını nasıl bozduğunu anlatıyor. Bağlantılar dışa aktarmadan parti halinde geliyorsa toplu link kısaltmaya bakın.

Son bir şey. Belgelerden doğrulanamayan tek ölçüt, hacminiz büyüdüğünde ne olacağıdır. Bu yüzden bir deneme anahtarı ve kendi ortamınızdan atılacak iki yüz kadar istek bir akşama değer — servis mimari şemanıza girdikten sonra değil, girmeden önce harcanan bir akşama.