Erste Schritte

Erstelle einen API-Schlüssel auf der Seite API-Schlüssel in deinem Kontrollpanel, wähle seine Scopes aus und kopiere den Schlüssel. Prüfe dann, ob er funktioniert:

curl https://api.prod.nexus.low.ms/v1/me \
  -H "Authorization: Bearer lowms_..."

Liste deine Server auf und agiere mit ihnen. Aktionen wie Neustarts liefern einen Job zurück, den du abfragen kannst, bis er abgeschlossen ist.

# List servers
curl https://api.prod.nexus.low.ms/v1/servers \
  -H "Authorization: Bearer lowms_..."

# Restart one, then poll the job it returns
curl -X POST https://api.prod.nexus.low.ms/v1/servers/SERVER_ID/power \
  -H "Authorization: Bearer lowms_..." \
  -H "Content-Type: application/json" \
  -d '{"action":"restart"}'

curl https://api.prod.nexus.low.ms/v1/jobs/JOB_ID \
  -H "Authorization: Bearer lowms_..."

Authentifizierung und Scopes

Sende deinen Schlüssel als Bearer-Token. Schlüssel besitzen nur die Scopes, die du ihnen gibst: servers:read, servers:power, backups:read, backups:write, console:send. Behandle Schlüssel wie Passwörter, du kannst einen jederzeit im Panel widerrufen.

Ratenlimits und Fehler

Jeder Schlüssel erhält 60 Leseanfragen und 12 Schreibanfragen pro Minute. Jede /v1-Anfrage zählt zusätzlich auf ein gemeinsames Limit von 300 Anfragen pro Minute je Quell-IP-Adresse, sodass mehrere Clients hinter einer Adresse dieses Limit erreichen können, bevor einer von ihnen sein eigenes erreicht. Antworten enthalten X-RateLimit-Header, und eine 429-Antwort trägt Retry-After.

Fehler sehen immer so aus:

{"error":{"code":"...","message":"..."}}

Jeder Fehler trägt einen Code aus einem festen Satz, sodass deine Skripte anhand von error.code verzweigen können: invalid_key, missing_scope, console_unavailable, not_found, bad_request, unauthorized, forbidden, conflict, server_busy, transfer_in_progress, node_offline, rate_limited, daemon_unavailable, bad_gateway, method_not_allowed, payload_too_large, unsupported_media_type, unavailable, internal_error. Neue Codes können hinzukommen, bestehende werden nie umbenannt oder entfernt.

Versionierung

Die v1 API ändert sich nur additiv: neue Endpunkte und neue optionale Felder. Alles Breaking erscheint als v2, und Abkündigungen werden rechtzeitig angekündigt.