API JSON nascosto del sito: come trovare gli endpoint (2026)

Il parser scarica 400 KB di HTML per otto campi che il sito restituisce in un JSON di 8 KB. La differenza di cinquanta volte non riguarda il "codice bello", ma il costo per i proxy residenziali, dove si paga per ogni gigabyte. Analizziamo come trovare l'API interna del sito, cosa impedisce di replicarla nel 2026 e quando vale la pena rinunciare a questa idea.

Perché cercare un'API nascosta, se l'HTML è già parsato

Quasi tutte le interfacce moderne — React, Vue, Angular, Next.js — caricano prima la struttura della pagina e poi recuperano i dati tramite richieste separate ai propri endpoint. Questi endpoint non sono documentati, ma esistono, rispondono con JSON pulito e sono accessibili senza un browser headless.

Cosa ottieni passando a questi endpoint:

Il traffico diminuisce drasticamente. Nella scansione di una tipica pagina di prodotto, la pagina HTML pesa circa 400 KB, compresi markup, stili e tracker, mentre l'endpoint JSON corrispondente pesa circa 8 KB, e contiene più campi: ID interni, giacenze, varianti di prodotto.
Non è necessario un browser. Si elimina il rendering di JavaScript, insieme a memoria, CPU e decine di richieste aggiuntive per font e analisi.
I dati sono già strutturati. Niente selettori che si rompono a causa del cambiamento della classe CSS.
Meno richieste — meno possibilità di ban. Il rendering di una singola pagina di catalogo in un browser implica decine di richieste al sito; lo stesso volume di dati tramite API — una sola.

Per un progetto su proxy residenziali, questo rappresenta un risparmio diretto: la tariffa è calcolata per gigabyte, e passare dal rendering al JSON di solito riduce il conto più di qualsiasi stratagemma per bloccare le immagini. Un argomento correlato è come ridurre il traffico del parser di 5 volte con altri metodi.

Passo dopo passo: come trovare l'endpoint

Controlla prima se esiste un'API ufficiale. Dai un'occhiata a /developers, /api, /docs del sito target. Un'API pubblica documentata è versionata e avvisa delle deprecazioni — quella privata cambia in silenzio.
Apri DevTools (F12) e vai alla scheda Network, assicurandoti che la registrazione sia attivata.
Attiva il filtro Fetch/XHR. Questo esclude immagini, font e analisi, lasciando solo le richieste per i dati.
Pulisci l'elenco per rimuovere il rumore del caricamento iniziale.
Provoca i dati necessari: scorri i risultati, clicca su "pagina successiva", applica un filtro, apri una scheda. La richiesta che ti interessa apparirà nel momento dell'azione.
Trova la risposta con i tuoi dati. Il modo più veloce è Ctrl+F nella scheda Network: cerca un valore unico che vedi sullo schermo (articolo, prezzo esatto, parte del nome) e guarda quale richiesta lo ha generato.
Copia l'intera richiesta: clic destro sulla riga → Copia → Copia come cURL. Poi converti in codice tramite curlconverter — in questo modo non perderai nessun'intestazione.

Percorsi caratteristici da controllare in primo luogo: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

Caso speciale: siti su Next.js

Qui i dati spesso non richiedono nemmeno una richiesta separata — sono direttamente nel HTML. Nella vecchia Pages Router, questo è il blocco __NEXT_DATA__. Nella App Router (Next.js 13 e versioni successive), i dati per l'idratazione sono distribuiti attraverso chiamate self.__next_f.push() in diversi nodi script — questo è il payload serializzato dei React Server Components. Analizzarlo manualmente è scomodo: i chunk si riferiscono l'uno all'altro tramite prefissi $ e possono essere tagliati a metà della stringa. Per Python, c'è una libreria nextflight che analizza sia il Flight-payload dall'HTML che la risposta RSC grezza (richiesta con intestazione RSC: 1), e suggerisce di cercare per nomi di chiavi, non per indici di array — in questo modo il parser sopravvive al ridispiegamento del sito.

Rovesciamento dei parametri: paginazione e filtri

L'endpoint trovato è quasi sempre parametrizzato. Si incontrano tre schemi:

Per pagine: ?page=3&per_page=20
Offset e limite: ?offset=40&limit=20
Cursor: ?after=<token>&limit=20 — il token della pagina successiva arriva nel corpo della risposta precedente

Tre regole che risparmiano ore di debug:

Fermati su un pacchetto vuoto, non su un numero di pagine pre-calcolato: il contatore total nelle API private mente più spesso di quanto si desideri.
Controlla la dimensione effettiva del pacchetto. Se hai richiesto 100 e ne sono arrivati 20 — significa che l'endpoint ha un suo limite, e la tua aritmetica sulle pagine è già errata.
Non andare a pagina 500. La paginazione profonda è quasi sempre tagliata dal server; invece, taglia il campione con filtri — per categoria, per fascia di prezzo, per data.

Perché cURL dal browser funziona, mentre il tuo codice no

Questo è il punto di fallimento più comune, e la ragione è quasi sempre una: intestazione mancante. Il cURL copiato porta tutto il contesto della richiesta, mentre il client scritto a mano no.

Cosa risulta di solito obbligatorio:

Intestazioni personalizzate con prefisso X- — X-CSRF-Token, X-Requested-With: XMLHttpRequest e vari X-*-Token che il frontend inserisce da solo. Senza di esse, riceverai una risposta nell'intervallo 400–500.
Referer — un'intestazione contestuale generata dall'azione dell'utente. Molti endpoint controllano che la richiesta "provenga dalla propria pagina".
Authorization: Bearer <JWT> — un token a vita breve, di solito da 15 a 60 minuti. Hardcodarlo non ha senso: è necessario saperne ottenere uno fresco.
Cookie di sessione — conservali in un oggetto sessione, non copiarli a mano.
Corretto Content-Type per POST: application/json e application/x-www-form-urlencoded codificano il corpo in modo diverso, e la non corrispondenza con il tipo dichiarato interrompe silenziosamente la richiesta.

Dove cercare i token stessi, se non sono nei cookie: nel sorgente HTML all'interno di <script> (cerca un valore noto tramite Ctrl+F), nei bundle JavaScript, in localStorage o IndexedDB — scheda Application in DevTools.

Insidie che si scoprono tardi

L'API privata cambia senza preavviso. Non ha versionamento, promesse di compatibilità e supporto: il team frontend rinomina un campo giovedì sera, e il tuo parser raccoglie vuoto. La protezione non è un "selettore affidabile", ma il controllo della struttura: verifica che i campi obbligatori siano presenti e del tipo corretto; monitora la percentuale di valori vuoti e il numero di record nel passaggio; salta i record danneggiati, ma alza l'allerta se il difetto supera il 10%; conserva le risposte grezze, in modo da avere qualcosa con cui confrontare in seguito.

L'API a volte è protetta più rigidamente della pagina. Questo accade regolarmente: l'HTML viene restituito senza problemi, mentre su /api/ c'è un anti-bot che controlla sia il fingerprint TLS che la combinazione di intestazioni. Allora il risparmio di traffico si trasforma in un aumento della percentuale di richieste non riuscite, e il guadagno viene eroso.

Richieste firmate. Se nei parametri si vede qualcosa come sign, hash o _s, il frontend calcola la firma in JavaScript. Riprodurla è un progetto a parte, e spesso è più economico rimanere sull'HTML.

Limitazioni di frequenza. Gli endpoint privati non sono progettati per il flusso: mantieni 1–2 richieste al secondo, imposta timeout separati per connessione e lettura (ad esempio, 5 e 30 secondi), ripeti solo gli errori transitori — 429, 500, 502, 503, 504 — e non toccare 401 e 404. Un ritardo esponenziale con jitter è obbligatorio, altrimenti tutti i worker andranno in secondo giro contemporaneamente. Maggiori dettagli — nell'analisi dei timeout e della logica di retry per i proxy.

Quadro giuridico. Gli endpoint pubblici non autenticati sono una situazione, l'accesso all'account è fondamentalmente un'altra: la registrazione implica l'accettazione del contratto utente. I dati personali rientrano nel GDPR indipendentemente da quanto siano facili da ottenere. I fatti — prezzi, caratteristiche, disponibilità — non sono protetti da copyright, a differenza di testi e immagini.

Quando rimanere sull'HTML

L'API nascosta non è sempre vantaggiosa. Rimani sull'analisi delle pagine se:

il sito è server-side e non esiste alcuna API interna;
l'endpoint richiede una firma o rotazione dei token — mantenerlo costa più della pagina;
l'API ha una protezione più severa rispetto alle pagine pubbliche;
hai bisogno del risultato finale, che il frontend raccoglie da diverse fonti;
gestisci decine di siti: un unico pipeline HTML si scala meglio di uno zoo di API private con stranezze individuali.

Quale tipo di proxy scegliere per il parsing API

Passare a JSON cambia il calcolo, perché si sposta il collo di bottiglia: il traffico diventa scarso, mentre le richieste di qualità IP e stabilità della sessione aumentano.

Endpoint aperto senza autorizzazione e senza anti-bot. Qui bastano proxy di data center: il volume di dati è piccolo, non c'è bisogno di pagare per quelli residenziali.
Endpoint dietro un anti-bot o legato a una sessione. Servono proxy residenziali con sessione persistente: token, cookie e IP devono corrispondere per tutta la durata della catena, altrimenti il server resetterà la sessione alla seconda richiesta. In questo caso, il conto rimarrà modesto — i gigabyte in modalità JSON si consumano lentamente.
Dati da un'app mobile. Se la versione web è chiusa e l'app restituisce le stesse informazioni in modo più semplice, gli endpoint si cercano tramite intercettazione del traffico — questa è una procedura separata, analizzata nell'articolo su come trovare l'API nascosta di un'app mobile tramite mitmproxy.

In breve

Venti minuti in DevTools spesso sostituiscono giorni di lotta con un browser headless: filtro Fetch/XHR, ricerca per valore visibile, Copia come cURL — e hai una richiesta funzionante. Poi si risolvono i dettagli: trasferire tutte le intestazioni, analizzare lo schema di paginazione, impostare la validazione della risposta e valutare con lucidità se l'endpoint è più protetto della stessa pagina. Dove l'API privata funziona, riduce sia il volume di traffico che il numero di richieste — cioè immediatamente sia il costo dei proxy che la probabilità di ban.