Per sviluppatori
Zinn Digital® è una piattaforma API-first. La stessa engine API che alimenta la nostra dashboard è quella che ricevi: versionata, spec-first e documentata al 100% in fase di compilazione, con SDK generati, una CLI, un provider Terraform, webhook firmati e un server MCP integrato. Qualsiasi strumento tu usi per lavorare — un terminale, una pipeline, un file di stato o un agente IA — la piattaforma risponde a esso.
La maggior parte dei provider aggiunge un'API a un pannello di controllo in un secondo momento, e si vede: metà delle funzioni del pannello non vengono mai rese disponibili. Noi abbiamo fatto il contrario. La dashboard, la console di amministrazione, la CLI, il provider Terraform, il server MCP e le tue integrazioni usano tutti lo stesso motore API. Se puoi farlo nel pannello, puoi farlo via codice.
La specifica OpenAPI è la fonte di verità e nessun endpoint viene rilasciato se non è incluso nella specifica. Questa singola regola è ciò che rende l'API pubblica completamente documentata in fase di compilazione anziché in un secondo momento: non esiste alcun angolo non documentato, poiché un endpoint non documentato non può esistere.
Documentazione di riferimento interattiva, i quattro SDK client, gran parte della CLI e lo scaffolding del provider Terraform sono generati tutti da quella singola specifica. Una sola fonte, molti artefatti, sempre sincronizzati: non dovrai mai inseguire una documentazione che si è discostata dall'implementazione.
Gli endpoint si trovano sotto /v1 con una policy di deprecazione pubblicata e un changelog. Riceverai una comunicazione scritta prima che qualcosa cambi, anziché scoprirlo da una build che fallisce.
I test di contratto implementazione-contro-specifica e il linting di OpenAPI vengono eseguiti a ogni modifica. Qualsiasi scostamento tra il codice e il contratto fa fallire la build: di conseguenza, la specifica da cui generi il client è la stessa che il server rispetta effettivamente.
Due modi per entrare, un unico principio fondamentale alla base di entrambi. Qualunque tu scriva, si applicano gli stessi controlli dei permessi e lo stesso isolamento a livello di database.
Le chiavi hanno il formato zdk_<mode>_<prefix>_<secret>. Nel sistema viene memorizzato solo un hash SHA-256 del segreto: non possiamo mostrarti nuovamente una chiave dopo l'emissione, e non può farlo nessun altro che acceda al nostro database. Le chiavi dispongono di permessi, possono essere revocate e vengono emesse per organizzazione anziché per singola persona.
Le chiavi sandbox sono separate dalle chiavi di produzione e funzionano in modalità sandbox: niente fatturazione reale, niente provisioning reale. I tuoi test di integrazione possono sovraccaricare l'API senza spendere soldi o configurare server.
Le sessioni utente si autenticano tramite JWT emessi da Keycloak, verificati rispetto alla chiave pubblica del realm, e si risolvono nello stesso oggetto Principal di una chiave API. Gli endpoint utilizzano chiavi di permesso granulari come sites.create o apikeys.manage, verificate per singola organizzazione; un permesso in un'organizzazione non garantisce alcun accesso in un'organizzazione separata e non correlata, sebbene si applici a quelle annidate al di sotto di essa.
Ogni richiesta del tenant viene eseguita in una transazione con l'ambito organizzativo Postgres impostato dal principal, garantendo così che l'isolamento sia applicato dal database e non da un filtro ORM che qualcuno potrebbe dimenticare. Il filtro del queryset rimane comunque attivo come difesa in profondità.
È facile far bella figura con un'API in un file README ed è difficile farla comportare bene sotto traffico reale. Sono questi i dettagli su cui abbiamo sudato, perché sono quelli che rompono le integrazioni alle tre del mattino.
Un dettaglio che vale la pena menzionare, perché definisce il comportamento delle operazioni in blocco: un errore 409 per un dominio duplicato risponde alla domanda "questo hostname è ospitato qui?" per qualsiasi tenant, il che costituisce un oracolo di enumerazione e un reale rischio di deanonymisation contro Footprint-Free. Limitare la creazione di siti sarebbe stata la soluzione più pigra e avrebbe compromesso del tutto il prodotto di provisioning in blocco. Al contrario, vengono contingentati solo i tentativi rifiutati di domini duplicati, per principal. Le creazioni riuscite non ne risentono mai — così puoi effettuare il provisioning in blocco tutto il giorno, e il probing si interrompe quasi immediatamente.
Tre consumatori della stessa specifica, per tre diversi modi di lavorare.
Generato per TypeScript, Python, PHP e Go, seguendo le specifiche in modo che un nuovo endpoint arrivi nella tua lingua senza dover attendere un wrapper scritto a mano.
Crea l'impalcatura di un sito WordPress, eseguilo localmente senza installare altro che Node e distribuiscilo. Zinnector® esegue controlli preliminari sul Suo progetto in base allo slot su cui sta per effettuare il deployment — versione di PHP, disco, numero di file — e La avvisa prima del push anziché dopo. Inoltre, effettua l'accesso, elenca i siti, esegue il deployment, gestisce domini e DNS, legge i servizi di posta, esegue backup, esegue WP-CLI inseriti nella whitelist, monitora i log in tempo reale e avvia operazioni in blocco. Gratuito, con licenza MIT e basato su questa stessa API pubblica.
Gestisci siti, domini, record DNS, caselle di posta e piani come infrastruttura come codice. terraform apply esegue il provisioning dell'hosting e i tuoi ambienti diventano riproducibili e verificabili anziché una sequenza di clic che nessuno ha annotato.
Documentazione generata che puoi leggere e chiamare direttamente dal browser, descrivendo esattamente gli endpoint implementati dal server, poiché entrambi derivano dalla stessa specifica.
Dietro la piattaforma si cela una solida spina dorsale di eventi: ogni modifica di stato scrive un evento in una casella di uscita transazionale in Postgres, in modo atomico rispetto alla modifica del database, e un relay lo pubblica su NATS JetStream. Gli eventi sono tipizzati e 버전izzati (versioned) — site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending e tutti gli altri.
Registra un endpoint come WebhookSubscription e scegli i tipi di evento che riceve. Un unico flusso alimenta notifiche, analisi, automazioni e la tua integrazione: stai consumando gli stessi eventi che utilizziamo noi.
Ogni notifica è firmata con HMAC in modo da poter verificare che provenga da noi prima di agire.
I tentativi di consegna falliti vengono ripetuti con un intervallo crescente e ciascun tentativo viene registrato come WebhookDelivery. Puoi controllare e ripetere le consegne dalla dashboard invece di inviare un'e-mail all'assistenza chiedendo cosa abbiamo inviato.
Il pipeline è deliberatamente ad almeno una volta (at-least-once) anziché fingere di essere a una sola volta (exactly-once). Un relay che si interrompe durante la pubblicazione vede scadere la sua concessione (claim lease) e i suoi eventi ripubblicati. Esegui la deduplica sull'id della busta e il tuo consumer sarà corretto per costruzione.
Un'API è solo metà della storia per uno sviluppatore. L'altra metà è il rilascio.
Esponiamo la piattaforma come un server MCP ospitato: un sottile adattatore di protocollo sopra l'API del motore che riutilizza lo stesso catalogo di azioni, RBAC e traccia di audit. Collega Claude Code, Cursor, ChatGPT, Claude Desktop o qualsiasi client compatibile con MCP una volta sola, e ogni funzionalità che aggiungiamo all'API diventerà automaticamente disponibile.
L'agente ottiene tre cose: Strumenti (gli stessi endpoint API, senza logica parallela che possa divergere), Risorse (salute del sito in sola lettura, configurazione, log recenti, metriche, uptime e articoli della KB, in modo che diagnostichi con dati reali prima di agire) e Prompt (modelli di flusso di lavoro pubblicati come "diagnostica questo sito" o "prepara una migrazione").
La sicurezza segue la stessa logica dell'autenticazione: OAuth 2.1, token associati alla tua organizzazione e permessi RBAC con sicurezza a livello di riga applicata, con ambito definito e revocabili per ogni singolo strumento, ambiente sandbox separato da quello di produzione. Le azioni distruttive — eliminazione, sospensione, fatturazione, spese elevate — richiedono una conferma esplicita o una policy di approvazione umana. Limiti di frequenza e tetti di spesa regolano le azioni a pagamento attivate dall'IA, e ogni chiamata MCP viene registrata nei log di audit con identità, strumento, argomenti e risultato.
Supportiamo il protocollo anziché integrare ogni singola app una alla volta, il che significa che puoi cambiare i tuoi strumenti di IA senza che la tua integrazione di hosting debba cambiare di conseguenza.
Sì: si tratta dello stesso motore API, pubblicato e consolidato. La dashboard, la console di amministrazione, la CLI, il provider Terraform, il server MCP e i webhook utilizzano tutti la stessa interfaccia, motivo per cui l'API non è mai indietro rispetto al pannello.
Sì. Le chiavi della sandbox vengono rilasciate separatamente da quelle di produzione e funzionano in modalità di test: nessuna fatturazione reale e nessun provisioning reale. Configura la tua CI con le credenziali della sandbox ed esegui l'intero ciclo di richieste e risposte in sicurezza.
Invia un Idempotency-Key nella tua richiesta POST. Il record di riproduzione viene scritto al momento del commit anziché in linea, quindi un tentativo non potrà mai riprodurre un successo memorizzato nella cache per una riga che non è stata effettivamente salvata, e una richiesta che fallisce rilascia il suo blocco immediatamente in modo che il tuo tentativo corretto non subisca ritardi. La consegna dei webhook è basata sul principio di almeno una volta (at-least-once) per progettazione: esegui la deduplicazione sull'id della busta dalla tua parte.
Oggi no. Le chiavi API vengono emesse per singola organizzazione, quindi un'integrazione che interessa diverse organizzazioni di clienti ne detiene una per ciascuna. Le autorizzazioni vengono inoltre verificate per singola organizzazione per i principal utente: detenere sites.create in un'organizzazione non concede alcun accesso in un'altra separata e non correlata, sebbene si applici alle organizzazioni nidificate al di sotto di essa. Questa è una scelta deliberata: confina una chiave compromessa alla propria organizzazione e alle sotto-organizzazioni ad essa subordinate, anziché all'intera piattaforma.
Il ruolo di sviluppatore (dev) include la lettura dell'organizzazione, la gestione delle chiavi API, la visualizzazione e la creazione di siti, il loro riavvio, lo svuotamento della cache e la visualizzazione e risposta ai ticket. Esclude deliberatamente il controllo della fatturazione. Nota che i permessi di distribuzione (deploy) e di pubblicazione (push-to-live) non ne fanno parte: se un membro del team ne ha bisogno, assegna un ruolo che li preveda, anziché dare per scontato che Sviluppatore sia il ruolo tecnico più ampio.
I tentativi di consegna vengono riprovati con backoff esponenziale e ogni tentativo viene registrato come WebhookDelivery ispezionabile. A monte, gli eventi vengono scritti in un outbox transazionale nella stessa transazione di database della modifica stessa, quindi nulla viene perduto se un consumer non è disponibile: un consumer inattivo subisce un ritardo ma non interrompe mai il producer, e puoi riprodurre le consegne dalla dashboard una volta tornato operativo.
Inizia una prova gratuita di 14 giorni di Footprint-Free Hosting senza carta di credito, fino a 5 siti. I piani a pagamento di Footprint-Free partono da $6/mo per PBN 5. Ogni piano include una garanzia di rimborso di 30 giorni, migrazioni gratuite e nessun vincolo di fornitore.
API basata su specifiche, SDK generati, CLI, provider Terraform, webhook firmati e server MCP: sull'hosting che abbiamo creato per oltre 650.000 siti in tutto il mondo. Inizia una prova gratuita di 14 giorni senza carta di credito e senza dati di pagamento.
Inizia gratis