Limiti tariffari e concorrenza

Le impostazioni predefinite attuali sono 180 richieste/minuto per IP, 60 per chiave e 90 per account. Il limite IP si applica anche alle richieste autenticate; le chiavi su un account condividono il limite di velocità dell'account. Un account può eseguire al massimo 5 richieste di dati contemporaneamente e ogni chiave ha anche il proprio limite max_concurrent_requests configurato. I corpi sono limitati a 256 KB e le pagine a 50 elementi.

L'indennità giornaliera limita le chiamate dati REST riuscite in un giorno; richieste di limiti tariffari entro un minuto; Richieste di limiti di concorrenza ancora in esecuzione. La verifica non utilizza chiamate dati giornaliere ma ha comunque una tariffa limitata. L'abbassamento del limite o la creazione di un'altra chiave non ignorano l'indennità giornaliera dell'account. Le richieste seriali riducono la concorrenza ma non aumentano l'indennità giornaliera.

Dopo 10 chiamate REST di dati viene restituito HTTP 429 con API_DAILY_LIMIT_REACHED. Attendi le 00:00 Asia/Shanghai. Creare o ruotare una chiave non azzera la quota dell’account.

Per RATE_LIMITED, rispetta Retry-After e distanzia i tentativi. Restano necessari chiavi valide, permessi e limiti di frequenza, concorrenza e account.

Scegli un percorso di ripristino utilizzando error.code, non solo HTTP 429. RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset descrivono la finestra del tasso breve. Il ripristino è un timestamp Unix in secondi, non il tempo di ripristino giornaliero. L'esaurimento della finestra di velocità fornisce Retry-After in pochi secondi; le risposte alla concorrenza o all'indennità giornaliera 429 possono ometterlo. Leggi daily_usage per l'utilizzo quotidiano e error.details.daily_usage per un errore di limite giornaliero.

Ogni richiesta REST di dati riuscita conta una volta, inclusi risultati vuoti e risposte dalla cache. Riutilizzare lo stesso Idempotency-Key e gli stessi parametri restituisce il risultato originale senza un ulteriore utilizzo giornaliero. Errori e risposte 304 non consumano la quota giornaliera.

Per RATE_LIMITED, rispetta Retry-After e distanzia i tentativi. Restano necessari chiavi valide, permessi e limiti di frequenza, concorrenza e account.

Per RATE_LIMITED, attendi prima Retry-After. Se assente, ridurre la concorrenza e utilizzare il backoff esponenziale con un piccolo ritardo casuale e un limite ai tentativi; ad esempio, attendere 1, 2, quindi 4 secondi prima di interrompere e registrare l'ID della richiesta. Non riprovare API_DAILY_LIMIT_REACHED ogni secondo: attendere il reset giornaliero. Correggere l'autenticazione, le autorizzazioni o i parametri prima di ritentare richieste 401, 403 o non valide.

Mantenere la chiave di idempotenza e i parametri invariati quando si riprova a eseguire la stessa operazione sui dati REST. Generare una nuova chiave per una nuova operazione logica; la modifica dei parametri durante il riutilizzo della chiave provoca IDEMPOTENCY_CONFLICT. Tratta le diverse pagine come operazioni diverse. Anche le risposte 5xx riproducibili richiedono un backoff limitato.

Se due chiavi di un account completano ciascuna 5 chiamate dati, la disponibilità giornaliera condivisa di 10 chiamate REST viene esaurita, anche se non è stata effettuata alcuna richiesta nell'ultimo minuto. Il sito Web prevede un'indennità separata per 10 ricerche. MCP non utilizza alcuna indennità giornaliera, ma troppe richieste MCP simultanee possono comunque attivare RATE_LIMITED.