İstek hızı sınırları

Listings ve Social genelinde plana göre istek sınırları, 429 yanıtının yapısı ve bekleme süresini artırarak yeniden deneme.

Listings API, istekleri hesabınız bazında planınızın istek hızı sınırına göre ölçer. Sınır içinde kalmak entegrasyonunuzun hızlı yanıt vermesini sağlar; sınırı aşmak ise uygun şekilde yeniden denemek için gereken tüm bilgilerle birlikte 429 Too Many Requests döndürür.

Plana göre sınırlar

API'yi ücretli bir plan olmadan mı deniyorsunuz? Ücretsiz sandbox günlük erişimini başlattığınızda, geçerli istek sınırları API anahtarıyla birlikte döndürülür.

Sınırlar plana bağlıdır ve hesap başına uygulanır: bir hesaptaki tüm API anahtarları aynı kotadan kullanır. İstekler üç zaman aralığında ölçülür: ani istek artışları için dakikalık bir sınır, saatlik bir sınır ve günlük bir üst sınır. Kullanılan endpoint ne olursa olsun her istek kotadan aynı miktarda düşer. Ücretsiz deneme, seçtiğiniz plan üzerinden yürütülür; dolayısıyla ilk istekten itibaren o planın sınırlarına tabidir.

Social aynı kotayı kullanır

Social endpoint'leri de diğer tüm endpoint'lerle hesap başına aynı istek kotasına tabidir. 500 satır taşıyan bir POST /social/bulk-posts, kotadan 500 istek değil, bir istek düşer; bu nedenle çok miktarda içerik yüklemek için kotayı en az tüketen yöntem toplu işlemdir.

Listings ve Social ayrı aboneliklerdir, ancak ayrı kotaları yoktur. Her ikisine de sahip bir hesap için iki planın sınırlarından yüksek olanı, tüm endpoint'ler genelinde tek bir kota olarak uygulanır; sınırlar toplanmaz ve her ürün için ayrı bir kota tanımlanmaz. Listings Launch ve Social Growth kullanan bir müşterinin tüm trafiği, yukarıdaki Growth değerlerine göre ölçülür.

429 yanıtı

Bir sınırı aştığınızda API, HTTP 429 durum kodunu ve standart hata yanıtını döndürür. Yeniden denemeler için üç alan önemlidir:

• retry_after_seconds: yeniden denemeden önce ne kadar beklemeniz gerektiği. Retry-After HTTP üst bilgisi mevcutsa aynı değeri taşır.
• correlation_id: destek ekibiyle iletişime geçtiğinizde belirtmeniz gereken istek tanımlayıcısı.
• doc_url: hata kodları başvuru kaynağındaki rate_limited girdisine yönlendiren bağlantı.

{  "error": {    "code": "RATE_LIMITED",    "message": "Too many requests. Slow down.",    "retry_after_seconds": 30,    "correlation_id": "9f2c1e64-2b1a-4b0e-9f1a-2c7d5e8a1b3c",    "doc_url": "https://listingsapi.com/docs/error-codes#rate_limited"  }}

429 yanıtlarını bekleme süresini artırarak ele alma

retry_after_seconds mevcutsa buna uyun; aksi takdirde bekleme süresini üstel olarak artırın: art arda gelen her 429 yanıtında gecikmeyi bir üst sınıra ulaşana kadar iki katına çıkarın ve çok sayıda istemcinin aynı anda yeniden denemesini önlemek için küçük rastgele sapmalar ekleyin.

import randomimport time import requests MAX_RETRIES = 5  def get_with_backoff(url: str, headers: dict, max_retries: int = MAX_RETRIES):    for attempt in range(max_retries):        resp = requests.get(url, headers=headers)        if resp.status_code != 429:            resp.raise_for_status()            return resp.json()         # Prefer the server's hint; fall back to exponential backoff + jitter.        body = resp.json().get("error", {})        retry_after = body.get("retry_after_seconds")        if retry_after is None:            retry_after = min(2 ** attempt, 30) + random.uniform(0, 1)        time.sleep(retry_after)     raise RuntimeError("Still rate limited after retrying")

Sınırın altında kalma

• Her seferinde bir sayfa isteyin: beklemeden çalışan paralel sayfalama döngüleri, 429 yanıtlarının en yaygın nedenidir. pageInfo.hasNextPage değerini okuyun ve sonraki sayfayı yalnızca mevcut sayfanın yanıtı geldikten sonra alın.
• Tüm sayfaları alıp satırları istemci tarafında elemek yerine, filter sorgu parametresiyle sunucu tarafında filtreleyin.
• Sık değişmeyen yanıtları her istekte yeniden almak yerine önbelleğe alın.