API do servidor para bots

Tudo o que o painel faz pode ser feito pelo seu próprio código: iniciar um servidor em um horário agendado, mostrar o status no Discord, enviar comandos por um bot.

Chave

A API está disponível em qualquer plano pago — no mesmo lugar onde ficam os arquivos, o SFTP e o acesso da equipe. No plano gratuito, não é emitida uma chave: a chave é o mesmo acesso compartilhado, só que para um bot.

Seção “Jogadores e acesso” → “Chaves de API” → “Emitir”. Confira o que a chave pode fazer — as permissões são as mesmas do acesso compartilhado.

A chave é exibida uma única vez: guardamos apenas o fingerprint dela. Se você perdê-la, emita uma nova e revogue a antiga.

A chave é enviada no cabeçalho Authorization: Bearer mhk_live_....

Métodos

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

Exemplo: iniciar um servidor e esperar que ele fique online

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"

Os backups são criados em segundo plano

POST /backups retorna {"id":"..."} na hora, enquanto o próprio arquivo de backup é montado no node: um mundo de vários gigabytes leva minutos. Verifique a prontidão em GET /backups pelo campo status: pending — ainda em montagem, ready — armazenado no storage (é aí que o sizeMb real aparece), failed — falha na montagem.

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"

Enquanto um backup está em andamento, você não pode criar um segundo no mesmo servidor — o node faz um de cada vez.

Console ao vivo

GET /console retorna um stream de Server-Sent Events: cada linha chega com o prefixo data:. Não é preciso WebSocket — o SSE passa por qualquer proxy.

O que você precisa saber

• Toda ação da chave é registrada no log do servidor com o autor “API key N”. É exatamente o que você precisa quando pessoas e bots administram servidores ao mesmo tempo.
• O rate limit é calculado por chave, não por endereço: trocar de IP não contorna o limite, e um vizinho na rede do escritório não o consome. Ele é generoso para automações normais, mas consultar o status uma vez por segundo vai estourar — uma vez a cada 10–15 segundos é suficiente. O stream do console pode ser aberto até dez vezes por minuto: mantenha uma conexão em vez de abrir uma nova para cada mensagem.
• A chave deixa de funcionar imediatamente se o servidor for suspenso ou se o plano deixar de estar pago. Você não precisa revogá-la manualmente por isso.
• Até cinco chaves por servidor. Revogue as que você não precisa.

Proteção anti-bot

GET /antibot retorna as configurações em dois campos. config — as configurações do próprio servidor; enquanto elas não existirem, é null, e o servidor fica protegido pelo padrão (o campo default). effective está sempre presente: são as configurações em vigor agora ou com as quais o servidor passará a trabalhar depois da primeira edição — leia os valores dele.

PUT /antibot aceita apenas os campos que você quer alterar:

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

Níveis (preset): off, under_attack, balanced, aggressive, custom. O nível se desdobra em valores de verificação por conta própria, então para configuração manual escolha custom e envie as verificações: checkCaptcha, checkPhysics, checkKeepAlive, checkTeleport, checkBrand, checkPing, checkTransfer, checkClientSettings — cada uma off, under_attack ou always. Listas de endereços (vpnMode, datacenterMode, torMode) — off, log ou block. Filtro geográfico — geoMode (off, allow, deny) e geoCountries (códigos de país, por exemplo ["RU","BY"]).

O segredo de forwarding não é emitido nem alterado pela API: ele é mostrado apenas ao dono no painel.

Configurações de arquivo

GET /files/config?path=server.properties retorna o arquivo interpretado — cada entrada com o tipo, o valor atual e a marca “requer reinício”:

{
  "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 indica o que pode ser feito com a entrada: platform — o valor é definido pela hospedagem, edições são recusadas; sync — a entrada existe tanto no painel quanto no arquivo; file — só o arquivo a conhece.

Uma gravação altera apenas as chaves que você enviar; todo o resto do arquivo fica 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"}}'

O formulário lê .properties, .yml/.yaml e .toml — inclusive configs de plugins que o painel desconhece: o tipo do campo é inferido a partir do valor. Chaves aninhadas são endereçadas com ponto: settings.bungeecord, advanced.compression-threshold.

O arquivo inteiro continua disponível via GET/PUT /files/content?path= — os dois caminhos gravam no mesmo lugar.