API del servidor para bots

Todo lo que hace el panel se puede hacer desde tu propio código: iniciar un servidor según un horario, mostrar el estado en Discord, enviar comandos desde un bot.

Clave

La API está disponible en cualquier plan de pago — el mismo lugar donde están los archivos, SFTP y el acceso de equipo. En el plan gratuito, no se emite una clave: una clave es el mismo acceso compartido, solo que para un bot.

Sección «Jugadores y acceso» → «Claves de API» → «Emitir». Comprueba qué puede hacer la clave — los permisos son los mismos que para el acceso compartido.

La clave se muestra una sola vez: solo guardamos su huella. Si la pierdes, emite una nueva y revoca la antigua.

La clave se pasa en el encabezado Authorization: Bearer mhk_live_....

Métodos

URL base — https://millida.net/v2/hosting/api.

Ejemplo: iniciar un servidor y esperar a que esté en línea

KEY="mhk_live_xxx"
API="https://millida.net/v2/hosting/api"

curl -sX POST "$API/start" -H "Authorization: Bearer $KEY"

until curl -s "$API/status" -H "Authorization: Bearer $KEY" | grep -q RUNNING; do
  sleep 5
done
echo "server online"

Las copias de seguridad se crean en segundo plano

POST /backups devuelve {"id":"..."} inmediatamente, mientras que la copia en sí se ensambla en el nodo: un mundo de varios gigabytes tarda minutos. Comprueba si está lista en GET /backups usando el campo status: pending — aún se está ensamblando, ready — guardada en el almacenamiento (ahí es cuando aparece el sizeMb real), failed — falló el ensamblaje.

ID=$(curl -sX POST "$API/backups" -H "Authorization: Bearer $KEY" | jq -r .id)

until curl -s "$API/backups" -H "Authorization: Bearer $KEY" \
  | jq -e --arg id "$ID" '.[] | select(.id==$id) | select(.status=="ready")' >/dev/null; do
  sleep 15
done
echo "backup ready"

Mientras una copia de seguridad está en curso, no puedes crear una segunda en el mismo servidor — el nodo las hace de una en una.

Consola en vivo

GET /console devuelve un flujo de Server-Sent Events: cada línea llega con el prefijo data:. No se necesita WebSocket — SSE pasa a través de cualquier proxy.

Lo que debes saber

• Cada acción de la clave queda registrada en el registro del servidor con el autor «clave de API N». Esto es exactamente lo que necesitas cuando tanto personas como bots están ejecutando servidores.
• El límite de peticiones se calcula por clave, no por dirección: cambiar de IP no evita el límite, y un vecino en la red de la oficina no lo consume. Es generoso para la automatización normal, pero consultar el estado una vez por segundo lo alcanzará — una vez cada 10–15 segundos es suficiente. El flujo de la consola se puede abrir hasta diez veces por minuto: mantén una conexión en lugar de abrir una nueva por cada mensaje.
• La clave deja de funcionar inmediatamente si el servidor se suspende o el plan deja de estar pagado. No necesitas revocarla manualmente para eso.
• Hasta cinco claves por servidor. Revoca las que no necesites.

Protección anti-bot

GET /antibot devuelve la configuración en dos campos. config — la configuración propia del servidor; hasta que exista, es null, y el servidor está protegido por defecto (el campo default). effective siempre está presente: es la configuración que está actualmente en vigor o con la que el servidor empezará a funcionar tras la primera edición — lee los valores de ahí.

PUT /antibot acepta solo los campos que quieres cambiar:

curl -sX PUT "$API/antibot" -H "Authorization: Bearer $KEY"   -H 'Content-Type: application/json'   -d '{"preset":"balanced"}'

Niveles (preset): off, under_attack, balanced, aggressive, custom. El nivel se expande a valores de comprobación por sí solo, así que para la configuración manual elige custom y envía las comprobaciones: checkCaptcha, checkPhysics, checkKeepAlive, checkTeleport, checkBrand, checkPing, checkTransfer, checkClientSettings — cada una off, under_attack o always. Listas de direcciones (vpnMode, datacenterMode, torMode) — off, log o block. Filtro geográfico — geoMode (off, allow, deny) y geoCountries (códigos de país, p. ej. ["RU","BY"]).

El secreto de reenvío no se emite ni se cambia a través de la API: solo se muestra al propietario en el panel.

Ajustes de configuración

GET /files/config?path=server.properties devuelve el archivo analizado — cada entrada con su tipo, valor actual y un indicador de «requiere reinicio»:

{
  "path": "server.properties",
  "format": "properties",
  "options": [
    { "key": "pvp", "type": "boolean", "value": "true", "owner": "sync", "requiresRestart": false },
    { "key": "difficulty", "type": "select", "value": "normal", "values": ["peaceful", "easy", "normal", "hard"], "owner": "sync", "requiresRestart": false },
    { "key": "server-port", "type": "integer", "value": "25565", "owner": "platform", "requiresRestart": true }
  ]
}

owner te dice qué se puede hacer con la entrada: platform — el valor lo establece el hosting, las ediciones se rechazan; sync — la entrada existe tanto en el panel como en el archivo; file — solo el archivo la conoce.

Una escritura cambia solo las claves que envías; todo lo demás en el archivo permanece intacto:

curl -sX POST "$API/files/config" -H "Authorization: Bearer $KEY"   -H 'Content-Type: application/json'   -d '{"path":"server.properties","values":{"pvp":"false","difficulty":"hard"}}'

El formulario lee .properties, .yml/.yaml y .toml — incluidos los archivos de configuración de plugins que el panel desconoce: el tipo de campo se infiere del valor. Las claves anidadas se direccionan con un punto: settings.bungeecord, advanced.compression-threshold.

El archivo completo sigue estando disponible mediante GET/PUT /files/content?path= — ambas rutas escriben en el mismo lugar.