Dokümanlar/API ve Webhook'lar/İstek Limitleri

Hız Limitleri

SecureCodingHub her API anahtarı için dakika ve saat başı bir üst sınır uygular. Limitler normal işletim sırasında görünmez kalacak ve kontrolden çıkmış script'ler platformu zorlamadan durduracak şekilde tasarlanmıştır.

Varsayılan limitler

PencereLimitHeader
Dakika başı60 istekX-RateLimit-Window: per_minute
Saat başı1.000 istekX-RateLimit-Window: per_hour

Her iki pencere de her istekte değerlendirilir. Daha dar olan pencere (60/dakika) kısa burst'leri yönetir; saatlik pencere sürekli yükü yönetir. Hangi pencerenin tetiklendiğini incelemenize gerek yok; yalnızca Retry-After header'ına saygı gösterin — istek aşıldığında 429 Too Many Requests ile reddedilir.

Reddedilme yanıtı

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Window: per_minute
X-RateLimit-Limit: 60

{ "error": "rate_limited" }

Retry-After her zaman bir tamsayı saniye sayısıdır — bir sonraki isteğin başarılı olması için en küçük güvenli gecikmedir. X-RateLimit-Limit ise tetiklenen pencerenin tavanını yansıtır.

Kayan ve sabit pencere karşılaştırması

Dakika başı pencere takvim dakikasına (UTC) sabitlenmiştir. 13:42:59 anındaki bir istek ile 13:43:01 anındaki bir istek farklı kovalara düşer. Saat başı pencere ise son 60 dakika boyunca gerçek bir kayan toplamdır. Bu da normal kullanımda dakikalık üst sınıra defalarca dokunmadıkça saatlik üst sınıra hiç çarpmayacağınız anlamına gelir.

Önerilen client davranışı

  • 429 alındığında en az Retry-After saniye bekleyin ve bir kez yeniden deneyin.
  • Jitter kullanın: birçok worker aynı anda limite çarptığında thundering herd'i önlemek için retryAfter + random(0, 5) saniye.
  • Batch boyutunu kontrol ediyorsanız, anahtar başına dakikada 50 isteği geçmeyin — sizi üst sınırın güvenli altında tutar.
  • Yüksek hacimli işler için (veri dışa aktarımı, toplu kullanıcı sağlama), tek bir anahtarı paylaşmak yerine her worker'a bir anahtar verin.
  • 429 durumunu uyarı verilecek bir hata olarak değerlendirmeyin. Yalnızca üstel geri çekilmenin ardından tekrarlanan başarısızlıklar için uyarı verin.

Yeniden deneme deseni

Jitter ile Retry-After'a saygı gösteren minimal bir Node örneği:

async function call(path) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch(`https://api.limeplate.com${path}`, {
      headers: { Authorization: `Bearer ${process.env.SCH_API_KEY}` },
    });
    if (res.status !== 429) return res;
    const wait = parseInt(res.headers.get('Retry-After') || '60', 10);
    const jitter = Math.floor(Math.random() * 5);
    await new Promise(r => setTimeout(r, (wait + jitter) * 1000));
  }
  throw new Error('exhausted retries on 429');
}

Daha yüksek kota talebi

Çoğu entegrasyon varsayılan limitler içinde rahatça çalışır. İş yükünüz gerçekten daha yüksek bir tavana ihtiyaç duyuyorsa — örneğin 10.000 kullanıcı için ilerleme çeken gecelik bir Looker yenilemesi — API anahtar adı, entegrasyon amacı ve beklediğiniz tepe istek/dakika ile birlikte support@securecodinghub.com adresine yazın. Token'ı döndürmeden anahtar başına limitleri yükseltebiliriz.

Hız limitine tabi olmayanlar

SecureCodingHub'dan kabul ettiğiniz gelen webhook teslimatları bizim tarafımızdan hız limitine tabi tutulmaz. Sizin uç noktanıza gönderdiğimiz giden webhook teslimatları Webhook'lar altında belgelenen ayrı bir yeniden deneme programını takip eder.