diff --git a/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md b/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md
index 32e8267053..8fd4c07332 100644
--- a/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md
+++ b/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md
@@ -369,6 +369,42 @@ curl --request POST 'http://localhost:9600/actuator/cluster/brokers?dryRun=true'
 -d '["0", "1", "2", "3"]'
 ```
 
+##### Replication Factor
+
+The replication factor for all partitions can be changed with the `replicationFactor` request parameter. If not specified, the replication factor remains unchanged.
+
+The new replicas will be assigned to the brokers based on the round robin partition distribution strategy.
+
+```
+curl --request POST 'http://localhost:9600/actuator/cluster/brokers?replicationFactor=4' \
+-H 'Content-Type: application/json' \
+-d '["0", "1", "2", "3"]'
+```
+
+##### Force remove brokers
+
+:::caution
+This is a dangerous operation and must be used with caution. When not used correctly, split-brain scenarios or unhealthy, unrecoverable clusters may result.
+:::
+
+Usually, changes can only be made to a cluster when all brokers are up. When some brokers are unreachable, you may want to remove them from the cluster. You can force remove a set of brokers by setting the request parameter `force` to `true`.
+
+This operation is mainly useful for [dual-region setups](/self-managed//concepts/multi-region/dual-region.md), and additional information can be found in the [dual-region operational procedure](/self-managed/operational-guides/multi-region/dual-region-ops.md/). Any deviations from the described process can result in the cluster being unusable.
+
+:::note
+Do not send more than one force request at a time.
+:::
+
+The following request force removes all brokers that are _not_ provided in the request body:
+
+```
+curl --request POST 'http://localhost:9600/actuator/cluster/brokers?force=true' \
+-H 'Content-Type: application/json' \
+-d '["0", "1", "2"]'
+```
+
+This operation does not re-distribute the partitions that were in the removed brokers. As a result, the resulting cluster will have a reduced number of replicas for the affected partitions.
+
 #### Response
 
 The response is a JSON object. See detailed specs [here](https://github.com/camunda/camunda/blob/main/dist/src/main/resources/api/cluster/cluster-api.yaml):
diff --git a/docs/self-managed/zeebe-deployment/operations/management-api.md b/docs/self-managed/zeebe-deployment/operations/management-api.md
index 6c4e083beb..66a4994971 100644
--- a/docs/self-managed/zeebe-deployment/operations/management-api.md
+++ b/docs/self-managed/zeebe-deployment/operations/management-api.md
@@ -15,6 +15,7 @@ The following operations are currently available:
 
 - [Rebalancing](/self-managed/zeebe-deployment/operations/rebalancing.md)
 - [Pause and resume exporting](#exporting-api)
+- [Enable and disable exporter](#exporters-api)
 
 ## Exporting API
 
@@ -61,3 +62,69 @@ When all partitions soft pause exporting, a successful response is received. If
 
 </TabItem>
 </Tabs>
+
+## Exporters API
+
+The Exporters API is used for [dual region deployment](/self-managed/operational-guides/multi-region/dual-region-ops.md/) operations, and allows for enabling and disabling configured exporters. By default, all configured exporters are enabled.
+
+When **enabled**, records are exported to the exporter. The log is compacted only after the records are exported. When **disabled**, records are _not_ exported to the exporter, and the log will be compacted.
+
+The OpenAPI spec for this API can be found [here](https://github.com/camunda/camunda/blob/main/dist/src/main/resources/api/cluster/exporter-api.yaml).
+
+<Tabs groupId="exporters" defaultValue="enable" queryString values={[{label: 'Enable an exporter', value: 'enable' },{label: 'Disable an exporter', value: 'disable' }, {label: 'Monitor', value: 'monitor'}]} >
+
+<TabItem value="enable">
+
+When enabling an exporter, the exporter must be already configured in the cluster. To initialize an exporter's state, an existing exporter's ID can be provided in the optional `initializeFrom` field. Both exporters must be of the same type.
+
+To enable a previously disabled exporter, send the following request to the gateway's management API:
+
+```
+POST actuator/exporters/{exporterId}/enable
+{
+    initializeFrom: {anotherExporterId}
+}
+```
+
+New records written after the exporter is enabled will be exported to this exporter.
+
+</TabItem>
+
+<TabItem value="disable">
+
+To disable an exporter, send the following request to the gateway's management API:
+
+```
+POST actuator/exporters/{exporterId}/disable
+```
+
+After disabling the exporter, no records will be exported to this exporter. Other exporters continue exporting.
+
+</TabItem>
+
+<TabItem value="monitor">
+
+Both enable and disable requests are processed asynchronously. To monitor the status of the exporters, send the following request to the gateway's management API:
+
+```
+GET actuator/exporters/
+```
+
+The response is a JSON object that lists all configured exporters with their status:
+
+```json
+[
+  {
+    "exporterId": "elasticsearch0",
+    "status": "ENABLED"
+  },
+  {
+    "exporterId": "elasticsearch1",
+    "status": "DISABLED"
+  }
+]
+```
+
+</TabItem>
+
+</Tabs>