Primeros pasos

Crea una clave de API en la página Claves de API de tu panel de control, elige sus scopes y copia la clave. Luego comprueba que funciona:

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

Lista tus servidores y actúa sobre ellos. Acciones como los reinicios devuelven un job que puedes consultar hasta que se complete.

# 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_..."

Autenticación y scopes

Envía tu clave como token bearer. Las claves solo tienen los scopes que les concedas: servers:read, servers:power, backups:read, backups:write, console:send. Trata las claves como contraseñas, puedes revocar una en cualquier momento desde el panel.

Límites de tasa y errores

Cada clave recibe 60 solicitudes de lectura y 12 de escritura por minuto. Cada solicitud a /v1 cuenta además para un límite compartido de 300 solicitudes por minuto por dirección IP de origen, así que varios clientes tras una misma dirección pueden alcanzar ese límite antes que el suyo propio. Las respuestas incluyen cabeceras X-RateLimit, y una respuesta 429 incluye Retry-After.

Los errores siempre tienen este aspecto:

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

Cada error incluye uno de un conjunto fijo de códigos, para que tus scripts puedan actuar según error.code: 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. Se pueden añadir códigos nuevos, y los existentes nunca se renombran ni se eliminan.

Versionado

La API v1 solo cambia de forma aditiva: nuevos endpoints y nuevos campos opcionales. Cualquier cambio disruptivo se publica como v2, y las obsolescencias se anuncian con suficiente antelación.