Para desarrolladores
Zinn Digital® es una plataforma API-first. La misma API del motor que impulsa nuestro panel es la que obtienes: versionada, orientada a especificaciones y documentada al 100 % en el momento de la compilación, con SDKs generados, una CLI, un proveedor de Terraform, webhooks firmados y un servidor MCP por encima. Uses lo que uses para trabajar —una terminal, una canalización, un archivo de estado o un agente de IA—, la plataforma responde ante ello.
La mayoría de los proveedores añaden una API a un panel de control a posteriori, y eso se nota; la mitad de las funciones del panel nunca llegan a estar disponibles. Nosotros lo construimos al revés. El panel, la consola de administración, la CLI, el proveedor de Terraform, el servidor MCP y tus propias integraciones consumen la misma API del motor. Si puedes hacerlo en el panel, puedes hacerlo mediante código.
La especificación OpenAPI es la fuente de la verdad, y ningún endpoint se lanza a menos que esté en ella. Esa única regla es lo que hace que la API pública esté totalmente documentada en el momento de la compilación y no más tarde; no hay ningún rincón sin documentar, porque un endpoint sin documentar no puede existir.
La documentación interactiva de referencia, los cuatro SDK de cliente, gran parte de la CLI y la estructura base del proveedor de Terraform se generan a partir de esa única especificación. Una sola fuente, muchos artefactos, siempre sincronizados; nunca tendrás que perseguir una documentación que se haya desalineado de la implementación.
Los puntos de conexión operan bajo /v1 con una política de obsolescencia publicada y un registro de cambios. Se le avisa antes de que algo cambie, por escrito, en lugar de descubrirlo a través de una compilación fallida.
Las pruebas de contrato de implementación frente a especificación y el análisis estático de OpenAPI se ejecutan en cada cambio. Cualquier discrepancia entre el código y el contrato hace que la compilación falle, por lo que la especificación a partir de la cual genera su cliente es la especificación que el servidor realmente cumple.
Dos formas de acceso, un único principio fundamental detrás de ellas. Uses la que uses, se aplican los mismos controles de permisos y el mismo aislamiento a nivel de base de datos.
Las claves tienen el formato zdk_<mode>_<prefix>_<secret>. Solo se almacena un hash SHA-256 del secreto; no podemos volver a mostrarle una clave después de su emisión, ni tampoco puede hacerlo nadie que acceda a nuestra base de datos. Las claves tienen ámbitos, se pueden revocar y se emiten por organización en lugar de por persona.
Las claves de entorno de pruebas son independientes de las de producción y se ejecutan en modo de pruebas: sin facturación real ni aprovisionamiento real. Sus pruebas de integración pueden saturar la API sin gastar dinero ni levantar servidores.
Las sesiones de usuario se autentican con JWT emitidos por Keycloak, verificados con la clave pública del realm, y se resuelven en el mismo objeto Principal que lo hace una API key. Los endpoints se protegen mediante claves de permisos granulares como sites.create o apikeys.manage, que se comprueban por organización; un permiso en una organización no otorga acceso a otra organización separada y no relacionada, aunque sí se aplica a las organizaciones anidadas bajo ella.
Cada solicitud de inquilino se ejecuta en una transacción con el ámbito de la organización de Postgres establecido a partir del principio, por lo que el aislamiento lo aplica la base de datos, no un filtro de ORM que alguien pueda olvidar. El filtro del conjunto de consultas sigue estando ahí como defensa en profundidad.
Una API es fácil de hacer que se vea bien en un archivo README y difícil de hacer que responda bajo tráfico real. Estas son las partes en las que nos esforzamos, porque son las partes que rompen las integraciones a las tres de la mañana.
Un detalle que vale la pena mencionar, porque determina cómo se comporta el trabajo masivo: un código 409 por dominio duplicado responde "¿este nombre de host está alojado aquí?" para cualquier inquilino, lo cual es un oráculo de enumeración y un riesgo real de desanonimización contra Footprint-Free. Limitar la creación de sitios habría sido la solución fácil y habría roto por completo el producto de aprovisionamiento masivo. En su lugar, solo los intentos rechazados de dominios duplicados se contabilizan en el presupuesto, por principal. Las creaciones exitosas nunca se cargan a este —por lo que puedes aprovisionar de forma masiva todo el día, y el sondeo se detiene casi de inmediato.
Tres consumidores de la misma especificación, para tres formas diferentes de trabajar.
Generado para TypeScript, Python, PHP y Go, siguiendo las especificaciones para que un nuevo endpoint llegue a tu lenguaje sin tener que esperar a un contenedor escrito a mano.
Cree la estructura de un sitio de WordPress, ejecútelo localmente sin más instalación que Node y desplieguelo. Zinnector® realiza comprobaciones previas de su proyecto con respecto al espacio en el que va a realizar el despliegue (versión de PHP, disco, recuento de archivos) y le advierte antes de enviar los cambios en lugar de después. También inicia sesión, enumera sitios, despliega, administra dominios y DNS, lee servicios de correo, realiza copias de seguridad, ejecuta WP-CLI en la lista blanca, sigue registros y ejecuta operaciones masivas. Gratuito, con licencia MIT y basado en esta misma API pública.
Gestiona sitios, dominios, registros DNS, buzones y planes como infraestructura como código. terraform apply aprovisiona el alojamiento, y tus entornos se vuelven reproducibles y revisables en lugar de una secuencia de clics que nadie anotó.
Documentación generada que puedes leer y consultar desde el navegador, describiendo exactamente los endpoints que el servidor implementa, ya que ambos provienen de la misma especificación.
Detrás de la plataforma hay un núcleo de eventos duradero: cada cambio de estado escribe un evento en una bandeja de salida transaccional en Postgres, de forma atómica junto con el cambio en la base de datos, y un repetidor lo publica en NATS JetStream. Los eventos tienen tipos y versiones: site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending y el resto.
Registra un endpoint como WebhookSubscription y elige los tipos de eventos que recibe. Un único flujo alimenta las notificaciones, las analíticas, las automatizaciones y tu propia integración; estás consumiendo exactamente los mismos eventos que nosotros.
Cada entrega está firmada con HMAC para que puedas verificar que proviene de nosotros antes de actuar en consecuencia.
Los envíos fallidos se reintentan con retroceso exponencial y cada intento se registra como WebhookDelivery. Puedes inspeccionar y reintentar los envíos desde el panel de control en lugar de enviar un correo a soporte preguntando qué enviamos.
El pipeline es deliberadamente al menos una vez en lugar de fingir ser exactamente una vez. Un relé que muere a mitad de publicación ve cómo caduca su concesión de reclamación y sus eventos se vuelven a publicar. Desduplica por el id de la sobre y tu consumidor será correcto por construcción.
Una API es solo la mitad de la historia para un desarrollador. La otra mitad es el despliegue.
Exponemos la plataforma como un servidor MCP alojado: un adaptador de protocolo ligero sobre la API del motor que reutiliza exactamente el mismo catálogo de acciones, RBAC y registro de auditoría. Conecta Claude Code, Cursor, ChatGPT, Claude Desktop o cualquier cliente compatible con MCP una vez, y cada funcionalidad que añadamos a la API estará disponible para él automáticamente.
El agente recibe tres cosas: Herramientas (los mismos puntos de conexión de la API, sin lógica paralela que pueda desviarse), Recursos (estado del sitio de solo lectura, configuración, registros recientes, métricas, tiempo de actividad y artículos de la base de conocimientos, para que diagnostique con datos reales antes de actuar) y Indicaciones (plantillas de flujos de trabajo publicadas como «diagnosticar este sitio» o «preparar una migración»).
La seguridad es la misma historia que la autenticación: OAuth 2.1, tokens vinculados a tu organización y permisos RBAC con seguridad a nivel de fila aplicada, con ámbito y revocables por herramienta, con el entorno aislado (sandbox) separado de producción. Las acciones destructivas —eliminar, suspender, facturación, gasto elevado— requieren confirmación explícita o una política de aprobación humana. Los límites de tasa y de gasto controlan las acciones de pago activadas por IA, y cada llamada a MCP queda registrada en la auditoría con su identidad, herramienta, argumentos y resultado.
Apoyamos el protocolo en lugar de integrar cada aplicación una por una, lo que significa que tu elección de herramientas de IA puede cambiar sin que tu integración de alojamiento cambie con ella.
Sí, es la misma API del motor, publicada y optimizada. El panel de control, la consola de administración, la CLI, el proveedor de Terraform, el servidor MCP y los webhooks son consumidores de una sola interfaz, razón por la cual la API no se queda atrás respecto al panel.
Sí. Las claves de sandbox se emiten por separado de las claves de producción y se ejecutan en modo de prueba: sin cobros reales y sin aprovisionamiento real. Apunte su CI a las credenciales de sandbox y ejecute todo el ciclo de solicitudes y respuestas de forma segura.
Envía un Idempotency-Key en tu POST. El registro de reproducción se escribe al confirmar en lugar de en línea, por lo que un reintento nunca puede reproducir un éxito en caché para una fila que en realidad no se confirmó, y una solicitud que falla libera su bloqueo inmediatamente para que tu reintento corregido no se quede bloqueado. La entrega de webhooks es de al menos una vez por diseño; desduplica por el id del sobre en tu extremo.
Hoy no. Las claves de API se emiten por organización, por lo que una integración que abarque varias organizaciones de clientes contiene una clave para cada una. Los permisos también se comprueban por organización para las entidades principales de usuario: tener sites.create en una organización no concede acceso en otra organización independiente y sin relación, aunque se aplica a las organizaciones anidadas bajo ella. Eso es deliberado: limita una clave vulnerada a su propia organización y a las suborganizaciones que dependen de ella, no a toda la plataforma.
El rol de desarrollador incluye la lectura de la organización, la gestión de claves API, la visualización y creación de sitios, su reinicio, el vaciado de su caché y la visualización y respuesta a tickets. Excluye deliberadamente el control de facturación. Ten en cuenta que los permisos de despliegue y de paso a producción no forman parte de él; si un miembro del equipo los necesita, asígnale un rol que los incluya en lugar de asumir que el de Desarrollador es el rol técnico más amplio.
Los envíos se reintentan con retroceso exponencial y cada intento se registra como un WebhookDelivery que puedes inspeccionar. En el origen, los eventos se escriben en una bandeja de salida transaccional dentro de la misma transacción de base de datos que el cambio en sí, por lo que no se pierde nada mientras un consumidor no está disponible; un consumidor caído se retrasa, pero nunca rompe al productor, y puedes repetir los envíos desde el panel de control una vez que vuelvas a estar en línea.
Comienza una prueba de 14 días de Footprint-Free Hosting sin tarjeta — sin datos de pago, hasta 5 sitios. Los planes de pago de Footprint-Free comienzan en $6/mes para PBN 5. Cada plan incluye una garantía de devolución de dinero de 30 días, migraciones gratuitas y sin dependencia del proveedor.
API basada en especificaciones, SDKs generados, una CLI, un proveedor de Terraform, webhooks firmados y un servidor MCP: en el alojamiento que construimos para más de 650.000 sitios en todo el mundo. Comienza una prueba de 14 días sin tarjeta, sin datos de pago.
Empieza gratis