--- title: "POST | Deactivate device" slug: "api-v2-post-deactivate-device" updated: 2026-11-03T14:47:51Z published: 2026-11-03T14:47:51Z canonical: "docs.senhasegura.io/api-v2-post-deactivate-device" --- > ## 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. # 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](/v4-2/docs/api-v2-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](/v4-2/docs/api-v2-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](/v4-2/docs/api-del-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](/v4-2/docs/api-v2-post-create-device). | This action takes no request body, and it doesn't require the `If-Match` header that [PUT | Update device](/v4-2/docs/api-v2-put-update-device) and [PATCH | Update device](/v4-2/docs/api-v2-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](/v4-2/docs/api-v2-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. | --- ## Related documents - [POST | Activate device](/v4-2/docs/api-v2-post-activate-device) - [GET | List a device](/v4-2/docs/api-v2-get-list-a-device) - [API v2 — Conventions and shared behaviors](/v4-2/docs/api-v2-conventions-and-shared-behaviors) - [How to manage authorizations in A2A](/v4-2/docs/api-v2-how-to-manage-authorizations-in-a2a)