/services/{id_service}/ endpoint of the SWPanel APIThe SWPanel REST API allows you to automate the complete management of cloud services, hosting, servers and infrastructure through external integrations. Its architecture is designed to facilitate DevOps operations, ERP synchronization, workflow automation and the construction of SaaS platforms or internal tools.
One of the most commonly used endpoints within the API is the service detail retrieval endpoint:
GET /v2026/services/{id_service}/
Official OpenAPI documentation:
https://api.swpanel.com/v2026/redoc?l=EN#tag/SERVICES/paths/~1v2026~1services~1{id_service}~1/get
Official GitHub repository:
https://github.com/swpanel
The combination of OpenAPI documentation and public examples on GitHub makes it possible to greatly accelerate any technical integration with SWPanel.
The endpoint:
GET /v2026/services/{id_service}/
allows you to retrieve all detailed information associated with a specific service using its unique identifier (id_service).
Depending on the type of service, the response may include:
This endpoint acts as the query core for practically any automation based on SWPanel.
id_serviceThe entire SWPanel API architecture is based on unique service identifiers.
The id_service allows you to:
This greatly simplifies the design of complex integrations.
GET /v2026/services/{id_service}/
The API uses Bearer Token authentication.
Required header:
Authorization: Bearer TU_TOKEN
The examples published on GitHub by SW Hosting use this same authentication model:
https://github.com/swpanel
| Parameter | Type | Description |
|---|---|---|
id_service |
integer/string | Unique service identifier |
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"
}
}
The real potential of this endpoint appears when it is combined with the active service listing endpoint:
GET /v2026/services/
This pattern is the foundation of practically any business integration or automated platform.
Common flow:
1. Get the list of services
2. Iterate through each id_service
3. Query individual detail
4. Process information
5. Execute automations
This model allows you to build fully automated platforms on top of SWPanel.
Automatically obtaining active services provides major operational advantages.
It allows automatic synchronization with:
Each service can later be enriched using the detail endpoint.
Many organizations need dashboards adapted to their operations.
For example:
The API allows completely custom dashboards to be generated without depending exclusively on the graphical panel.
This endpoint is especially useful in DevOps environments.
It allows you to:
SWPanel has especially evolved towards advanced automation and API-first operations:
https://swpanel.com/en/changelog
One of the most interesting aspects of the SWPanel ecosystem is the availability of public examples and official repositories on GitHub.
Main repository:
https://github.com/swpanel
Featured repositories:
| Repository | Description |
|---|---|
| Example-Cloud-Purchase | Examples of Cloud Server purchase and modification |
| Example-Login-Swpanel | Automatic login integration |
| Example-Domain-Lookup | Domain lookup through API |
| Example-Domain-Register | Automatic domain registration |
| SW-WHMCS8 | Official WHMCS module |
These examples greatly accelerate real integrations and business automations.
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("Service:", data["service_name"])
print("Status:", 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);
A common scenario may consist of:
1. Query all active services
2. Obtain individual detail
3. Detect incidents
4. Update dashboards
5. Synchronize ERP
6. Generate alerts
7. Automate reporting
8. Execute DevOps workflows
All without manual intervention.
The API follows a clear and consistent REST architecture.
This facilitates:
The structure based on id_service greatly simplifies integration logic.
When data does not change constantly, it is advisable to use cache:
This improves performance and reduces load on the API.
Errors such as the following should always be considered:
| Code | Meaning |
|---|---|
| 401 | Invalid token |
| 403 | Access denied |
| 404 | Service does not exist |
| 429 | Rate limit |
| 500 | Internal error |
Never assume that a service is operational simply because it exists.
For example:
{
"status": "active"
}
Common recommendations:
Allows automatic synchronization of contracted infrastructure.
Resellers can:
Ideal for:
Allows services to be related to:
https://api.swpanel.com/v2026/redoc
https://github.com/swpanel
https://swpanel.com/en/changelog