Vendere hosting web con Plesk

Plesk gestisce senza problemi un centinaio di abbonamenti per Lei. Ciò che non fa è prendere un ordine, incassare il denaro, accorgersi che una fattura è rimasta insoluta o sospendere l’account corrispondente. È in questo divario tra «un pannello che ospita siti web» e «un’attività di hosting» che si trova il lavoro, e questa pagina spiega come attraversarlo senza mettere piede nei quattro punti in cui è facile metterlo.

Cosa Plesk Le offre già

Un abbonamento è l’unità che vende: un dominio principale, un piano di servizio, limiti di disco e di traffico e tutto ciò che sta sotto. Un piano di servizio è la descrizione che il pannello dà di quel pacchetto: quota, traffico mensile, quanti domini e quante caselle di posta, quali servizi sono attivi. Entrambi i concetti esistono già, quindi non sta inventando un modello di prodotto, ne sta nominando uno che è già presente.

L’API è valida in un aspetto che conta particolarmente per un prodotto di hosting: una sola chiamata legge tutti gli abbonamenti del server, con il relativo piano, stato, quota e utilizzo. L’abbiamo misurato in 0,33 secondi indipendentemente dal loro numero. Tre chiamate di lettura danno il quadro completo di un server (abbonamenti, clienti, piani), e questo numero non cresce con il numero dei suoi clienti. Costruire lo stesso quadro tramite REST richiederebbe una chiamata più tre per ogni abbonamento.

Una sola chiave apre due API, e servono entrambe

Plesk dispone di una moderna API REST v2 e di una più vecchia API XML/RPC. Nessuna delle due è completa da sola, e non è una questione di preferenza.

REST v2 non ha né abbonamenti né piani di servizio. Ne abbiamo enumerato i 43 percorsi a partire dal suo stesso documento OpenAPI; /subscriptions e /service-plans non vi figurano, e richiederli restituisce un 404 reso come pagina HTML anziché come JSON. Poiché il piano di servizio è il pacchetto di hosting, tutto il versante dei pacchetti deve passare per XML.

Ciò che salva la situazione sono le credenziali. La chiave emessa da POST /api/v2/auth/keys funziona invariata in entrambe: come X-API-Key su REST e come KEY sull’endpoint XML. Misurato, stessa chiave, entrambe le API. Quindi all’operatore si chiede un solo valore, non due.

Ciò che questo costa sono due vocabolari di errore. REST risponde a una chiave inutilizzabile con HTTP 401 e un corpo completamente vuoto. XML risponde alla stessa chiave con HTTP 200 e un codice di errore all’interno del documento. Il che ci porta al punto critico.

Un errore di autenticazione che sembra un server vuoto

Poiché l’API XML restituisce HTTP 200 per una chiave errata, un client che controlla il codice di stato legge un errore di autenticazione come un ciclo riuscito che non ha trovato nulla. E un ciclo riuscito che non ha trovato nulla ha un significato in qualsiasi piattaforma di hosting: ogni account che ieri era presente è scomparso.

La conseguenza non è un dashboard rotto. È un sistema che contrassegna ognuno dei suoi clienti come eliminato perché una chiave è scaduta. La regola che ne consegue è assoluta: sull’API XML il codice di stato non porta alcuna informazione, nemmeno sull’autenticazione. Analizzi il documento e tratti una risposta illeggibile come sconosciuta anziché come vuota.

Nemmeno un server vuoto produce un errore: produce un unico risultato vuoto, che è la risposta corretta quando davvero non ce ne sono. Distinguere questi due casi è tutto il lavoro.

La trappola della sospensione: scrivere e leggere lo stesso campo

Ci sono due modi per sospendere un abbonamento in Plesk e non scrivono lo stesso campo.

Rilegga la seconda riga. Sospendere tramite REST lascia a zero il campo che legge l’interrogazione in blocco. Quindi un prodotto di hosting che sospende tramite REST e interroga tramite XML mostrerà l’account come attivo mentre in realtà è sospeso. Nulla dà errore. Nulla diventa rosso. Il suo pannello e il suo server sono semplicemente in disaccordo, e la prima persona ad accorgersene è un cliente che non riesce a raggiungere un sito che Lei crede in funzione.

La regola: sospenda e riattivi attraverso lo stesso campo che legge. Provibr usa XML <webspace><set><gen_setup><status>, e dopodiché entrambe le viste si muovono insieme: il campo XML segnala 16 e REST segnala sospeso.

gen_info.status è una maschera di bit, e i valori che abbiamo misurato sono 0 per attivo, 1 per webspace-off e 16 per disattivato dall’amministratore. Tutto ciò che non è zero conta come sospeso, che è l’unica lettura che sopravvive a un valore che non abbiamo ancora visto.

Due set di dati che non chiediamo mai al pannello

L’API XML di Plesk è pensata per l’amministrazione, perciò due dei suoi set di dati restituiscono materiale di credenziali al chiamante che li richiede:

• <webspace><get> con il set di dati hosting restituisce la password FTP dell’account in chiaro, con un campo che la contrassegna esplicitamente come tale.
• <customer><get> con il set di dati gen_info restituisce l’hash della password del cliente (bcrypt) insieme al tipo di hash.

Questo è ragionevole per un’API di amministrazione. Non è qualcosa che una piattaforma di hosting dovrebbe tirare giù dalla rete a intervalli regolari.

Uno strato di oscuramento è la risposta sbagliata a questo. La risposta giusta è non chiedere. L’interrogazione di Provibr richiede esattamente quattro set di dati (informazioni generali, limiti, statistiche e abbonamenti), e li abbiamo esaminati campo per campo per confermare che nessuno porta un segreto. L’elenco dei clienti viene da REST, che non ha alcun campo password.

C’è una conseguenza di progettazione che vale la pena esprimere. L’utente FTP o di sistema di un abbonamento sarebbe un identificatore breve allettante, ma vive solo nel set di dati hosting, perciò usarlo come identità significherebbe recuperare la password di ogni cliente a ogni ciclo di interrogazione. Da qui il dominio al suo posto.

L’identità di un abbonamento è un nome di dominio

In Plesk, un abbonamento prende il nome dal suo dominio principale. È ciò che il pannello mostra, ciò su cui la sua API filtra e ciò che qualsiasi integrazione deve memorizzare.

Questa è una differenza reale rispetto a cPanel e DirectAdmin, dove un account ha separatamente un nome utente breve e un dominio, e ha una conseguenza pratica: il dominio non può più essere modificato in seguito. Qualunque cosa il suo sistema di fatturazione memorizzi come identificatore di un abbonamento Plesk è un nome di dominio, e un cliente che vuole rinominare il proprio sito chiede un nuovo abbonamento anziché una modifica.

Due dettagli minori misurati lungo il percorso. La specifica di Plesk stessa dice che una password cliente va da 5 a 14 caratteri; una password di 22 caratteri è stata accettata senza obiezioni, quindi il limite documentato non è quello applicato. E Plesk sceglie da solo l’indirizzo IP dal proprio pool, motivo per cui un account di hosting in Provibr ha un campo indirizzo vuoto finché il pannello non ne segnala uno.

Un ordine fallito può lasciarsi dietro mezzo abbonamento

Misurato: creare un dominio con un piano di servizio che non esiste risponde con HTTP 404 e un messaggio chiaro, e l’oggetto dominio esiste comunque dopo, senza tipo di hosting e con un document root vuoto. Plesk crea prima l’oggetto e applica il piano dopo, e non annulla nulla quando il secondo passaggio fallisce.

Il cliente ha pagato, l’ordine è fallito, e il tentativo successivo ora fallisce in modo diverso, perché il dominio è già in uso, da un account che non ha mai ricevuto. Cerchi quindi il piano prima di creare qualsiasi cosa, dall’elenco dei piani che ha già recuperato, e faccia pulizia dopo ogni creazione fallita. Per contrasto, un errore di validazione di campo come un login duplicato torna con HTTP 400 e non lascia nulla dietro di sé: quel controllo viene eseguito prima della creazione, e solo la ricerca del piano avviene troppo tardi.

Nessun ritardo, cosa più rara di quanto dovrebbe essere

L’elenco di utilizzo di DirectAdmin è indietro di circa tre secondi rispetto alla realtà in entrambe le direzioni, il che costringe a una seconda chiamata autorevole. Plesk no. Abbiamo misurato una creazione e un’eliminazione a fronte della lettura in blocco:

    0 ms  create
 4519 ms  create returns 201
 4957 ms  bulk read sees the subscription      <- immediately
 4957 ms  delete
12622 ms  delete returns 200
13001 ms  bulk read no longer sees it          <- immediately

Plesk è transazionale: una volta che la chiamata risponde, la modifica è visibile nella lettura in blocco. Un’unica fonte autorevole, nessuna seconda chiamata, nessuna attesa.

Anche i tempi in sé meritano attenzione. Creare un abbonamento richiede da 4,1 a 4,5 secondi ed eliminarne uno 7,7 secondi, abbastanza a lungo da dover dire a un cliente che guarda un modulo d’ordine che qualcosa sta accadendo. Cambiare piano richiede 1,5 secondi e sospendere 0,78.

Cosa fa Provibr con tutto questo

Provibr si colloca tra la sua fatturazione e il suo server Plesk. Collega il server con una sola chiave API, e dopodiché un abbonamento è una riga ordinaria: lo ordini, lo sospenda, lo riattivi, lo sposti su un altro piano di servizio, lo elimini.

• Una sola chiave, perché la stessa chiave apre entrambe le API.
• La sospensione passa per il campo che legge l’interrogazione, così pannello e server non possono divergere.
• L’interrogazione non richiede mai un set di dati contenente una password, così nessun segreto del cliente raggiunge la piattaforma.
• Il piano viene risolto prima della creazione, e una creazione fallita viene ripulita anziché lasciata in sospeso.
• Nulla viene creduto sulla parola. Ogni mutazione termina rileggendo l’abbonamento.
• L’agente si connette verso l’esterno dalla sua rete, così la porta 8443 non è esposta a internet e nulla viene installato sul server Plesk.
• Gli abbonamenti che non ha ordinato tramite Provibr vengono lasciati intatti finché non li importa, il che rende un server con duecento clienti esistenti adottabile anziché una ricostruzione.

Cosa non fa

Gestisce gli abbonamenti su un server Plesk che Lei amministra, non il server in sé: i servizi, le zone DNS, l’instradamento della posta e le impostazioni del pannello stesso restano dove sono. Non c’è console, perché un account di hosting non è una macchina. Le caselle di posta, i database e il DNS all’interno di un abbonamento appartengono a Plesk e al suo cliente.

Una lacuna onesta: tutto ciò che è qui è stato misurato con una chiave di amministratore. Se una chiave con ambito rivenditore o cliente possa usare l’API XML non è stato testato, perciò l’integrazione sonda al momento della connessione e rifiuta credenziali che possono vedere solo una parte di un pannello anziché gestirne in silenzio la metà.

Da leggere dopo

• Automatizzare la fatturazione e il provisioning di Plesk: i tre momenti in cui denaro e macchine si toccano, e le trappole di ciascuno.
• Alternative a cPanel per i provider di hosting: sei pannelli su modello di licenza, sforzo di migrazione e comportamento dell’API misurato.
• Configurare Plesk: la chiave API, i piani di servizio, i piani web e l’importazione degli abbonamenti.

Misurato su Plesk Obsidian 18.0.80 ad agosto 2026, con tutte le risposte registrate come fixture. Il comportamento con una chiave con ambito rivenditore, con più di un abbonamento per cliente e sotto un carico di traffico reale non è stato misurato, ed è segnalato come tale più sopra.