L'API pumpfun, spiegata senza il marketing

Cosa vogliono davvero gli sviluppatori da una “API pump.fun”

Quando si digita API pumpfun in una barra di ricerca, quasi sempre si cerca una di tre cose. Vale la pena nominarle con precisione, perché hanno profili di difficoltà e rischio molto diversi.

I primi due sono problemi di lettura. Il terzo è un problema di scrittura, ed è lì che il denaro sparisce più velocemente — sia a causa di bug sia per mano di attaccanti. Tieni a mente questa distinzione per il resto della pagina, perché i consigli sulla sicurezza scalano di conseguenza.

Esiste un'API ufficiale di pump.fun?

In breve: non nel senso che la maggior parte degli sviluppatori si aspetta. Un exchange centralizzato come CEX.IO o Coinbase pubblica un'API REST versionata, un changelog, una documentazione sui rate limit e un canale di supporto. pump.fun è un insieme di programmi on-chain su Solana con un frontend web. La fonte di verità canonica non è un endpoint REST — è la blockchain stessa.

Questo ha due conseguenze. Primo, chiunque può leggere i dati, perché sono pubblici on-chain; non serve il permesso di pump.fun. Secondo, non c'è alcun SLA, nessun servizio di supporto e nessuna garanzia che un endpoint non documentato che il frontend per caso chiama oggi esisterà domani. C'è chi fa reverse engineering delle chiamate interne del sito, e c'è chi ci rimette quando quelle chiamate cambiano o iniziano a restituire errori.

RPC on-chain vs indexer di terze parti

Ci sono due modi onesti per ottenere i dati di pump.fun, e la maggior parte dei progetti reali li usa entrambi.

1. RPC Solana (parla direttamente con la chain). Un nodo RPC Solana risponde a domande di basso livello: lo stato di un account, il contenuto di una transazione, i log emessi da un programma e — tramite websocket — uno stream in tempo reale di quegli eventi. Per trasformare tutto ciò ne “il prezzo del token X”, sei tu a decodificare gli account del programma rilevante. È flessibile, economico e minimizza la fiducia, ma fai vero lavoro di ingegneria, e gli endpoint RPC pubblici hanno rate limit pesanti e sono spesso sovraccarichi.

2. Indexer e API di dati di terze parti. Un indexer è un servizio che ha già assorbito la chain, decodificato i programmi pump.fun e DEX, ed espone query amichevoli: “nuovi token nell'ultima ora”, “operazioni per questo mint”, “top holder”. Paghi la comodità con denaro e con una dipendenza di fiducia — stai credendo che l'indexer abbia decodificato tutto correttamente e non sia silenziosamente in ritardo. Per i feed dei nuovi lanci e l'analitica, un indexer è di solito la scelta pragmatica.

La regola empirica: usa l'RPC quando contano correttezza e indipendenza (esecuzione, verifiche di settlement), e un indexer quando contano la velocità di sviluppo e query ricche (dashboard, screener). Vedi il nostro manuale introduttivo a Solana per capire come i blocchi da 400ms della chain e il modello di commissioni plasmano tutto questo, e la guida allo swap DEX per capire come si comportano le pool una volta che un token si è diplomato dalla bonding curve.

Funzionalità e limiti tipici

Tra RPC e i comuni indexer, ecco grosso modo cosa puoi e non puoi aspettarti.

Fonti di dati a confronto

Un confronto approssimativo e schietto di come gli sviluppatori ottengono i dati di pump.fun. Limiti e funzionalità specifici dipendono interamente dal provider e dal piano — controlla sempre la sua documentazione attuale.

Le valutazioni qualitative riflettono la nostra lettura editoriale a 2026, non benchmark dei vendor. Verifica funzionalità e prezzi nella documentazione di ciascun provider.

Rate limit e affidabilità

Questa è la parte che uccide silenziosamente i progetti. Gli endpoint RPC pubblici sono condivisi e aggressivamente limitati; nel momento in cui il tuo loop di polling diventa popolare, vedrai 429 Too Many Requests e connessioni websocket interrotte. Gli indexer hanno i propri limiti a fasce, spesso espressi come richieste al secondo più un tetto mensile.

Progetta in modo difensivo fin dal primo giorno:

• Preferisci le sottoscrizioni al polling. Uno stream websocket di nuovi eventi è più economico e veloce che martellare un endpoint REST ogni secondo.
• Applica un backoff sugli errori. Backoff esponenziale con jitter su 429 e 5xx, non un loop di retry serrato che peggiora il throttling.
• Fai cache in modo aggressivo. I metadati dei token e le operazioni storiche non cambiano; non recuperarli di nuovo.
• Abbi un fallback. Un secondo RPC/indexer su cui passare quando il principale degrada. La dipendenza da un solo provider è un singolo punto di guasto.
• Aspettati interruzioni. Solana ha avuto rallentamenti di rete e blocchi. Il tuo bot dovrebbe fallire in sicurezza — non fare nulla — invece di lanciare ordini alla cieca nel caos.

La fascia API più economica e la strategia di trading ad altissima frequenza si escludono a vicenda. Se il tuo vantaggio dipende dall'essere più veloce di tutti gli altri, sei in una corsa agli armamenti infrastrutturale che probabilmente non puoi vincere contro bot finanziati.

Autenticazione e sicurezza delle chiavi API

Le chiamate RPC di sola lettura a un nodo pubblico spesso non richiedono alcuna chiave. Tutto ciò che è serio sì: i provider RPC e gli indexer a pagamento rilasciano chiavi API, e qualsiasi endpoint che può fare trading per tuo conto (su un exchange centralizzato) rilascia chiavi che possono movimentare denaro. Il modello di minaccia è completamente diverso per i due, e dovresti trattare le chiavi di trading come munizioni vere.

1. Non committare mai le chiavi. Nessuna chiave nel codice sorgente, nei file di configurazione del repo, negli screenshot o nel JavaScript lato client. Usa variabili d'ambiente o un secrets manager. Aggiungi .env al .gitignore fin dal primo giorno, e scansiona la tua history — le chiavi pushate una volta vengono raccolte nel giro di minuti.
2. Minimo privilegio. Crea una chiave separata per ogni app, con solo i permessi di cui ha bisogno. Una dashboard riceve una chiave di sola lettura. Un logger di prezzi non ha mai bisogno dello scope di trading.
3. Disabilita i prelievi. Su qualsiasi chiave di trading, disattiva il permesso di prelievo/trasferimento. Un bot che compra e vende non ha bisogno della capacità di inviare fondi fuori dalla piattaforma.
4. Allowlist di IP. Vincola la chiave all'IP (o agli IP) fisso del tuo server. Una chiave rubata è molto meno utile se funziona solo dalla tua macchina.
5. Ruota e monitora. Ruota le chiavi a cadenza regolare e immediatamente se qualcosa non torna. Imposta alert su utilizzi inattesi. Tieni chiavi separate per dev e produzione, così che una chiave di test esposta non possa toccare denaro reale.

Per l'esecuzione non in custodia direttamente su pump.fun, c'è una versione ancora più affilata di tutto ciò: stai firmando transazioni Solana con la chiave privata di un wallet. Quella chiave è i fondi. Esegui l'automazione contro un hot wallet dedicato che contiene solo ciò che puoi perdere, mai il tuo wallet principale — la nostra guida al wallet e alla self-custody copre le regole sulla seed phrase che contano qui.

Una richiesta segnaposto, fatta in sicurezza

Qui sotto c'è un esempio minimale e illustrativo di lettura dei dati da un provider, con la chiave presa dall'ambiente — mai hard-coded. L'URL, il nome dell'header e la forma della risposta sono segnaposto; usa il formato documentato del tuo provider reale.

# 1) Metti la chiave nel tuo ambiente, NON nel codice o nel repo:
#    export DATA_API_KEY="your-read-only-key"

curl -s "https://api.example-indexer.com/v1/token/<MINT_ADDRESS>" \
  -H "Authorization: Bearer ${DATA_API_KEY}" \
  -H "Accept: application/json"

# Esempio Node — chiave letta a runtime, scope di sola lettura:
#   const key = process.env.DATA_API_KEY;
#   const res = await fetch(`${BASE}/v1/token/${mint}`, {
#     headers: { Authorization: `Bearer ${key}` }
#   });
#   if (!res.ok) { /* backoff su 429 / 5xx, NON fare tight-loop */ }

La stessa disciplina vale per un'API di exchange documentata: chiavi in variabili d'ambiente, prelievi disattivati, ristrette per IP. I meccanismi sono gli stessi sia che tu stia leggendo prezzi di memecoin sia che tu stia piazzando ordini spot.

Casi d'uso — e i rischi onesti

Ecco dove il discorso diventa un bagno di realtà. Queste sono le tre cose che la gente costruisce, ordinate grosso modo da “per lo più sicuro” a “molto probabilmente fa perdere denaro”.

Analitica e dashboard (rischio più basso)

Screener di sola lettura, grafici di distribuzione degli holder, tracker di volume, alert sui nuovi lanci. Questa è la categoria più sicura perché nulla viene eseguito — il caso peggiore sono dati errati o una quota esaurita. È anche genuinamente utile: una buona dashboard ti aiuta a evitare i token cattivi, il che vale più che inseguire quelli buoni. Costruisci con una chiave di sola lettura, fai cache in modo deciso, e sei su un terreno solido.

Bot di alert e sniper (rischio alto)

Bot che osservano il feed dei nuovi lanci e reagiscono — avvisandoti, o comprando in automatico. La fantasia è essere il primo; la realtà è che stai gareggiando con operatori dotati di infrastruttura più veloce, accesso a pagamento alla mempool e co-location. Quando il tuo websocket su RPC pubblico consegna un evento, il prezzo che otterresti è spesso già peggiorato. E il feed è pieno di esche: token-truffa progettati appositamente per attirare gli sniper bot.

Trading bot automatizzati (rischio più alto)

Codice non sorvegliato che compra e vende con fondi reali. Sii schietto con te stesso: la maggior parte dei trading bot retail perde denaro, e i bot sulle memecoin lo perdono più velocemente. Le ragioni si sommano:

Aggiungi i rischi operativi — un bug nella logica, un caso limite non gestito, un feed di prezzi obsoleto, un blocco di rete a metà operazione — e un bot non sorvegliato può bruciare un wallet mentre dormi. Se comunque ne costruisci uno, fallo su un hot wallet usa e getta con un tetto di spesa rigido, dei kill switch e l'assunzione che l'intero saldo possa svanire. Trattalo come un modo costoso per imparare, non come una fonte di reddito.

Se ciò che ti serve davvero è un'interfaccia stabile e documentata per prezzi ed esecuzione — con un changelog, supporto e rate limit prevedibili — un'API di exchange regolamentato è una base più sensata di un endpoint non ufficiale da scraping. Rinunci alla self-custody, ma guadagni responsabilità e trasparenza.

Esplora un'API di trading documentata→

Una checklist pre-volo prima di andare in produzione

1. Scegli la fonte giusta. RPC per correttezza ed esecuzione, indexer per query ricche, un'API di exchange documentata quando vuoi supporto. Non fare scraping di endpoint interni per nulla a cui tieni.
2. Metti in sicurezza ogni chiave. Variabili d'ambiente o secrets manager, minimo privilegio, prelievi disattivati, IP in allowlist, rotazione a cadenza regolare. .env nel .gitignore.
3. Gestisci i limiti con grazia. Sottoscrizioni invece del polling, backoff esponenziale, caching e un provider di fallback.
4. Fallisci in sicurezza. Di fronte a dati errati, errori o problemi di rete, il tuo codice dovrebbe non fare nulla invece di tirare a indovinare.
5. Limita il raggio dell'esplosione. Hot wallet dedicato, limite di spesa rigido, kill switch. Non automatizzare mai fondi che non puoi perdere.
6. Verifica contro la fonte. Riscontra i numeri critici (saldi, fill) con la chain tramite RPC, non solo con un indexer.

Vuoi vedere dove finiscono questi dati nell'interfaccia reale? Il nostro tour dell'app e la guida passo-passo allo swap mostrano il lato frontend della stessa idraulica on-chain che andresti a interrogare.

FAQ