API serwera dla botów

Wszystko, co potrafi panel, możesz zrobić z własnego kodu: uruchomić serwer według harmonogramu, pokazać status na Discordzie, wysyłać komendy z bota.

Klucz

API jest dostępne w każdym płatnym planie — w tym samym miejscu, co pliki, SFTP i dostęp dla zespołu. W darmowym planie klucz nie jest wydawany: klucz to ten sam dostęp współdzielony, tylko dla bota.

Sekcja „Gracze i dostęp” → „Klucze API” → „Wydaj”. Sprawdź, co klucz może robić — uprawnienia są takie same jak dla dostępu współdzielonego.

Klucz jest pokazywany raz: przechowujemy tylko jego odcisk. Jeśli go zgubisz, wydaj nowy i unieważnij stary.

Klucz przekazujesz w nagłówku Authorization: Bearer mhk_live_....

Metody

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

Przykład: uruchom serwer i poczekaj, aż będzie 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"

Kopie zapasowe tworzą się w tle

POST /backups zwraca {"id":"..."} natychmiast, ale samo archiwum jest tworzone na węźle: świat o wielkości kilku gigabajtów zajmuje kilka minut. Gotowość sprawdzisz w GET /backups za pomocą pola status: pending — wciąż jest tworzona, ready — zapisana w magazynie (wtedy pojawia się prawdziwe sizeMb), failed — nie udało się utworzyć.

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"

Gdy kopia zapasowa jest w trakcie tworzenia, nie możesz utworzyć drugiej na tym samym serwerze — węzeł wykonuje je pojedynczo.

Konsola na żywo

GET /console zwraca strumień Server-Sent Events: każda linia przychodzi z prefiksem data:. WebSocket nie jest potrzebny — SSE przechodzi przez każde proxy.

Co powinieneś wiedzieć

• Każda akcja na kluczu jest logowana w logu serwera z autorem „Klucz API N”. To dokładnie to, czego potrzebujesz, gdy serwerami zarządzają i ludzie, i boty.
• Limit zapytań jest liczony na klucz, a nie na adres: zmiana IP nie omija limitu, a sąsiad z sieci biurowej go nie zużywa. Jest hojny dla normalnej automatyzacji, ale odpytywanie statusu raz na sekundę go wyczerpie — raz na 10–15 sekund wystarczy. Strumień konsoli można otworzyć maksymalnie dziesięć razy na minutę: trzymaj jedno połączenie zamiast otwierać nowe dla każdej wiadomości.
• Klucz przestaje działać natychmiast, jeśli serwer zostanie zawieszony lub plan nie jest już opłacany. Nie musisz go w tym celu ręcznie unieważniać.
• Maksymalnie pięć kluczy na serwer. Unieważnij te, których nie potrzebujesz.

Ochrona anti-bot

GET /antibot zwraca ustawienia w dwóch polach. config — własne ustawienia serwera; dopóki nie istnieją, jest to null, a serwer jest chroniony domyślnie (pole default). effective jest zawsze obecne: to ustawienia, które aktualnie obowiązują lub z którymi serwer zacznie pracować po pierwszej edycji — czytaj wartości z niego.

PUT /antibot przyjmuje tylko pola, które chcesz zmienić:

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

Poziomy (preset): off, under_attack, balanced, aggressive, custom. Poziom sam rozwija się w wartości sprawdzeń, więc do ręcznej konfiguracji wybierz custom i wyślij sprawdzenia: checkCaptcha, checkPhysics, checkKeepAlive, checkTeleport, checkBrand, checkPing, checkTransfer, checkClientSettings — każde z nich off, under_attack lub always. Listy adresów (vpnMode, datacenterMode, torMode) — off, log lub block. Geo-filtr — geoMode (off, allow, deny) i geoCountries (kody krajów, np. ["RU","BY"]).

Sekret przekazywania nie jest wydawany ani zmieniany przez API: jest pokazywany tylko właścicielowi w panelu.

Ustawienia konfiguracji

GET /files/config?path=server.properties zwraca sparsowany plik — każdy wpis z jego typem, bieżącą wartością i flagą „wymaga restartu”:

{
  "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 mówi, co można zrobić z wpisem: platform — wartość jest ustawiana przez hosting, edycje są odrzucane; sync — wpis istnieje zarówno w panelu, jak i w pliku; file — tylko plik o nim wie.

Zapis zmienia tylko klucze, które wyślesz; wszystko inne w pliku pozostaje nietknięte:

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

Formularz odczytuje .properties, .yml/.yaml i .toml — w tym konfiguracje pluginów, o których panel nic nie wie: typ pola jest wnioskowany z wartości. Zagnieżdżone klucze adresuje się kropką: settings.bungeecord, advanced.compression-threshold.

Cały plik jest nadal dostępny przez GET/PUT /files/content?path= — obie ścieżki zapisują w to samo miejsce.