---
title: "GET | List device connection status"
slug: "api-v2-get-device-connection-status"
updated: 2026-11-03T14:47:51Z
published: 2026-11-03T14:47:51Z
canonical: "docs.senhasegura.io/api-v2-get-device-connection-status"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GET | List device connection status

## Description

Access the result of the most recent connectivity test for each protocol configured on a device registered in PAM Core, using the v2 API. The response reports one result per protocol, including when the test ran and why it failed.

Info

This endpoint belongs to the A2A API v2 surface and is available from Segura™ version 4.2.9. Devices are served from the `/api/v2/platform` base path, not from `/api/v2/pam` like other v2 resources. There is no v1 equivalent: in v1, connectivity results were only available per protocol inside the device response.

---

## Prerequisites

- Authorization with **read** permission to PAM Core granted by the administrator in A2A. For more information, access [How to manage authorizations in A2A](/v4-2/docs/api-v2-how-to-manage-authorizations-in-a2a).
- An existing device with at least one connectivity protocol configured. To configure connectivities, access [POST | Create device](/v4-2/docs/api-v2-post-create-device) or [PATCH | Update device](/v4-2/docs/api-v2-patch-update-device).

---

## Request

`GET` `/api/v2/platform/devices/{id}/connection-status`

### Path parameters

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | integer | Yes | Unique identification code of the device. **Note:** this value is assigned by Segura™ in [POST \| Create device](/v4-2/docs/api-v2-post-create-device), which returns it as a string in the response body. |

---

### Example request

`GET` `{{url}}/api/v2/platform/devices/55/connection-status`

---

## Response

```
HTTP/1.1 200 OK
```

The response carries an `X-Request-Id` header, which correlates the request across Segura™ logs.

### Example response body

```
{
    "data": {
        "id": "55",
        "results": [
            {
                "protocol": "SSH",
                "port": 22,
                "connectable": true,
                "tested_at": "2026-06-22T10:00:00-03:00",
                "message": null
            },
            {
                "protocol": "RDP",
                "port": 3389,
                "connectable": false,
                "tested_at": "2026-06-22T09:55:00-03:00",
                "message": "Connection refused"
            }
        ]
    },
    "meta": {
        "links": {
            "self": "/api/v2/platform/devices/55/connection-status"
        }
    }
}
```

---

## Response body fields

| Field | Type | Description |
| --- | --- | --- |
| `data` | object | Connection status of the device. |
| `data.id` | string | Unique identification code of the device. |
| `data.results` | array of objects | Most recent connectivity test result for each protocol configured on the device. |
| `data.results[].protocol` | string | Connectivity protocol tested. Possible values: `SSH`, `RDP`, `HTTPS`, `VNC`, `Telnet`, `SQL_Server`. |
| `data.results[].port` | integer | Port used by the protocol. Returns `null` when no port is recorded for the test. |
| `data.results[].connectable` | boolean | Indicates whether the device answered on this protocol in the most recent test. |
| `data.results[].tested_at` | string | Date and time when the test ran, in ISO 8601 format. Example: `2026-06-22T10:00:00-03:00`. Returns `null` when the protocol has never been tested. |
| `data.results[].message` | string | Reason reported when the test failed. Example: `Connection refused`. Returns `null` when the test succeeded. |
| `meta` | object | Navigation links. |
| `meta.links` | object | Navigation links for the request. |
| `meta.links.self` | string | URL of the current request. |

Info

This endpoint reports the result of the last test that ran; it doesn't start a new one. The same `connectable` value is also available per protocol in `device.connectivities[].connectable` in [GET | List a device](/v4-2/docs/api-v2-get-list-a-device), without the timestamp and failure message.

---

## Errors

| HTTP code | Message | Possible cause | Solution |
| --- | --- | --- | --- |
| `401` | `api.auth.token.invalid` | The access token is missing or has expired. | Request a new access token. |
| `403` | `api.permission.denied` | The authorization doesn't have read permission to PAM Core resources. | Ask the administrator to check the authorization permissions in A2A, then generate a new token. |
| `404` | `api.resource.not_found` | The device doesn't exist, or it belongs to another tenant. | Check the `id`. For the `403` versus `404` policy, access [API v2 — Conventions and shared behaviors](/v4-2/docs/api-v2-conventions-and-shared-behaviors). |
| `500` | `api.internal.error` | Internal server error. | Contact the Segura™ support team. |

### Example error response

`404` the device doesn't exist or is outside the authorization scope:

```
{
    "error": {
        "code": "api.resource.not_found",
        "message": "The requested resource does not exist or is not accessible."
    }
}
```

### Authentication errors

| Message | Possible cause | Solution |
| --- | --- | --- |
| `Client authentication failed.` | Application authentication failure with the Segura™ server. | Check the authentication parameters (`Access Token URL`, `Client ID`, and `Client secret`) and request a new access token. |
| `Invalid signature` | Failure in recognizing the client application URL. | Check the URL of the client application and resend the request. |
| `No route matched with those values.` | Missing authorization header in the API request. | Request a new access token. |
| `Request timed out.` | The request exceeded the timeout limit. | Check the connectivity between the source of the request and the Segura™ server. |