API degli exchange cripto per l’arbitraggio: REST vs WebSocket, rate limit e chiavi API sicure Ottobre 1, 2026 – Posted in: Arbitrage Software, cryptoarbitrage software
BJF TRADING GROUP · INGEGNERIA DELL’ARBITRAGGIO CRIPTO
Connettersi alle API degli exchange cripto per l’arbitraggio: REST, WebSocket, rate limit e latenza
Un’opportunità di arbitraggio esiste solo finché il tuo bot riesce a vederla e ad agire. Entrambe le cose dipendono da come ti connetti a ciascun exchange. Questa guida spiega le scelte che decidono se un gap di prezzo si trasforma in un’esecuzione o in un trade mancato: quale tipo di API usare, come funzionano i rate limit su Binance, Bybit, OKX, MEXC e Gate.io, come creare chiavi API sicure e dove si perdono i millisecondi.
In questa guida
Perché la connessione API decide i risultati dell’arbitraggio
L’arbitraggio tra exchange sembra semplice sulla carta: compri dove il prezzo è più basso, vendi dove è più alto e tieni la differenza al netto delle commissioni. In pratica la differenza dura di solito da poche centinaia di millisecondi a pochi minuti, e l’intero trade avviene tramite le API degli exchange. Tre fattori tecnici determinano ciò che catturi davvero:
- Quanto velocemente vedi il prezzo. Se le tue quotazioni arrivano in ritardo, il gap che calcoli potrebbe essere già sparito.
- Quanto velocemente arrivano i tuoi ordini. Due gambe devono essere eseguite su due piattaforme; la gamba più lenta determina il tuo prezzo di ingresso reale.
- Quanto spesso puoi fare richieste. I rate limit limitano il numero di richieste. Un bot che li raggiunge viene bloccato proprio quando il mercato è più attivo e i gap sono più ampi.
Niente di tutto questo è visibile in un backtest, ed è per questo che due bot con la stessa strategia possono produrre risultati molto diversi. Se non hai ancora misurato i gap tra i tuoi exchange, inizia con il nostro scanner di arbitraggio cripto gratuito: mostra quali coppie e piattaforme producono differenze di prezzo abbastanza ampie da coprire le commissioni.
REST vs WebSocket: a cosa serve ciascuno
Ogni grande exchange offre due modi per comunicare con esso.
REST API funziona a richiesta e risposta. Il bot invia una richiesta HTTP firmata (ad esempio “dammi l’order book” o “colloca questo ordine”) e attende la risposta. Ogni richiesta è indipendente, semplice da debuggare e conteggiata nel rate limit.
WebSocket API mantiene aperta una sola connessione. Dopo esserti iscritto a un canale, l’exchange invia ogni aggiornamento (variazioni dell’order book, trade, stato dei tuoi ordini) nel momento in cui avviene. Non c’è polling né intervallo cieco tra un controllo e l’altro.
| REST | WebSocket | |
|---|---|---|
| Dati di mercato | Snapshot su richiesta; le variazioni tra un polling e l’altro vanno perse | Stream continuo di aggiornamenti dell’order book e dei trade |
| Uso tipico nell’arbitraggio | Hedge arbitrage (tra exchange) con gap che durano secondi o più; saldi; prelievi | Arbitraggio di latenza e qualsiasi strategia con gap che durano meno di un secondo |
| Pressione sui rate limit | Alta: ogni controllo del prezzo consuma peso | Bassa per i dati: una sola sottoscrizione invece di migliaia di richieste |
| Complessità | Bassa | Maggiore: riconnessioni, numeri di sequenza, gestione dell’order book locale |
La maggior parte delle configurazioni professionali combina entrambi: WebSocket per i dati di mercato e gli aggiornamenti degli ordini, REST (o l’endpoint di trading WebSocket dell’exchange, dove disponibile) per collocare gli ordini, e REST per le chiamate amministrative lente come saldi e trasferimenti.
È anche la differenza pratica tra i nostri due bot cripto. VIP Crypto Arbitrage si connette via REST a oltre 35 exchange ed è progettato per l’hedge arbitrage tra exchange, dove i gap persistono abbastanza a lungo. SharpTrader Pro usa feed WebSocket da oltre 40 exchange, necessari per l’arbitraggio di latenza, dove la finestra è di 100–500 ms.
Rate limit sui principali exchange
I rate limit sono il motivo più comune per cui i bot di arbitraggio smettono di funzionare nel trading live. Ogni exchange conta le tue richieste per indirizzo IP, per account (UID) o per chiave API, e ti blocca o ti banna quando superi il budget. La tabella seguente riassume le regole pubblicate al momento della stesura (settembre 2026). I limiti cambiano regolarmente, quindi controlla sempre la documentazione dell’exchange e leggi gli header dei limiti nelle risposte live.
| Exchange | Principali limiti REST | Cosa succede se vengono superati | Dettagli utili |
|---|---|---|---|
| Binance (Spot) | Peso delle richieste di 6,000 al minuto per IP; limiti separati sul numero di ordini. Ogni endpoint ha il proprio peso | HTTP 429; continuare dopo il 429 porta a HTTP 418 e a un ban automatico dell’IP da 2 minuti fino a 3 giorni per i recidivi | Gli header X-MBX-USED-WEIGHT-* e X-MBX-ORDER-COUNT-* mostrano l’utilizzo attuale; Retry-After indica quanto attendere |
| Bybit (V5) | 600 richieste ogni 5 secondi per IP; limiti per UID sul trading, es. creazione ordini 20/s su spot e 10/s sui contratti lineari | Limite IP: HTTP 403 “access too frequent”, revocato dopo circa 10 minuti; limite UID: retCode 10006 | Header X-Bapi-Limit, X-Bapi-Limit-Status, X-Bapi-Limit-Reset-Timestamp |
| OKX (V5) | I limiti sono impostati per endpoint e per strumento, e i livelli VIP più alti ottengono più capacità | Risposta di errore per l’endpoint; abusi ripetuti possono limitare la chiave | Canali dell’order book: bbo-tbt (miglior bid/ask, ogni 10 ms), books5 (ogni 100 ms), books (incrementale, 100 ms); i canali L2 tick-by-tick richiedono livelli VIP più alti |
| MEXC (Spot v3) | Gli endpoint con peso per IP condividono 300 di peso ogni 10 secondi; gli endpoint con peso per UID 500 di peso ogni 10 secondi | HTTP 429 con Retry-After; violazioni ripetute portano a ban dell’IP da 2 minuti a 3 giorni |
WebSocket: fino a 30 stream per connessione, 100 messaggi al secondo; connessione chiusa dopo 60 s senza traffico (rispondi ai ping) |
| Gate.io (API v4) | Limiti per chiave pubblicati per gli endpoint spot pubblici e privati, con un limite molto più alto per la cancellazione degli ordini | Le richieste vicine alla soglia di burst vengono ritardate, quelle oltre la soglia vengono rifiutate | WebSocket: fino a 300 connessioni per IP |
Tre regole mantengono un bot entro i limiti:
- Prendi i dati di mercato da WebSocket, non da REST. Un bot che interroga l’order book di 20 coppie su 5 exchange ogni 200 ms invia 500 richieste al secondo. Gli stessi dati via WebSocket costano una manciata di sottoscrizioni.
- Leggi gli header dei limiti e rallenta prima che lo faccia l’exchange al posto tuo. Un bot che rallenta all’80% del budget non subisce mai un ban.
- Separa il traffico. Usa chiavi API diverse (o sub-account) per bot diversi, così uno script fuori controllo non può bloccare la tua chiave di trading.
Creare chiavi API in modo sicuro
Un bot di arbitraggio ha bisogno del permesso di leggere i saldi e collocare ordini. Non ha mai bisogno del permesso di prelievo. Una chiave trafugata senza diritti di prelievo può comunque causare perdite tramite trade sbagliati, ma non può svuotare il conto.
- Crea una chiave per exchange e per bot, e assegnale il nome del bot e del server.
- Abilita solo lettura e trading spot/futures. Mantieni i prelievi disabilitati.
- Limita la chiave all’indirizzo IP del tuo VPS. La maggior parte degli exchange supporta una whitelist di IP; una chiave limitata a un solo IP è inutilizzabile su qualsiasi altra macchina.
- Conserva i segreti cifrati sul server, mai in screenshot, chat o documenti condivisi.
- Ruota le chiavi dopo ogni cambio di personale, migrazione del server o sospetto di fuga di dati, ed elimina le chiavi che non usi più.
- Per strategie separate, usa i sub-account: isolano saldi e rate limit.
Da dove nasce la latenza e come ridurla
Dal momento in cui il prezzo cambia sull’exchange al momento in cui il tuo ordine viene eseguito, il tempo si spende in cinque punti: l’aggiornamento di mercato viaggia fino al tuo server, il bot rileva il gap, l’ordine firmato torna indietro, l’exchange lo abbina e la conferma ritorna. In un bot ben scritto l’elaborazione richiede pochi millisecondi. Di solito è la rete a dominare.
- Ospita il bot vicino all’exchange. La maggior parte dei grandi exchange gestisce i propri motori di matching in specifiche regioni cloud (molti a Tokyo, Singapore o Hong Kong). Un VPS nella stessa regione può ridurre il tempo di round-trip da decine di millisecondi a pochi. La nostra guida alla velocità del VPS spiega come misurarlo.
- Per le strategie multi-exchange, scegli la location che minimizza la gamba più lenta, non la media: il trade è veloce solo quanto la sua esecuzione più lenta.
- Mantieni le connessioni attive. Riutilizza le connessioni HTTPS (keep-alive) e prefirma ciò che puoi; aprire una nuova connessione TLS per ogni ordine aggiunge un intero round trip in più.
- Misura continuamente. Registra il timestamp dell’exchange di ogni aggiornamento rispetto al tuo orologio locale (sincronizzato con NTP) e monitora l’età delle quotazioni su cui opera il tuo bot.
Mantenere la connessione affidabile
Le connessioni WebSocket cadono. Gli exchange chiudono gli stream inattivi, riavviano i server e limitano la durata delle connessioni. Un bot robusto lo prevede:
- Heartbeat: rispondi ai ping (MEXC chiude una connessione dopo 60 secondi senza traffico) e inviane di tuoi se l’exchange lo richiede.
- Controlli di sequenza: gli stream incrementali dell’order book contengono ID di aggiornamento. Se ne manca uno, scarta l’order book locale e risincronizzalo da uno snapshot nuovo invece di operare su un order book corrotto.
- Riconnessione automatica con back-off: riconnettiti rapidamente, ma non in un ciclo serrato; Bybit, ad esempio, limita le nuove connessioni in ogni finestra di 5 minuti.
- Protezione dai dati obsoleti: se per una coppia non arriva alcun aggiornamento entro un tempo stabilito, sospendi il trading su quella coppia finché lo stream non si ripristina.
- Riconciliazione dello stato degli ordini: dopo una riconnessione, interroga ordini aperti e posizioni via REST prima di collocare qualsiasi nuovo ordine, così un hedge eseguito a metà non viene mai dimenticato.
- Segui gli avvisi di modifica delle API. Gli exchange deprecano endpoint e cambiano i limiti più volte all’anno. Il nostro tracker delle modifiche alle API degli exchange cripto raccoglie questi annunci in un unico posto.
Checklist prima del lancio
- Gap di prezzo confermati sulle tue coppie con lo scanner, al netto delle commissioni.
- Una chiave API per exchange: solo trading, prelievi disattivati, whitelist IP impostata.
- Dati di mercato via WebSocket; chiamate REST limitate a ordini e dati del conto.
- Header dei rate limit registrati; il bot rallenta prima dell’80% del budget.
- VPS nella regione che minimizza la gamba più lenta; tempi di round-trip misurati.
- Riconnessione, risincronizzazione e protezioni dai dati obsoleti testate interrompendo volutamente la rete.
- Primo test live con dimensione minima, poi confronta le esecuzioni con i prezzi visti dal bot.
Lascia che sia il software a gestire l’infrastruttura
Gestione delle connessioni, firma delle richieste, rate limit e riconnessioni sono integrati nei nostri bot. Inizia con lo scanner gratuito, poi scegli il bot adatto alla tua strategia.
Scanner di arbitraggio cripto gratuito Confronta i bot di arbitraggio cripto
Domande frequenti
Mi serve WebSocket per l’arbitraggio cripto?
Per l’arbitraggio di latenza, sì: l’opportunità dura meno di un secondo e il polling non riesce a vederla in tempo. Per l’hedge arbitrage (tra exchange), dove i gap persistono per secondi o minuti, REST è sufficiente, ma WebSocket riduce comunque l’utilizzo dei rate limit.
Perché il mio bot riceve errori HTTP 429 o 418 su Binance?
429 significa che hai superato un limite di richieste; 418 significa che l’IP è stato bannato perché le richieste sono continuate dopo il 429. Sposta i dati di mercato su WebSocket, rispetta l’header Retry-After e rallenta prima di raggiungere il limite.
Una chiave API per l’arbitraggio dovrebbe consentire i prelievi?
No. Trading e lettura sono sufficienti. Il ribilanciamento tra exchange può essere fatto manualmente o tramite un processo separato e rigorosamente limitato.
Qual è la migliore location del server per l’arbitraggio tra più exchange?
Quella che minimizza la gamba più lenta del tuo trade. Misura i tempi di round-trip dalle regioni candidate verso le API di ciascun exchange prima di decidere.
Con quale frequenza cambiano le API degli exchange?
Più volte all’anno per ogni exchange: nuovi endpoint, versioni deprecate e limiti modificati. Iscriviti agli annunci API di ciascun exchange e consulta il nostro tracker delle modifiche alle API.
