API blockchain a confronto: di quale tipo avete davvero bisogno?

Cercate «API blockchain» e trovate listicle che mettono un provider RPC accanto a un processore di pagamenti accanto a un servizio di analytics, come se fossero intercambiabili. Non lo sono. Alcuni degli articoli comparativi più linkati risalgono al 2023 e raccomandano ancora provider che nel frattempo hanno chiuso o cambiato modello. Scegliere da una lista così costa settimane, perché i prodotti risolvono problemi diversi e lo si scopre solo dopo aver iniziato l’integrazione.

Questo confronto ordina il mercato del 2026 in sei categorie invece di classificare venti loghi. Per ogni categoria: cosa fa, chi la fa bene, e quando è lo strumento sbagliato. Chaingateway compare in esattamente una delle sei, e saremo chiari su dove le altre sono la scelta migliore.

Cosa conta come API blockchain?

Qualsiasi interfaccia HTTP che permetta alla vostra applicazione di interagire con una blockchain senza parlare essa stessa il protocollo peer-to-peer. Questo copre almeno quattro compiti diversi: leggere lo stato della chain, inviare transazioni, ricevere notifiche di eventi, e gestire chiavi o wallet. Nessun singolo provider fa tutti e quattro al meglio, ed è proprio per questo che le categorie contano.

1. Infrastruttura RPC: QuickNode, Alchemy, Chainstack

Questi provider fanno girare node blockchain per voi ed espongono le interfacce JSON-RPC native delle chain tramite endpoint gestiti. Ottenete quello che darebbe un node self-hosted, meno il lavoro operativo: eth_call, eth_getBalance, broadcast grezzo di transazioni, sottoscrizioni WebSocket.

Questa è la categoria giusta quando costruite una dApp, interagite direttamente con smart contract, o vi serve accesso grezzo alla chain a bassa latenza. QuickNode e Alchemy in particolare hanno investito anni in tooling per sviluppatori, SDK ed endpoint di comodità sopra l’RPC standard; Chainstack compete per gli stessi carichi di lavoro. Per i backend di dApp, tutte e tre sono una scelta migliore di una API di pagamento, Chaingateway inclusa. Una API di pagamento astrae la chain, e una dApp ha bisogno della chain, non di un’astrazione.

Il compromesso: l’RPC è di basso livello. «Avvisami quando l’indirizzo X riceve USDT» non è una chiamata RPC; la costruite voi stessi a partire da log e sottoscrizioni, o la comprate come prodotto aggiuntivo. Anche la gestione delle chiavi è interamente un problema vostro.

Una giornata tipica su questo stack, per un team di dashboard DeFi: la mattina inizia con un backfill di eth_getLogs per un token appena quotato, poi qualcuno nota che la sottoscrizione WebSocket è caduta silenziosamente durante la notte e la logica di riconnessione ha perso venti blocchi, poi i budget di rate-limit vengono ridistribuiti perché una funzionalità del prodotto martella eth_call. Lavoro nativo della chain, tutto quanto. Se il vostro team dovrebbe pensare a fatture invece che a nonce, state leggendo la categoria sbagliata.

2. API di dati e analytics: CoinStats API, Bitquery e simili

Le API di dati indicizzano le blockchain in forma interrogabile. Bitquery espone dati cross-chain tramite GraphQL; The Graph e Dune occupano lo stesso spazio con modelli di query diversi. Invece di scorrere i blocchi da soli, chiedete «tutti i trade DEX del token X questa settimana» e ottenete risultati strutturati.

All’interno di quella categoria i fornitori rispondono a due forme di domanda diverse. Bitquery, The Graph e Dune indicizzano l’attività grezza della chain e vi consegnano un linguaggio di query; CoinStats Crypto API aggrega, così un solo indirizzo restituisce saldi già valorizzati, storico delle transazioni e posizioni DeFi su oltre 10.000 protocolli e oltre 120 chain. «Tutti gli scambi DEX del token X» è una domanda da indexer; «che cosa detiene questo indirizzo e quanto vale» è una domanda di aggregazione, ed è quella che pongono davvero i portfolio tracker, gli strumenti fiscali e i dashboard dei wallet. Resta in sola lettura come il resto della categoria, analizza i contratti dei token alla ricerca di honeypot e fornisce un server MCP, così un agente IA interroga ciò che interroga il vostro backend. Livello gratuito per iniziare, poi prezzi a crediti.

Usate questa categoria per dashboard, strumenti fiscali e contabili, ricerche di mercato, o qualsiasi carico di lavoro orientato alla lettura su dati storici. È la categoria sbagliata per spostare fondi: le API di dati sono di sola lettura per design. I team a volte lo scoprono alla fine di una valutazione, una settimana che nessuno recupera. Se il vostro requisito contiene la parola «payout», continuate a leggere.

Il lavoro quotidiano qui somiglia al data engineering, perché lo è. Un prodotto fiscale crypto esegue job notturni che estraggono ogni trasferimento per decine di migliaia di wallet utente su cinque chain, un backfill per una chain appena supportata si trascina per giorni, e l’allerta di reperibilità che scatta davvero riguarda i limiti di costo delle query, non il denaro. Nulla viene firmato, nessuna chiave viene mai detenuta. Quando qualcosa si rompe, il caso peggiore è una dashboard non aggiornata, esattamente il profilo di rischio che un’integrazione di sola lettura dovrebbe avere.

3. Piattaforme di custody enterprise: Fireblocks, BitGo

Le piattaforme di custody detengono o co-gestiscono chiavi per le istituzioni, con chiavi divise tra più parti (MPC o multi-signature), motori di policy transazionale e audit trail. Fireblocks e BitGo sono i nomi affermati, e per un fondo, una banca o un exchange che gestisce saldi a nove cifre, questa categoria è la risposta giusta, senza dubbi. La macchina di governance è il prodotto: flussi di approvazione multi-utente, limiti di velocity, hook di screening di conformità.

Il disallineamento per i team più piccoli sta nell’onboarding e nella struttura dei costi. Sono contratti guidati dalle vendite con controlli KYB, non iscrizioni self-service, e la macchina di policy che pagate è sovradimensionata per un negozio che vuole solo accettare USDT. Se la vostra tesoreria ha bisogno di controlli a livello di board, andate qui. Se volete depositi funzionanti questa settimana, è la strada più lenta possibile.

Ecco com’è una giornata di lavoro in questa categoria: un trader richiede un trasferimento in uscita prima di pranzo, il motore di policy richiede due approvazioni da reparti diversi più un controllo di velocity rispetto al limite giornaliero, la compliance esamina l’indirizzo di destinazione, e il quorum di firma MPC si completa nel primo pomeriggio. Quattro ore dalla richiesta al broadcast, ed è il sistema che funziona come progettato. La lentezza è il prodotto; esiste perché nessun singolo dipendente, laptop compromesso o credenziale phishata possa spostare da solo nove cifre.

4. API di exchange: Binance, Coinbase

Gli exchange espongono API per trading, dati di mercato e spostamento di fondi dentro e fuori dai conti dell’exchange. Se i vostri fondi sono già su un exchange, o il vostro prodotto riguarda il trading, queste API sono mature e ben documentate.

Due limiti strutturali le rendono una cattiva API blockchain generica. Primo, tutto avviene dentro un conto dell’exchange verificato KYC; i depositi dei vostri utenti diventano voci nel vostro conto presso l’exchange, con l’exchange come custode. Secondo, raggiungete solo le chain e gli asset che l’exchange lista, secondo le sue regole e i suoi limiti di prelievo. Costruire un flusso di pagamento per il vostro prodotto sopra un conto exchange funziona finché il conto non viene segnalato, e poi non funziona più. Le API di exchange servono a interagire con l’exchange, non con la blockchain.

L’abitante naturale di questa categoria è un sistema di trading. La sua giornata: osservare stream dell’order-book via WebSocket, piazzare e cancellare ordini a migliaia, ribilanciare l’inventario tra due venue con chiamate di prelievo, e avvisare un umano quando un venue stringe i limiti di prelievo senza preavviso. Notate cosa manca in quella giornata: la blockchain. Compare solo per i minuti in cui un trasferimento di ribilanciamento è in corso, e se ne occupa persino l’exchange. Se la vostra giornata somiglia a questa, le API di exchange non sono un compromesso, sono lo strumento giusto.

5. API di pagamento e wallet: Chaingateway, BitPay, CoinStats, CryptoAPIs

Questa categoria esiste per un solo compito: accettare e inviare crypto dentro il vostro prodotto. Indirizzi di deposito per cliente, notifiche webhook sui trasferimenti in entrata, payout via chiamata REST, senza far girare node né costruire indicizzazione.

I provider differiscono più di quanto suggerisca l’etichetta condivisa. BitPay è un processore di pagamenti completo: checkout ospitato, fatturazione e settlement in fiat — e il settlement in fiat implica la verifica del merchant prima di andare live; se volete «pagare in crypto, ricevere euro», questo modello si adatta. CryptoAPIs vende un’ampia copertura REST multi-chain con webhook, pensata per team che vogliono un solo fornitore per molte chain. Chaingateway copre Bitcoin, Ethereum, TRON, Solana, BSC, Polygon e Arbitrum con una API REST per wallet e trasferimenti; i webhook di deposito firmati HMAC sono disponibili su tutte tranne Solana, e potete iniziare senza onboarding KYC con una prova di 7 giorni. Le specificità di TRON come lo staking di energy e la delega di risorse sono endpoint a sé stanti, il che conta perché l’USDT su TRON è il cavallo di battaglia dei pagamenti crypto.

Il quarto nome del titolo appartiene alla seconda metà dell’etichetta. La CoinStats Crypto Wallet API legge i wallet senza muovere fondi: passate un indirizzo qualsiasi e ottenete saldi, cronologia delle transazioni e posizioni DeFi su oltre 120 chain, dallo xpub di Bitcoin a Solana e all’EVM. Non emette indirizzi di deposito e non invia pagamenti, quindi affianca una API di pagamento invece di sostituirla, ed è la strada più breve per una vista di portafoglio ai clienti di cui già gestite i depositi.

Per essere altrettanto chiari sui limiti: questa categoria non è per le dApp (usate l’infrastruttura RPC), non per l’analytics (usate una API di dati), e non per la policy di custody istituzionale (usate Fireblocks o BitGo). Le API di pagamento vincono quando il requisito è «la mia piattaforma accredita i depositi dei clienti e invia payout, e preferisco non diventare un team di infrastruttura blockchain».

Una giornata nella vita di questa integrazione è piacevolmente noiosa. All’iscrizione, il backend crea un indirizzo di deposito per ogni nuovo cliente con una singola chiamata REST. Durante il giorno, i webhook arrivano a goccia e accreditano i conti; nessuno fa polling di nulla. Alle sei di sera, un batch di payout paga i fornitori, e l’unico pensiero a livello di chain rimasto in azienda è la pianificazione delle fee su TRON, di cui si occupa un calcolatore. Il vocabolario del team sono clienti, fatture e saldi. Questo è tutto il senso della categoria: la chain è diventata un dettaglio implementativo.

6. Far girare il proprio node

L’opzione a zero fornitori: far girare geth, bitcoind o java-tron da soli e chiamare il proprio RPC. Nessuno vi limita la rate, nessuna terza parte vede le vostre query, e nessun down di provider vi blocca.

I costi sono operativi. I tempi di sync vanno da ore a giorni a seconda della chain e dell’hardware, lo storage arriva a centinaia di gigabyte e continua a crescere, e gli aggiornamenti arrivano secondo il calendario della chain, non il vostro. Dovete anche costruire da soli tutto ciò che sta sopra l’RPC: monitoraggio degli indirizzi, consegna dei webhook, gestione delle chiavi. Un node ha senso quando la sovranità dei dati è un requisito rigido, quando il volume di query rende irrazionali i prezzi dei provider, o quando siete un team di infrastruttura di mestiere. Per una chain è un progetto collaterale gestibile; per cinque chain è un ruolo a tempo pieno.

La giornata dell’ingegnere responsabile vi dice a cosa state andando incontro. Inizia con un alert di utilizzo disco all’80%, prosegue con una nota di rilascio del client che annuncia un hard fork con una finestra di aggiornamento obbligatoria tra due settimane, e può finire con una resync da uno snapshot perché la macchina si è spenta in modo non pulito. Nel mezzo ci sono i pannelli Grafana per il numero di peer e il ritardo dei blocchi, che qualcuno ha dovuto costruire. Niente di tutto questo consegna funzionalità di prodotto; mantiene solo stabile il terreno sotto di esse. Alcuni team trovano questo trade-off davvero conveniente. La maggior parte scopre cosa costa solo dopo la seconda resync non pianificata.

Il confronto in sintesi

Quanto costa, verificato il 17 agosto 2026

Ogni confronto di questo tipo riporta prezzi, e quasi nessuno dice quando quei prezzi sono stati letti. Una cifra senza data è un’affermazione su oggi che era vera in un giorno imprecisato del passato. Perciò: il 17 agosto 2026 abbiamo aperto la pagina prezzi di ogni fornitore e annotato quello che diceva. Dove un fornitore non pubblica alcuna cifra, la tabella lo dichiara invece di tirare a indovinare.

† Letto dalla documentazione o dal blog del fornitore stesso, perché la sua pagina prezzi si renderizza solo nel browser e non è stato possibile acquisirla direttamente. Tutto il resto proviene dalla pagina prezzi stessa.

Due cose meritano attenzione in quella colonna di numeri. La prima è quanto il mercato sia converso sullo stesso prezzo di ingresso: QuickNode, Chainstack, CoinStats e CryptoAPIs partono con il primo piano a pagamento a 49 $ al mese, e il nostro parte da 49 €. Non è una coincidenza pianificata da qualcuno; è il punto in cui si è assestata l’infrastruttura self-service. La seconda è che la riga custody non appartiene affatto alla stessa colonna. 999 $ al mese, o 36.000 $ all’anno, comprano un prodotto di tipo diverso, e confrontarlo con 49 $ non vi dice nulla se non che state guardando due categorie invece di una.

Questi numeri cambieranno. Quando accadrà, la data qui sopra vi dirà quanto diffidarne, il che è più di quanto offra la maggior parte dei confronti.

Un esempio di API blockchain: creare un indirizzo di deposito

Il flusso di deposito ha due metà, e la prima è una singola chiamata. Il vostro backend genera una coppia di chiavi nel vostro ambiente e la registra per la chain, dove viene salvata cifrata sotto una password che solo voi possedete:

curl -X POST https://app.chaingateway.io/api/v2/tron/addresses/import \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "TYourGeneratedTronAddress",
    "privatekey": "<generated secp256k1 private key, hex>",
    "password": "<encryption password for this key>"
  }'

La stessa forma di chiamata funziona per ogni chain: /api/v2/bsc/addresses/import per BSC, e le route corrispondenti per Ethereum, Polygon e Arbitrum. Aggiungete l’header X-Network: testnet e la richiesta gira sulla testnet della chain invece che sulla mainnet, il che permette di provare l’intero flusso con coin di test senza valore prima che sia coinvolta una chiave o un cliente reali. Salvate l’indirizzo restituito nel record del cliente nel vostro database; è proprio questa corrispondenza che trasforma un trasferimento on-chain anonimo in «la fattura 4127 è pagata».

Vale la pena soffermarsi su cosa sostituisce questa chiamata. Nella categoria RPC, gli indirizzi di deposito per cliente significano costruire il proprio storage delle chiavi, la rotazione degli indirizzi e il monitoraggio della chain. Nella categoria exchange, significano sub-account dentro la custody di qualcun altro. Qui è una singola richiesta, e le chiavi restano vostre.

Un esempio di API blockchain: ricevere un webhook di deposito

La seconda metà è scoprire che il denaro è arrivato. Quando un trasferimento raggiunge uno dei vostri indirizzi registrati, un webhook chiama il vostro endpoint. Il lato ricevente, in Node.js:

import express from "express";
import { createHmac, timingSafeEqual } from "node:crypto";

const app = express();
app.use(express.raw({ type: "application/json" }));

app.post("/webhooks/deposits", (req, res) => {
  const tx = JSON.parse(req.body);

  // X-Signature carries base64(HMAC-SHA256(txid, personal_secret))
  const signature = req.get("X-Signature") ?? "";
  const expected = createHmac("sha256", process.env.PERSONAL_SECRET)
    .update(tx.txid)
    .digest("base64");

  if (
    signature.length !== expected.length ||
    !timingSafeEqual(Buffer.from(signature), Buffer.from(expected))
  ) {
    return res.status(401).end();
  }

  // Payload fields: txid, from, to, amount, contractaddress, type, blocknumber
  creditCustomerByAddress(tx.to, tx.amount, tx.txid);
  res.status(200).end();
});

Il controllo di firma respinge le chiamate falsificate — l’header X-Signature porta un HMAC-SHA256 codificato in base64 sull’id della transazione, firmato con il vostro personal_secret. Le consegne fallite si accumulano sotto GET /api/v2/tron/webhooks/notifications/failed e possono essere reinviate con POST /api/v2/tron/webhooks/notifications/{id}/retry, e le notifiche passate possono essere recuperate dopo un downtime tramite GET /api/v2/tron/webhooks/notifications. Nomi degli header e schema del payload sono nella guida ai webhook. Confrontatelo con la via RPC, dove la stessa funzionalità significa sottoscrivere i log, decodificare eventi di trasferimento TRC20 o ERC-20, tracciare le conferme, e costruire la propria coda di retry. È un buon progetto di ingegneria, e inutile se i depositi sono tutto ciò che vi serve.

Come scegliere: sei domande

1. Leggete dati della chain o spostate fondi? Leggere punta a RPC o API di dati; spostare fondi punta a API di pagamento o custody.
2. Chi detiene le chiavi? I vostri utenti (dApp, RPC), voi (API di pagamento o node proprio), o un custode sotto policy (Fireblocks, BitGo)?
3. Vi servono notifiche push per i depositi? Se i webhook sono nella lista dei requisiti, verificate se sono una funzionalità centrale o un’aggiunta.
4. Quanto in fretta dovete andare live? L’iscrizione self-service è oggi; i contratti KYB sono settimane. Chaingateway e i provider RPC partono senza KYC; le piattaforme di custody e i processori che liquidano in fiat, no.
5. Quali chain, davvero? Scartate prima i provider a cui manca una delle vostre chain indispensabili. Se TRON conta, controllate le specificità TRON come la gestione delle fee; vedete cos’è un indirizzo TRC20 per capire perché quella chain si comporta diversamente.
6. Qual è la vostra via d’uscita? Il JSON-RPC standard è portabile tra provider con un cambio di URL. Le API REST proprietarie, la nostra inclusa, comportano lavoro al cambio — soppesate quanto vi fa risparmiare l’astrazione contro questo lock-in.

Tre di queste domande meritano più di una riga.

Latenza per prima, perché i team comprano regolarmente velocità nel posto sbagliato. Un sistema di trading si preoccupa di ogni millisecondo tra un evento e un ordine. Un flusso di pagamento è scandito dalla chain, non dall’API: un deposito TRC20 è finale dopo circa 57 secondi e uno Ethereum dopo diversi minuti, quindi una risposta REST di 50 millisecondi lì non vi fa risparmiare nulla di rilevante. Pagare un premio RPC per bassa latenza in un flusso di deposito significa comprare velocità dove la chain ha già fissato il tempo. Esiste anche l’errore opposto: far girare logica di trading sensibile alla latenza su un livello API i cui rate-limit sono stati calibrati per volumi di pagamento.

La compliance taglia in entrambe le direzioni. I provider vi impongono un onboarding, da un’iscrizione via email a una revisione KYB completa, e il vostro regolatore a sua volta impone requisiti al provider: hook di screening transazionale, residenza dei dati, export di audit. Scrivete entrambe le liste prima di valutare chiunque. Un provider che fallisce un requisito di compliance è fuori a qualsiasi prezzo — questo filtro va applicato all’inizio della valutazione, non alla fine.

La logica di budget differisce per categoria, il che rende i prezzi grezzi incomparabili. I provider RPC fatturano per request, quindi i costi scalano con il traffico, letture incluse, e un frontend chiacchierone può dominare la fattura. Le API di pagamento hanno prezzi per piano, indirizzi o volume di webhook, quindi i costi seguono gli eventi di business, più vicino a come arriva il ricavo. Un node sembra gratuito per request e costa hardware più ore di ingegneria che nessuno scorpora. Modellate un mese del vostro uso reale in ogni forma di prezzo prima di confrontare i numeri; le forme distorcono più degli importi.

La stessa scelta come albero decisionale

Iniziate con la domanda: spostate fondi o leggete dati? Tutto il resto dipende da questa risposta.

Se leggete soltanto, il bivio successivo è freschezza contro storico. Stato attuale grezzo a bassa latenza, chiamate a contratto, transazioni pending: infrastruttura RPC. Domande aggregate su attività passata, portfolio, statistiche: una API di dati, un indexer come Bitquery per l’attività grezza della chain, CoinStats API per dati di wallet, DeFi e portfolio già uniti. Nel dubbio, guardate le query che intendete scrivere. «Allowance attuale del contratto X» è RPC; «tutti i trasferimenti del token X da gennaio» è una query di API di dati.

Se spostate fondi, il bivio è la custody delle chiavi. Un’istituzione che ha bisogno di controlli di policy e approvazione multi-parte va verso una piattaforma di custody e accetta l’onboarding. Fondi che vivono già su un exchange, e lì restano, puntano all’API di quell’exchange. Chiavi che detenete voi stessi, in un vostro prodotto che accredita depositi e invia payout: una API di pagamento, il ramo su cui si trova Chaingateway.

Due considerazioni attraversano tutti i rami. La sovranità dei dati o un volume di query estremo possono giustificare un node self-hosted in qualsiasi scenario, accanto a un provider o al suo posto, al prezzo operativo descritto sopra. E se i webhook portano il vostro prodotto, testateli durante la prova gratuita qualunque ramo abbiate scelto: latenza, comportamento di retry e verifica della firma, contro il vostro endpoint reale.

Percorsi di migrazione: entrare è più facile che uscire

Le categorie non sono prigioni, e i sistemi reali si muovono tra loro. I due percorsi comuni:

Da node self-hosted a API. Il trigger è di solito la seconda chain, o il primo aggiornamento client obbligatorio che cade in periodo di ferie. Fatto per gradi, il trasloco è poco drammatico: mettere l’endpoint del provider dietro la stessa interfaccia interna in cui già si trova il vostro node, far girare entrambi in parallelo e confrontare i percorsi di lettura per una settimana, poi passare le letture, poi le scritture. Le chiavi non devono mai spostarsi. Con una API di pagamento, le chiavi esistenti si registrano tramite la stessa chiamata di import mostrata sopra, così gli indirizzi di deposito che i vostri clienti già conoscono continuano a funzionare. Dismettete il node dopo un mese pulito di parità, e conservate i runbook; documentano assunzioni che il vostro codice fa ancora.

Dall’API tornando a un node, o tra provider. La portabilità dipende dall’interfaccia integrata. Il JSON-RPC standard si sposta con un cambio di URL, l’argomento più forte della categoria RPC. Le API REST proprietarie, la nostra inclusa, richiedono uno strato di adattamento, e le API di dati sono ancora più vischiose, perché i linguaggi di query vengono riscritti anziché ricollegati. La difesa è architetturale ed economica se fatta presto: incapsulare ogni chiamata al provider in un modulo proprio fin dal primo giorno. Questo wrapper costa mezza giornata all’inizio di un progetto e risparmia una riscrittura tre anni dopo, qualunque sia la direzione in cui infine migrate.

Segnali d’allarme: riconoscere un provider abbandonato

L’infrastruttura crypto ha un alto tasso di mortalità tra i provider, e i sintomi si vedono molto prima dell’avviso di chiusura.

Il controllo più veloce è la traccia documentale. Aprite la documentazione e cercate le date di ultimo aggiornamento e il changelog. Le chain si muovono di continuo — solo BSC ha cambiato il proprio block time due volte tra metà 2025 e inizio 2026 — quindi un provider il cui changelog tace da diciotto mesi non tiene il passo delle reti a cui vende accesso. Confrontate la pagina delle chain supportate del provider con le release note delle chain stesse; le lacune lì predicono lacune in produzione.

I ranking di ricerca non sono un controllo di salute. Articoli comparativi del 2023 si posizionano ancora bene per «API blockchain» e raccomandano ancora provider che nel frattempo hanno chiuso o abbandonato il prodotto elogiato. Prima di confrontare le funzionalità, verificate che il provider esista nel senso che conta: iscrizioni aperte, pagina prezzi recente, una pagina di stato con uno storico incidenti reale. Una pagina di stato che non ha mai registrato un incidente è essa stessa un campanello d’allarme, perché l’infrastruttura reale ha incidenti, e i provider vivi li documentano.

Il resto lo potete verificare in un pomeriggio con un account di prova. Supporto testnet mancante, repository SDK archiviati su GitHub, supporto che impiega giorni a rispondere durante la fase di valutazione — quando un provider vi corteggia di più —, e prezzi che sono passati silenziosamente da self-service a «contattate le vendite». Ognuno di questi singolarmente è sopportabile. Più insieme rivelano dove sta andando quel changelog.

Se le vostre risposte portano a «pagamenti, self-service, webhook inclusi»: quell’angolo è nostro, i piani sono sulla pagina prezzi e il quickstart ha la prima chiamata funzionante in pochi minuti. Se portano altrove, una delle altre cinque categorie vi servirà meglio, e ora sapete quale.