Hız Sınırları

TwexAPI verim limitleri, 429 yönetimi, Retry-After davranışı ve üretim işleri için sayfalama güvenli geri çekilme.

TwexAPI, hesap kararlılığını ve üst akış X/Twitter getirme kapasitesini korumak için hız sınırları uygular. Dışa aktarmaları, agent döngülerini ve zamanlanmış işleri her hatadan sonra tam hızda yeniden denemek yerine limitlere saygı gösterecek şekilde tasarlayın.

Verim beklentileri

TwexAPI üretim iş yükleri için tasarlanmıştır. Pazarlama kıyaslamaları normal koşullarda istemci başına saniyede 100 isteğe kadar çıkabileceğini belirtir; ancak etkin limitiniz uç nokta türüne, hesap katmanına ve mevcut platform yüküne bağlıdır.

Yayınlanan verimi üst sınır olarak değerlendirin — her entegrasyon için hedef değil.

Limite ulaştığınızda

Aşılan limitler HTTP 429 Too Many Requests döndürür. Bazı yanıtlarda Retry-After başlığı (saniye cinsinden makul bekleme süresi) bulunur. Varsa, bir sonraki çağrıdan önce en az o kadar saniye bekleyin.

Tipik yanıt şekli:

{
  "detail": "Rate limit exceeded. Try again later."
}

MCP’de twexapi_request aynı durumu araç sonucu içinde gösterir. Geri çekilmeden önce imleçleri ve tamamlanan satırları koruyun.

Kurtarma kontrol listesi

Geri çekilme örneği

İsteğe bağlı Retry-After ile Python:

import time
import requests

def call_with_backoff(fn, max_attempts=5):
    delays = [5, 15, 45, 120, 300]
    for attempt in range(max_attempts):
        response = fn()
        if response.status_code != 429:
            return response

        retry_after = response.headers.get("Retry-After")
        wait = int(retry_after) if retry_after and retry_after.isdigit() else delays[min(attempt, len(delays) - 1)]
        time.sleep(wait)

    return response

Prefect kullanıcıları aynı gecikmeleri retry_delay_seconds ile yansıtabilir — bkz. Prefect guide.

429’dan kaçınan tasarım desenleri

Paralelleştirmek yerine sayfalayın

Tek bir dışa aktarmayı hızlandırmak için 1. sayfayı yirmi kez paralel getirmek işe yaramaz. Uç noktalar bağımsız parçaları açıkça desteklemedikçe imleçleri sırayla ilerletin.

Okuma ve yazma zamanlamalarını ayırın

Yazmalar genelde okumalardan daha sıkı pratik limitlere sahiptir. Gönderi, beğeni ve takipleri arama ve profil sorgularından daha yavaş bir kuyrukta çalıştırın.

Kararlı sorguları önbelleğe alın

user_id, profil alanları ve tweet meta verilerini aşağı akış adımları yeniden kullanıyorsa saklayın. Daha az yinelenen sorgu, daha az sayılan istek demektir.

MCP explore’u idareli kullanın

Keşif çağrıları da kullanıma sayılır. İş süresince seçilen method ve path değerlerini önbelleğe alın.

No-code ve agent platformları

Platform webhook’ları (Catch Hook, Custom Webhook) agent devirlerini alır — TwexAPI’ye özgü olay akışları değildir. Webhook alımından sonra geri çekilmeli REST takip çağrılarını zamanlayın.

MCP ve REST

Her iki yol da aynı hesap limitlerini ve kredi modelini paylaşır. Gecikmesiz döngüleyen bir agent, sıkı bir SDK döngüsü kadar hızlı 429 tetikleyebilir.

Uzun süren üretim dışa aktarmalarında otonom agent döngüsü yerine açık yeniden deneme politikası olan doğrudan REST veya SDK tercih edin.

Hız sınırı sağlığını izleme

İstek başına şu alanları günlüğe kaydedin:

• HTTP durumu
• Uç nokta yolu
• İmleç veya sayfa indeksi
• Yeniden deneme numarası
• Varsa Retry-After

Tek bir API anahtarı veya iş akışı için 429 oranı eşiği aştığında uyarı verin.

İlgili sayfalar

• Error Handling
• Authentication
• API Overview
• Agent MCP Handoff