### Disconnect a session

`POST /api/v1/admin/sessions/{id}/disconnect`

Sends an RFC 5176 Disconnect-Request straight from this platform to the NAS that owns the session. The packet goes out over UDP to the device, not through the RADIUS server.

- Authentication: manager session (JWT) or API token
- Permission: `prm_users_live_traffic` (Live traffic / disconnect)
- Risk: write
- Rate limit bucket: `t_mutate`

#### Parameters

| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `id` | path | integer | yes | Session id. |

#### Response — 200 OK

```json
{
  "data": { "ok": true, "nak": false, "message": "disconnected" }
}
```

#### Errors

| Code | Status | When |
| --- | --- | --- |
| `ERR_NOT_FOUND` | 404 | no such session, or one outside the caller's subtree |
| `ERR_INTERNAL` | 502 | the NAS did not answer, or the exchange failed. details.reason carries the transport error |
| `ERR_INTERNAL` | 503 | no CoA dispatcher is wired in this deployment |

#### Note

ok true means the NAS ACCEPTED the packet, not that the subscriber is off the network. Whether the session actually ends is up to the device, and it will be reflected in accounting a moment later. nak true is also a success from your point of view: the NAS replied "no such session", so it is already gone. Only a 502 means the disconnect did not happen.

