Limiti di frequenza delle API degli exchange crypto spiegati
1. Cosa significano i “limiti di frequenza API”
I limiti di frequenza delle API sono concetti semplici sulla carta. Indicano il numero massimo di richieste che un exchange accetterà in una determinata finestra temporale, come 1 secondo, 1 minuto o 1 ora. Questa è l’idea di base dietro ai limiti di frequenza API exchange crypto spiegati, ed è fondamentale per capire come funzionano i limiti API degli exchange.
Non confondere i limiti di frequenza con le commissioni. Una commissione è denaro addebitato per un trade, un prelievo o un livello di servizio. Un limite di frequenza è una regola sul traffico, cioè un vero rate limit API crypto. Se il tuo client invia 200 richieste in un minuto e l’exchange ne consente solo 120, la 121ª richiesta può fallire anche se il tuo account è gratuito.
I limiti sono anche diversi dai livelli dell’account. Alcuni exchange concedono limiti più ampi agli utenti verificati, ai market maker o ai piani a pagamento, ma il limite di frequenza esiste comunque. Un livello può consentire 10 richieste al secondo, mentre un altro ne consente 50. L’exchange sta comunque tracciando un confine.
Un modo pratico di pensarci: i limiti di frequenza sono la politica d’ingresso dell’API. Potresti essere ammesso, ma non tutto in una volta. E questo conta molto nei giorni di forte traffico.
2. Perché gli exchange usano i limiti di frequenza
Gli exchange usano i limiti di frequenza per tre motivi molto semplici: proteggere l’infrastruttura, ridurre gli abusi e mantenere i sistemi stabili durante i picchi di traffico. Un mercato può muoversi rapidamente in 30 secondi, e un’ondata di script può mettere sotto pressione ordini, controlli dei saldi e feed di prezzo contemporaneamente. Se un client invia troppe chiamate, ne risentono tutti.
C’è anche una questione di equità. Senza limiti, un bot troppo aggressivo potrebbe martellare gli endpoint pubblici e penalizzare gli utenti più piccoli. Non è teoria: è il tipo di problema che emerge quando una nuova quotazione o una vendita improvvisa spinge il volume delle richieste oltre il normale.
Alcuni limiti servono a bloccare scraping, abusi o loop accidentali. Un loop difettoso può inviare la stessa richiesta 500 volte prima che qualcuno se ne accorga. L’exchange vede una tempesta, non un incidente.
Detto questo, i limiti non servono solo a difendersi. Aiutano gli exchange a mantenere aggiornati i dati di mercato e reattivi i sistemi di ordini quando il traffico aumenta. Un’API stabile è più facile da fidare di una che cede sotto un afflusso improvviso.
3. Come vengono misurati i limiti di frequenza
La maggior parte degli exchange misura i limiti in richieste al secondo o richieste al minuto. Altri usano un sistema misto, con un tetto piccolo per secondo e uno più ampio per minuto. L’exchange può anche assegnare pesi diversi a endpoint diversi. Un semplice controllo del prezzo può valere 1 unità, mentre l’inserimento di un ordine o una query sulla cronologia ne vale di più.
I limiti specifici per endpoint sono comuni. Un endpoint pubblico per il ticker può consentire più chiamate di un endpoint privato per il saldo. Anche limiti separati per pubblico e autenticato compaiono spesso.
Alcune API consentono burst. Significa che puoi inviare un breve gruppo di richieste sopra il ritmo normale per alcuni secondi, purché la media resti entro la regola. Altre sono rigide e piatte, senza alcuno spazio per burst. La differenza cambia il modo in cui scrivi un client.
Cerca l’unità, la finestra e il peso. Questi tre numeri raccontano la maggior parte della storia. Una pagina che dice solo “rate limited” non basta.
4. Dove i limiti si manifestano nei flussi di lavoro reali
I limiti emergono prima di tutto nelle attività ordinarie. Un trader che aggiorna i prezzi ogni 2 secondi può raggiungere rapidamente il tetto se l’app controlla 20 mercati alla volta. Uno sviluppatore che sincronizza i saldi ogni 5 secondi può andare bene all’inizio, poi vedere improvvisamente dei fallimenti quando l’elenco dei wallet passa da 3 asset a 30.
L’inserimento degli ordini è un altro punto critico. Un bot che testa segnali, cancella ordini obsoleti e ne reinvia di nuovi può consumare in fretta il budget di richieste, soprattutto durante la volatilità. Un minuto il sistema sembra tranquillo. Poi, dopo 12 variazioni di prezzo, non lo è più.
I backfill storici sono ancora più facili da sottovalutare. Scaricare 90 giorni di candele, cronologia trade o eseguiti spesso richiede migliaia di richieste, e ognuna compete con il traffico live se l’exchange non offre un endpoint batch. Se l’API restituisce solo 100 righe per chiamata, il conto diventa rapidamente pesante.
Il polling è la tassa nascosta del tempo, non del denaro. Una dashboard che controlla cinque endpoint ogni secondo può sembrare innocua durante i test, poi sovraccaricare il rate limit API crypto non appena gli utenti reali effettuano l’accesso. Ecco perché molti team passano dal polling alle websocket dopo il primo mese difficile.
5. Segnali d’allarme comuni e modalità di errore
Il segnale più evidente è un errore HTTP, spesso uno stato 429 per troppe richieste. Alcuni exchange restituiscono un messaggio chiaro. Altri danno un errore generico e si aspettano che il client legga gli header. Non piacevole, ma comune.
Un altro esito è il throttling temporaneo. L’API può rallentare le risposte prima di iniziare a rifiutare le chiamate. Invi una richiesta, poi aspetti 1,5 secondi per una risposta che prima arrivava in 120 millisecondi. Quel ritardo è il campanello d’allarme prima dello stop.
Alcune piattaforme applicano una finestra di blocco dopo violazioni ripetute. Il blocco può durare 30 secondi, 5 minuti o più. Nei casi più gravi, l’exchange può bloccare l’indirizzo IP o la chiave API. Se un bot continua a riprovare alla cieca, la penalità peggiora.
Possono verificarsi anche rifiuti degli ordini senza un messaggio pulito sul limite di frequenza. Una richiesta di trade può fallire perché il client ha già consumato la quota burst consentita, anche se lo stesso account può ancora recuperare dati pubblici. Questa discrepanza confonde molti team durante la prima integrazione.
6. Come leggere correttamente le regole sui limiti di frequenza di un exchange
Inizia dalla documentazione, ma non fermarti alla prima tabella. Cerca i pesi degli endpoint, le regole di cooldown e le note sulle eccezioni. Una pagina può indicare “10 richieste al secondo” e poi aggiungere, in piccolo, che gli endpoint per gli ordini valgono peso 5 ciascuno. Questo cambia di molto la capacità reale.
Gli header sono importanti. Molti exchange inviano header sui limiti di frequenza nella risposta, e spesso rivelano quante richieste restano, quanto manca al reset o se la chiamata corrente ha consumato peso extra. Se la documentazione è vaga, gli header di solito lo sono meno.
Fai attenzione alle eccezioni nascoste. I dati di mercato pubblici possono seguire una regola, mentre le chiamate private di trading ne seguono un’altra. Anche le connessioni websocket possono avere limiti separati. Se leggi solo il primo paragrafo, potresti perdere la parte che fa male.
I team spesso tengono una checklist semplice prima dell’integrazione. Se vuoi una checklist più ampia prima del lancio, l’articolo su la checklist di sicurezza per gli exchange crypto è un buon complemento, perché gli errori sui limiti di frequenza e quelli di sicurezza spesso compaiono insieme quando una chiave API viene esposta o usata in modo improprio.
Presta attenzione anche al linguaggio della documentazione. Formulazioni brevi possono nascondere vincoli reali. Se la pagina dice “uso corretto”, chiedi il numero. Se dice “soggetto a modifiche”, chiedi chi le effettua e con quale frequenza. La risposta conta prima della produzione, non dopo un blackout.
7. Termini sui limiti di frequenza da conoscere
Throttle significa che l’exchange ti sta rallentando intenzionalmente. Non è ancora un errore, ma ci va vicino. Potresti ricevere comunque risposte, solo più tardi del solito.
Quota è l’ammontare totale consentito in un periodo. Se la quota è di 100 richieste al minuto, quel numero si azzera quando la finestra del minuto si chiude. La quota è il budget. Va spesa con attenzione.
Burst allowance è lo spazio extra a breve termine che un’API può concederti. Un burst di 20 richieste può andare bene anche se il ritmo stabile è di 5 al secondo. Il problema è che la media deve comunque rientrare nella regola.
Backoff è la pausa prima del retry successivo. Un client che aspetta 250 millisecondi, poi 500 millisecondi, poi 1 secondo si comporta in modo paziente. Un client che riprova subito si comporta come se fosse rotto.
Ban window indica il periodo durante il quale l’exchange blocca ulteriori richieste dopo una violazione. Le richieste pesate sono chiamate che valgono più di 1 unità. Se un endpoint ha peso 10, allora 10 chiamate di quel tipo possono consumare la stessa allowance che servirebbe a 100 chiamate leggere. È il tipo di dettaglio che fa saltare un bot alle 3 del mattino.
8. Esempi: scenari tipici di limiti
Esempio 1: un’app che controlla i prezzi. Supponiamo che l’app monitori 8 coppie e si aggiorni ogni 5 secondi. Sembra poco, ma se ogni aggiornamento colpisce un endpoint pubblico separato e l’exchange consente solo 10 richieste al secondo, l’app può andare bene finché non arrivano più utenti e lo stesso server inizia a servire 50 sessioni. A quel punto il limite diventa visibile.
Esempio 2: un bot di trading. Il bot controlla i segnali, piazza ordini, cancella ordini obsoleti e conferma gli eseguiti. Se ogni azione usa endpoint autenticati con pesi più elevati, il bot può raggiungere il limite dopo pochi cicli veloci. Un bot prudente usa stato memorizzato nella cache, meno controlli del saldo e un ritardo di retry che cresce dopo ogni fallimento.
Esempio 3: un job di backfill intensivo. Uno script di ricerca che scarica 180 giorni di dati a candela può attivare i limiti molto prima di finire. Se l’exchange restituisce solo 200 righe per richiesta, il job potrebbe aver bisogno di centinaia di chiamate. Un approccio migliore è raggruppare per giorno, fare pause tra i blocchi e riprendere dall’ultimo timestamp pulito dopo un errore.
Se stai confrontando piattaforme per uno di questi casi, la scelta dell’exchange conta quanto il codice. Una guida pratica come come scegliere un exchange crypto aiuta quando devi capire se il design dell’API si adatta al tuo flusso di lavoro, non solo se la schermata di trading è gradevole.
C’è un secondo tipo di esempio che vale la pena citare: un’API che sembra pulita ma si comporta male sotto carico. Alcuni progetti sembrano perfetti in sandbox e poi falliscono sugli endpoint live perché le regole di limite sono più rigide in produzione. Ecco perché i soli dati di test non bastano mai.
Un’ultima nota pratica. Se stai cercando di proteggere un client dai ban, leggere come verificare un exchange di criptovalute può aiutarti a capire se la piattaforma pubblica regole chiare, contatti di supporto e un comportamento API coerente prima che tu le affidi traffico reale.
Per chi costruisce bot o dashboard, la soluzione più pulita di solito non è “invia più velocemente”. È “invia meno”. Memorizza i risultati in cache per 3 secondi, elimina le chiamate duplicate e non chiedere lo stesso saldo due volte nello stesso ciclo. Questa piccola disciplina mantiene l’API più tranquilla e i log più leggibili.
Un ultimo appunto: se una pagina di documentazione è così vaga che non riesci a capire se una richiesta vale 1 unità o 5, trattala come un avviso, non come un enigma. Chiedi al supporto il limite esatto, la finestra di reset e la penalità per gli sforamenti. Non sono dettagli decorativi: determinano se l’integrazione sopravvive alla sua prima ora di punta.
