# Litmus Edge 4.0.x - System: High Availability

## Get HA Role

**GET** `{{edgeUrl}}/dm/v2/ha/role`

Return the high availability role and configuration of this device.

This route is in the Device Management **v2** namespace. The v1 swagger does not describe it, which is why it is easy to miss when auditing `/dm` coverage.

A `200` returns the `LoopedgeHaRole` object: `role`, `enabled`, `primaryConfig`, `backupConfig`, `syncStatus`, `heartbeat`, `heartbeatInterval`, `heartbeatFailureThreshold`, `peerEnabled`, `peerSystemdTarget`, `lastSyncTs`, `lastSyncError`, `lastSyncErrorTs`, `restoreLastError`, `promotedAt`, `promotionReason`, `wasPromoted`, `pendingTargetSwitch`, `tokenAcquiredAt` and `tokenExpiresAt`.

**Reading a 404 here:** a device with no HA role configured answers `404` with the Device Management service's own JSON error body, shown in the saved example. That is how to tell 'no role is set' apart from 'this route does not exist', which would return the web application shell instead.

Unchanged between 4.0.x and 4.3.x.

### Response

**Status**: 200 OK

```json
{"error":{"Msg":"Not found","MsgCode":""}}

```

---

## Set HA Role

**POST** `{{edgeUrl}}/dm/v2/ha/role`

Assign the high availability role for this device. Takes a `SetRoleRequestBody` with `role`, `primaryConfig` and `backupConfig`.

This route is in the Device Management **v2** namespace. The v1 swagger does not describe it, which is why it is easy to miss when auditing `/dm` coverage.

Returns a `LoopedgeHaSetrole` carrying `token` and `sshPubKey`. The peer device needs both to join the pair, so capture them from the response rather than expecting to read them back later.

Setting a role does not start it. Follow with `Enable HA Role`.

Responses: `200`, `400`, `401`, `403`, `404`, `500`.

### Request Body

```json
{
    "role": "primary",
    "primaryConfig": {},
    "backupConfig": {}
}
```

---

## Enable HA Role

**POST** `{{edgeUrl}}/dm/v2/ha/role/enable`

Start high availability using the role already configured. No request body.

This route is in the Device Management **v2** namespace. The v1 swagger does not describe it, which is why it is easy to miss when auditing `/dm` coverage.

Fails if no role has been set, so call `Set HA Role` first.

---

## Disable HA Role

**POST** `{{edgeUrl}}/dm/v2/ha/role/disable`

Stop high availability while keeping the configured role. No request body.

This route is in the Device Management **v2** namespace. The v1 swagger does not describe it, which is why it is easy to miss when auditing `/dm` coverage.

This is the reversible half of teardown: the role survives, so `Enable HA Role` restarts it. Use `Clear HA Role` to remove the configuration entirely.

---

## Clear HA Role

**DELETE** `{{edgeUrl}}/dm/v2/ha/role`

Remove the high availability role and its configuration from this device.

This route is in the Device Management **v2** namespace. The v1 swagger does not describe it, which is why it is easy to miss when auditing `/dm` coverage.

Destructive and not reversible through the API: the pairing token and configuration are gone, and re-forming the pair means calling `Set HA Role` again on both devices. Prefer `Disable HA Role` when you only need to stop it.

---