Politiche
Come viene versionata la Data API, come vengono annunciate le deprecazioni e quanto durano, e come segnalare un problema di sicurezza.
L'API è versionata nel percorso: ogni endpoint vive sotto /api/v1. L'info.version del contratto (attualmente 1.1.0) segue il changelog: il numero minor sale quando viene aggiunto qualcosa, il numero di patch quando viene corretto qualcosa, e una nuova versione di percorso (/api/v2) è l'unico modo in cui viene rilasciato un breaking change.
Gli otto SDK ufficiali seguono l'API: un nuovo endpoint è una release minor dell'SDK, un endpoint rimosso o rinominato una release major.
Queste cose non accadono mai all'interno di una versione di percorso:
{ data, meta }, l'envelope degli errori o il significato di un codice di errore esistente.Queste cose possono accadere in qualsiasi momento e vengono annunciate nel changelog:
error.code, mai il messaggio.Quando un endpoint, un parametro o un campo viene programmato per la rimozione, la cosa viene annunciata nel changelog e via email a ogni titolare di chiave, e da quel giorno l'endpoint risponde con gli header Deprecation e Sunset (RFC 9745, RFC 8594) che indicano la data di rimozione. Il contratto OpenAPI lo segnala con deprecated: true.
La rimozione avviene non prima di sei mesi dall'annuncio. Una nuova versione di percorso convive con la precedente per almeno sei mesi prima che la vecchia venga dismessa allo stesso modo.
I limiti di burst al minuto e le quote mensili fanno parte del tuo piano, sono riportati su ogni risposta negli header X-RateLimit-* e X-Quota-* e documentati nel riferimento. Alzare un limite non è mai breaking; abbassarne uno all'interno di un piano lo è, e segue la tempistica di deprecazione.
Se ritieni di aver trovato una vulnerabilità di sicurezza in bitculator.com, nella Data API, nel server MCP o negli SDK, scrivi a contact@bitculator.com indicando l'URL o l'endpoint interessato, i passaggi per riprodurla e l'impatto che osservi. Riceverai una risposta entro tre giorni lavorativi.
Ti chiediamo di mantenere riservata la segnalazione finché non è risolta, di non accedere né alterare dati non tuoi e di non eseguire attacchi denial-of-service o scansioni automatizzate contro la produzione. Le segnalazioni fatte in buona fede secondo questi termini non saranno oggetto di azioni legali. Non esiste un programma di bug bounty a pagamento; il riconoscimento viene dato su richiesta.
Lo stesso contatto è pubblicato in formato leggibile dalle macchine su /.well-known/security.txt (RFC 9116).
Lo stato live dei componenti, gli incidenti aperti e i disservizi degli ultimi 30 giorni sono sulla pagina di stato e su /status.json.