Cómo vender alojamiento web con Plesk

Plesk hará funcionar sin problema un centenar de suscripciones. Lo que no hará es tomar un pedido, cobrar el dinero, notar que una factura quedó impagada ni suspender la cuenta que le corresponde. En esa distancia entre «un panel que aloja sitios web» y «un negocio de alojamiento» está el trabajo, y esta página trata de cómo salvarla sin pisar los cuatro sitios donde es fácil pisar.

Lo que Plesk ya ofrece

Una suscripción es la unidad que se vende: un dominio principal, un plan de servicio, límites de disco y de tráfico, y todo lo que hay debajo. Un plan de servicio es la descripción que el propio panel hace de ese paquete: cuota, tráfico mensual, cuántos dominios y buzones, qué servicios están activos. Ambos conceptos ya existen, así que no se inventa un modelo de producto, se nombra uno que ya está ahí.

La API destaca en un aspecto que importa especialmente para un producto de alojamiento: una sola llamada lee todas las suscripciones del servidor, con su plan, su estado, su cuota y su uso. Lo medimos en 0,33 segundos, sea cual sea su número. Tres llamadas de lectura dan el cuadro completo de un servidor (suscripciones, clientes, planes) y ese número no crece con la cantidad de clientes. Construir el mismo cuadro sobre REST costaría una llamada más tres por suscripción.

Una sola clave abre dos API, y hacen falta las dos

Plesk dispone de una API REST v2 moderna y de una API XML/RPC más antigua. Ninguna está completa por sí sola, y eso no es una cuestión de preferencia.

REST v2 no tiene ni suscripciones ni planes de servicio. Enumeramos sus 43 rutas a partir de su propio documento OpenAPI; /subscriptions y /service-plans no figuran entre ellas, y pedirlas devuelve un 404 presentado como página HTML en lugar de JSON. Puesto que el plan de servicio es el paquete de alojamiento, todo el lado de los paquetes debe pasar por XML.

Lo que salva la situación son las credenciales. La clave emitida por POST /api/v2/auth/keys funciona igual en ambas: como X-API-Key en REST y como KEY en el punto de acceso XML. Medido, la misma clave, las dos API. Así que al operador se le pide un solo valor, no dos.

Lo que cuesta son dos vocabularios de error. REST responde a una clave inservible con un HTTP 401 y un cuerpo completamente vacío. XML responde a la misma clave con un HTTP 200 y un código de error dentro del documento. Y eso nos lleva al filo cortante.

Un fallo de autenticación que parece un servidor vacío

Como la API XML devuelve un HTTP 200 ante una clave errónea, un cliente que comprueba el código de estado lee un fallo de autenticación como una ronda con éxito que no encontró nada. Y una ronda con éxito que no encontró nada tiene un significado en cualquier plataforma de alojamiento: todas las cuentas que ayer estaban ahí han desaparecido.

La consecuencia no es un panel de control roto. Es un sistema que marca como eliminados a todos los clientes porque una clave caducó. La regla que se deriva es absoluta: en la API XML el código de estado no aporta ninguna información, ni siquiera sobre la autenticación. Hay que analizar el documento y tratar una respuesta ilegible como desconocida en lugar de como vacía.

Un servidor vacío tampoco produce un error: produce un único resultado vacío, que es la respuesta correcta cuando de verdad no hay ninguna. Distinguir ambos casos es todo el trabajo.

La trampa de suspensión: escribir y leer el mismo campo

Hay dos formas de suspender una suscripción en Plesk, y no escriben el mismo campo.

Léase de nuevo la segunda fila. Suspender por REST deja a cero el campo que lee el sondeo en bloque. Así, un producto de alojamiento que suspende por REST y sondea por XML mostrará la cuenta como activa cuando, en realidad, está suspendida. Nada falla. Nada se pone en rojo. El panel y el servidor simplemente no coinciden, y la primera persona en darse cuenta es un cliente que no puede acceder a un sitio que se cree en marcha.

La regla: suspender y reactivar por el mismo campo que se lee. Provibr utiliza XML <webspace><set><gen_setup><status>, y a partir de ahí ambas vistas evolucionan juntas: el campo XML indica 16 y REST indica suspendida.

gen_info.status es una máscara de bits, y los valores que medimos son 0 para activo, 1 para webspace-off y 16 para desactivado por el administrador. Todo lo que no sea cero cuenta como suspendido, que es la única lectura que sobrevive a un valor que aún no hemos visto.

Dos conjuntos de datos que nunca pedimos al panel

La API XML de Plesk está pensada para la administración, de modo que dos de sus conjuntos de datos devuelven material de credenciales a quien los pide:

• <webspace><get> con el conjunto de datos hosting devuelve la contraseña FTP de la cuenta en texto claro, con un campo que la marca explícitamente como tal.
• <customer><get> con el conjunto de datos gen_info devuelve el hash de la contraseña del cliente (bcrypt) junto con el tipo de hash.

Eso es razonable para una API de administración. No es algo que una plataforma de alojamiento deba traer por la red de forma periódica.

Una capa de censura es la respuesta equivocada a esto. La respuesta correcta es no pedir. El sondeo de Provibr solicita exactamente cuatro conjuntos de datos (información general, límites, estadísticas y suscripciones) y los recorrimos campo por campo para confirmar que ninguno lleva un secreto. La lista de clientes viene de REST, que no tiene ningún campo de contraseña.

Hay una consecuencia de diseño que conviene decir. El usuario FTP o de sistema de una suscripción sería un identificador corto atractivo, pero vive solo en el conjunto de datos hosting, así que usarlo como identidad significaría descargar la contraseña de cada cliente en cada ciclo de sondeo. De ahí el dominio en su lugar.

La identidad de una suscripción es un nombre de dominio

En Plesk, una suscripción toma el nombre de su dominio principal. Es lo que el panel muestra, aquello por lo que filtra su API, y lo que cualquier integración debe almacenar.

Es una diferencia real respecto a cPanel y DirectAdmin, donde una cuenta tiene un nombre de usuario corto y un dominio por separado, y tiene una consecuencia práctica: el dominio no puede cambiarse después. Lo que el sistema de facturación almacene como identificador de una suscripción Plesk es un nombre de dominio, y un cliente que quiere renombrar su sitio está pidiendo una nueva suscripción y no una modificación.

Dos detalles menores medidos por el camino. La propia especificación de Plesk dice que una contraseña de cliente tiene de 5 a 14 caracteres; se aceptó sin queja una contraseña de 22 caracteres, así que el límite documentado no es el que se aplica. Y Plesk elige él mismo la dirección IP de su propio grupo, razón por la cual una cuenta de alojamiento en Provibr tiene el campo de dirección vacío hasta que el panel informa de una.

Un pedido fallido puede dejar media suscripción atrás

Medido: crear un dominio con un plan de servicio que no existe responde con un HTTP 404 y un mensaje claro, y aun así el objeto de dominio existe después, sin tipo de alojamiento y con una raíz de documentos vacía. Plesk crea primero el objeto y aplica después el plan, y no revierte nada cuando el segundo paso falla.

El cliente pagó, el pedido falló, y el siguiente reintento falla ahora de otra manera, porque el dominio ya está en uso, por una cuenta que nunca recibió. Así que conviene buscar el plan antes de crear nada, en la lista de planes ya obtenida, y limpiar después de cualquier creación fallida. En contraste, un error de validación de campo como un identificador duplicado vuelve en HTTP 400 y no deja nada atrás: esa comprobación se ejecuta antes de la creación, y solo la búsqueda del plan llega demasiado tarde.

Sin latencia, algo más raro de lo que debería

El listado de uso de DirectAdmin va unos tres segundos por detrás de la realidad en ambos sentidos, lo que obliga a una segunda llamada de referencia. Plesk no. Medimos una creación y un borrado frente a la lectura en bloque:

    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 es transaccional: en cuanto la llamada responde, el cambio es visible en la lectura en bloque. Una sola fuente de referencia, sin segunda llamada, sin espera.

Los tiempos en sí merecen anotarse. Crear una suscripción lleva 4,1 a 4,5 segundos y borrar una 7,7 segundos, lo bastante largo como para que a un cliente que mira un formulario de pedido haya que avisarle de que algo está pasando. Cambiar de plan lleva 1,5 segundos y suspender 0,78.

Lo que Provibr hace con todo esto

Provibr se sitúa entre la facturación y el servidor Plesk. El servidor se conecta con una sola clave de API, y a partir de ahí una suscripción es una fila ordinaria: pedirla, suspenderla, reactivarla, moverla a otro plan de servicio, eliminarla.

• Una sola clave, porque la misma clave abre las dos API.
• La suspensión pasa por el campo que lee el sondeo, para que el panel y el servidor no puedan divergir.
• El sondeo nunca solicita un conjunto de datos que contenga una contraseña, para que ningún secreto de cliente llegue a la plataforma.
• El plan se resuelve antes de la creación, y una creación fallida se limpia en lugar de dejarse atrás.
• Nada se cree bajo palabra. Cada mutación termina releyendo la suscripción.
• El agente marca hacia el exterior desde su red, de modo que el puerto 8443 no queda expuesto a internet y no se instala nada en el servidor Plesk.
• Las suscripciones que no se pidieron a través de Provibr se dejan intactas hasta importarlas, lo que hace que un servidor con doscientos clientes existentes sea adoptable en lugar de una reconstrucción.

Lo que no hace

Gestiona suscripciones en un servidor Plesk que se opera, no el servidor en sí: los servicios, las zonas DNS, el enrutamiento de correo y los propios ajustes del panel se quedan donde están. No hay consola, porque una cuenta de alojamiento no es una máquina. Los buzones, las bases de datos y el DNS dentro de una suscripción pertenecen a Plesk y al cliente.

Una salvedad honesta: todo esto se midió con una clave de administrador. Si una clave restringida a revendedor o a cliente puede siquiera usar la API XML no se ha probado, así que la integración sondea en el momento de la conexión y rechaza unas credenciales que solo ven una parte de un panel, en lugar de gestionar en silencio la mitad de él.

Seguir leyendo

• Automatizar la facturación y el aprovisionamiento de Plesk: los tres momentos en que el dinero y las máquinas se tocan, y las trampas de cada uno.
• Alternativas a cPanel para proveedores de alojamiento: seis paneles sobre modelo de licencia, esfuerzo de migración y comportamiento de API medido.
• Configurar Plesk: la clave de API, los planes de servicio, los planes web y la importación de suscripciones.

Medido sobre Plesk Obsidian 18.0.80 en agosto de 2026, con todas las respuestas registradas como fixtures. El comportamiento con una clave restringida a revendedor, con más de una suscripción por cliente y bajo carga de tráfico real no se midió, y así se indica más arriba.