POST | Deactivate device

Description

Deactivate a device registered in PAM Core using the v2 API. A deactivated device stops accepting write operations and actions, and remains readable with active set to false.

Alert

Deactivating a device also deactivates every active credential linked to it, and the response reports how many were affected in affected_credentials. Reactivating the device with POST | Activate device does not bring those credentials back: reactivating them is the integrator's responsibility. Check the credentials linked to a device before deactivating it, since automations that depend on them will stop working.

Prerequisites

Authorization with write permission to PAM Core granted by the administrator in A2A. For more information, access How to manage authorizations in A2A.
An active device. Deactivating a device that is already inactive returns 409.
No session for the device active on the proxy. An active session blocks deactivation and returns 409.

Request

POST /api/v2/platform/devices/{id}/deactivate

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. In v1, a device was disabled through DELETE | Disable device; in v2 this action replaces it, and the v2 API implements no DELETE method for devices.

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.

This action takes no request body, and it doesn't require the If-Match header that PUT | Update device and PATCH | Update device require.

An active proxy session blocks deactivation. A credential under custody, meaning an active checkout, does not block it: custody remains the responsibility of the integrator that performed the checkout.

Example request

POST {{url}}/api/v2/platform/devices/55/deactivate

Response

HTTP/1.1 200 OK

Unlike POST | Activate device, which returns 204, this action returns a body so that the caller can see the impact of the cascade.

Example response body

{
    "data": {
        "affected_credentials": 12
    },
    "meta": {
        "links": {
            "self": "/api/v2/platform/devices/55/deactivate"
        }
    }
}

Response body fields

Field	Type	Description
`data`	object	Result of the deactivation.
`data.affected_credentials`	integer	Number of active credentials that were deactivated as a result of deactivating the device. Returns `0` when the device had no active linked credentials.
`meta`	object	Navigation links.
`meta.links`	object	Navigation links for the request.
`meta.links.self`	string	URL of the current request.

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 write 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 identification code sent in the path.
`409`	`api.resource.conflict.active_sessions`	A session for the device is active on the proxy.	Wait for the session to end, or terminate it, then resend the request.
`409`	`api.resource.conflict.already_inactive`	The device is already inactive.	No action is needed, the device is already in the requested state.
`429`	`rate_limit_exceeded`	The request rate limit was exceeded.	Wait the number of seconds given in the `Retry-After` header, then retry.
`500`	`api.internal.error`	Internal server error.	Contact the Segura® support team.

Example error response

409 a session for the device is active on the proxy:

{
    "error": {
        "code": "api.resource.conflict.active_sessions",
        "message": "Cannot modify or deactivate device while active sessions exist on the proxy."
    }
}

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.