/services/{id_service}/ de la API de SWPanelLa API REST de SWPanel permite automatizar la gestión completa de servicios cloud, hosting, servidores e infraestructura mediante integraciones externas. Su arquitectura está diseñada para facilitar operaciones DevOps, sincronización con ERPs, automatización de workflows y construcción de plataformas SaaS o herramientas internas.
Uno de los endpoints más utilizados dentro de la API es el endpoint de obtención de detalle de servicio:
GET /v2026/services/{id_service}/
Documentación oficial OpenAPI:
https://api.swpanel.com/v2026/redoc?l=ES#tag/SERVICES/paths/~1v2026~1services~1{id_service}~1/get
Repositorio oficial GitHub:
https://github.com/swpanel
La combinación entre documentación OpenAPI y ejemplos públicos en GitHub permite acelerar enormemente cualquier integración técnica con SWPanel.
El endpoint:
GET /v2026/services/{id_service}/
permite recuperar toda la información detallada asociada a un servicio concreto utilizando su identificador único (id_service).
Dependiendo del tipo de servicio, la respuesta puede incluir:
Este endpoint funciona como núcleo de consulta de prácticamente cualquier automatización basada en SWPanel.
id_serviceToda la arquitectura API de SWPanel se basa en identificadores únicos de servicio.
El id_service permite:
Esto simplifica enormemente el diseño de integraciones complejas.
GET /v2026/services/{id_service}/
La API utiliza autenticación Bearer Token.
Cabecera requerida:
Authorization: Bearer TU_TOKEN
Los ejemplos publicados en GitHub por SW Hosting utilizan este mismo modelo de autenticación:
https://github.com/swpanel
| Parámetro | Tipo | Descripción |
|---|---|---|
id_service |
integer/string | Identificador único del servicio |
curl --request GET
--url https://api.swpanel.com/v2026/services/XX012/ --header 'Authorization: Bearer TU_TOKEN'
{
"ID_service": "CJ878",
"values": {
"name": "ce2022050915002.dnssw.net",
"alias": "Cloud Web 1",
"status": "ready",
"type": {
"id_service_type": "18-CLA1",
"description": "Cloud One",
"group": {
"id_type_group": "CLD",
"description": "Cloud One"
}
},
"service": {
"customize": {
"OS": {
"id": "19-W01",
"name": "Debian - Buster v.10"
},
"specifications": {
"vcores": 4,
"GB": {
"ram": 8,
"hd": 160,
"snapshot": 160000
}
}
},
"ips": [{
"ip": "185.61.126.73"
}]
},
"location": {
"id_dc": "03"
},
"created_at": "01/06/2022"
}
}
El verdadero potencial de este endpoint aparece cuando se combina con el endpoint de listado de servicios activos:
GET /v2026/services/
Este patrón es la base de prácticamente cualquier integración empresarial o plataforma automatizada.
Flujo habitual:
1. Obtener listado de servicios
2. Recorrer cada id_service
3. Consultar detalle individual
4. Procesar información
5. Ejecutar automatizaciones
Este modelo permite construir plataformas completamente automatizadas sobre SWPanel.
La obtención automática de servicios activos aporta enormes ventajas operativas.
Permite sincronizar automáticamente:
Cada servicio puede enriquecerse posteriormente usando el endpoint de detalle.
Muchas organizaciones necesitan cuadros de mando adaptados a sus operaciones.
Por ejemplo:
La API permite generar dashboards completamente personalizados sin depender exclusivamente del panel gráfico.
Este endpoint resulta especialmente útil en entornos DevOps.
Permite:
SWPanel ha evolucionado especialmente hacia automatización avanzada y operaciones API-first:
https://swpanel.com/es/changelog
Uno de los aspectos más interesantes del ecosistema SWPanel es la disponibilidad de ejemplos públicos y repositorios oficiales en GitHub.
Repositorio principal:
https://github.com/swpanel
Repositorios destacados:
| Repositorio | Descripción |
|---|---|
| Example-Cloud-Purchase | Ejemplos de compra y modificación de Cloud Servers |
| Example-Login-Swpanel | Integración de login automático |
| Example-Domain-Lookup | Consulta de dominios mediante API |
| Example-Domain-Register | Registro automático de dominios |
| SW-WHMCS8 | Módulo oficial WHMCS |
Estos ejemplos permiten acelerar enormemente integraciones reales y automatizaciones empresariales.
import requests
TOKEN = "TU_TOKEN"
SERVICE_ID = XX012
url = f"https://api.swpanel.com/v2026/services/{SERVICE_ID}/"
headers = {
"Authorization": f"Bearer {TOKEN}"
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
data = response.json()
print("Servicio:", data["service_name"])
print("Estado:", data["status"])
print("CPU:", data["resources"]["cpu"])
else:
print("Error:", response.status_code)
<?php
$token = "TU_TOKEN";
$id_service = XX012;
$curl = curl_init();
curl_setopt_array($curl, [
CURLOPT_URL => "https://api.swpanel.com/v2026/services/$id_service/",
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
"Authorization: Bearer $token"
],
]);
$response = curl_exec($curl);
curl_close($curl);
$data = json_decode($response, true);
print_r($data);
Un escenario habitual puede consistir en:
1. Consultar todos los servicios activos
2. Obtener detalle individual
3. Detectar incidencias
4. Actualizar dashboards
5. Sincronizar ERP
6. Generar alertas
7. Automatizar reporting
8. Ejecutar workflows DevOps
Todo ello sin intervención manual.
La API sigue una arquitectura REST clara y consistente.
Esto facilita:
La estructura basada en id_service simplifica enormemente la lógica de integración.
Cuando los datos no cambian constantemente es recomendable usar cache:
Esto mejora rendimiento y reduce carga sobre la API.
Siempre deben contemplarse errores como:
| Código | Significado |
|---|---|
| 401 | Token inválido |
| 403 | Acceso denegado |
| 404 | Servicio inexistente |
| 429 | Rate limit |
| 500 | Error interno |
Nunca asumir que un servicio está operativo únicamente porque exista.
Por ejemplo:
{
"status": "active"
}
Recomendaciones habituales:
Permite sincronizar automáticamente infraestructura contratada.
Los revendedores pueden:
Ideal para:
Permite relacionar servicios con:
https://api.swpanel.com/v2026/redoc
https://github.com/swpanel
https://swpanel.com/es/changelog