Primeros pasos con la API
Guía rápida de la API
Crea una clave de API, elige un plan y un centro de datos, contrata un servidor bare metal, paga su factura e instala un sistema operativo mediante la API.
Siete peticiones te llevan desde una clave de API nueva hasta un servidor con el sistema operativo elegido en ejecución. Cada petición aparece en cURL, Node.js, Python, Go, PHP, Ruby, Java, C# y PowerShell; el lenguaje que elijas en una se aplica a las demás, aquí y en las páginas de la referencia de la API.
Crear una clave de API
En la consola en la nube, abre los ajustes de tu organización y elige Create an API Key en Manage API Keys. La consola muestra la clave una sola vez, al crearla, así que cópiala antes de cerrar el diálogo.
Todas las peticiones de la documentación la muestran como <api-key> en la cabecera Authorization: Bearer. Pon tu clave en su lugar y los valores que devuelve cada paso en lugar de los demás valores <...> y {serviceId}.
Elegir un plan y un centro de datos
Enumera los planes bare metal:
curl --request GET \
--url https://api.serverside.com/v1/baremetal/plans \
--header 'Authorization: Bearer <api-key>'La lista está paginada, con 25 planes por página salvo que pageSize solicite más, hasta 1000. Cada plan de data incluye su id y slug, su hardware en specs y dos campos que determinan el pedido:
availabilitytiene una entrada por centro de datos, con sucode(comoams1), sucityyfacilityy laquantitydisponible allí.pricingda lacurrencyy, enrates, una entrada por ciclo de facturación en el que se vende el plan. ElpriceMillicentsde una entrada es el precio de un periodo de ese ciclo yeffectiveMonthlyMillicentsel mismo precio por mes, ambos en milésimas de céntimo (Dinero).
Elige un plan y un centro de datos cuya quantity sea mayor que cero y conserva el slug del plan y el code del centro de datos. Para empezar por una ubicación, Listar regiones indica todos los centros de datos donde puedes contratar, con su code, ciudad e instalación.
Contratar el servidor
Crea un pedido del plan en ese centro de datos con el ciclo de facturación que vayas a pagar:
curl --request POST \
--url https://api.serverside.com/v1/billing/orders \
--header 'Authorization: Bearer <api-key>' \
--header 'Idempotency-Key: <idempotency-key>' \
--header 'Content-Type: application/json' \
--data '
{
"cycle": "MONTHLY",
"items": [
{
"type": "BAREMETAL",
"plan": "<plan-slug>",
"datacenter": "<datacenter-code>",
"name": "<hostname>"
}
]
}
'plan y datacenter aceptan ID además del slug y el código. name es opcional, de 2 a 64 caracteres, y el despliegue lo convierte en el nombre de host del sistema operativo, así que un nombre como web1.example.com establece ambos.
cycle es obligatorio y acepta HOURLY, MONTHLY, QUARTERLY, SEMI_ANNUALLY o ANNUALLY. Lo que sucede después depende del que elijas:
- Un periodo (
MONTHLYaANNUALLY): el pedido se guarda con una factura y aún no se aprovisiona nada. La respuesta es201; conservadata.order.idydata.invoiceIdpara el paso siguiente. HOURLY: el servidor se aprovisiona dentro de la petición y no se emite factura.data.provisionedItems[0].provisionedIdes el ID del servidor, el{serviceId}de los dos últimos pasos, así que pasa a elegir un sistema operativo. La facturación por hora necesita quebilling.isUsageBasedseatrueen Obtener derechos, algo que una organización nueva no tiene; por ahora se concede previa solicitud mediante soporte en la consola, y sin ello el pedido responde422USAGE_BILLING_DISABLED.
El servidor recibe un IPv4 /30 y un IPv6 /120, ambos incluidos en el precio del plan; IPv6 se omite si el centro de datos no tiene espacio IPv6 disponible. Facturación explica cómo usar un prefijo IPv4 mayor y omitir una familia.
La cabecera Idempotency-Key es opcional. Genera un valor por pedido y vuelve a enviar el mismo si reintentas tras agotar el tiempo de espera, para que el reintento devuelva el primer pedido en lugar de crear otro; Idempotencia contiene las reglas.
Pagar la factura
Un servidor contratado por un periodo se aprovisiona cuando su factura se paga íntegramente y nada paga automáticamente la factura de un pedido. Un pedido que queda sin pagar se cancela en un plazo de 24 horas. Desde un script, Pagar factura la liquida con crédito de cuenta:
curl --request POST \
--url https://api.serverside.com/v1/billing/invoices/{invoiceId}/pay \
--header 'Authorization: Bearer <api-key>' \
--header 'Content-Type: application/json' \
--data '
{
"providerType": "ACCOUNT_CREDIT"
}
'El pago toma el saldo de crédito disponible hasta el importe pendiente y muestra status SUCCEEDED. Un saldo insuficiente deja parte de la factura pendiente y el servidor espera el resto; obtén la factura y lee amountDue, en céntimos. Sin crédito, la llamada responde 422 PAYMENT_FAILED.
providerType STRIPE con el ID de una tarjeta guardada en methodId carga el pago a esa tarjeta. La API solo enumera las tarjetas guardadas en los ajustes de la organización, que requieren una sesión de consola, así que una clave no tiene una llamada para obtener ese ID. Sin methodId, STRIPE inicia un pago que debe confirmar un navegador (Facturación).
Después obtén el pedido aproximadamente cada 20 segundos hasta que su elemento en items muestre status COMPLETED:
curl --request GET \
--url https://api.serverside.com/v1/billing/orders/{orderId} \
--header 'Authorization: Bearer <api-key>'El propio pedido muestra UNPAID hasta que se ha ejecutado el aprovisionamiento y después COMPLETE. El provisionedId del elemento es el ID del nuevo servidor, el {serviceId} que requieren todas las llamadas posteriores. Un elemento que muestre FAILED no se recuperará solo: el pedido también muestra FAILED y soporte necesita el id del pedido para completarlo.
Elegir un sistema operativo
Enumera las imágenes compatibles con el nuevo servidor:
curl --request GET \
--url https://api.serverside.com/v1/baremetal/{serviceId}/deploy/images \
--header 'Authorization: Bearer <api-key>'Cada imagen tiene un id, un name, un slug como ubuntu-24.04, una platform (LINUX o WINDOWS), el defaultUser que crea y los raidVariants que admite.
Desplegarlo
Inicia el despliegue. image acepta el id de la imagen o su slug y sshKeyIds acepta ID de Listar claves SSH.
curl --request POST \
--url https://api.serverside.com/v1/baremetal/{serviceId}/deploy \
--header 'Authorization: Bearer <api-key>' \
--header 'Content-Type: application/json' \
--data '
{
"image": "<image-id>",
"sshKeyIds": [
"<ssh-key-id>"
],
"raidVariant": "RAID1"
}
'Un despliegue Linux necesita una forma de iniciar sesión: una clave SSH, una password o tu propio cloudInit. Uno de Windows necesita una password. username toma por defecto el defaultUser de la imagen; en Linux, username y password se aplican junto con las claves y un usuario indicado ahí recibe sudo sin contraseña. raidVariant toma por defecto NONE y cualquier otro valor debe estar entre los que enumera la imagen.
La respuesta es 201 con la operación en curso, de type DEPLOYMENT. Obtén el estado del servicio para seguirla:
curl --request GET \
--url https://api.serverside.com/v1/baremetal/{serviceId}/status \
--header 'Authorization: Bearer <api-key>'operation contiene el despliegue en curso con su progress y lastProgressMessage, y lastOperation.state muestra COMPLETED o FAILED cuando termina. Un despliegue solo comienza si el state del servicio es ACTIVE; si sigue ejecutándose otra operación, la API responde 409 y el código OPERATION_IN_PROGRESS. Cuando muestre COMPLETED, inicia sesión en la primaryIpv4 que devuelve Obtener servicio bare metal.
Próximos pasos
- Desplegar tu primer servidor: el mismo flujo con una clave SSH, configuración del primer arranque, consultas del resultado y qué leer cuando falla un despliegue.
- Gestionar direcciones IP: direcciones adicionales y DNS inverso para el nuevo servidor.
- Facturación: ciclos de facturación, pedidos, facturas, crédito de cuenta y tarjetas.
- Convenciones de la API: nombres, unidades monetarias, estructuras de éxito y error, paginación, códigos de error, límites de peticiones e idempotencia.