---
title: "Rebalance"
method: POST
path: "/strategies/{strategy_id}/rebalance"
tags: ["Trade Strategy"]
---

# Rebalance

`POST /strategies/{strategy_id}/rebalance`

Re-aligns Traders to the supplied allocations. Asynchronous. If `participants` is omitted, every Trader with `auto_rebalance: true` is targeted; if provided, only those Traders are targeted (ignoring their `auto_rebalance` flag). A weight of `"0"` means "fully exit this asset"; assets the Trader currently holds that are missing from the list are also fully exited.

## Path parameters

- `strategy_id` string, uuid, required

## Headers

- `X-SCX-SIGNED` string, required
- `X-SCX-TIMESTAMP` string, required

## Request body

- CreateTradeStrategyRebalanceBody
  - `allocations` object[], required — New target weights. A weight of `"0"` means "fully exit this asset"; assets the Trader currently holds that are missing from this list are also fully exited.
    - `underlying_currency` string, required — Underlying asset code (e.g., BTC, ETH).
    - `weight` string, required — Target weight in the allocation. Decimal string in [0, 1]. Weights across an allocation set must sum to exactly 1.0; a "0" weight in Rebalance means "fully exit this asset".
  - `participants` object[] — Optional. If present, the Rebalance targets exactly these Traders (ignoring `auto_rebalance`). If omitted, the Rebalance targets every Trader with `auto_rebalance: true`.
    - `participant_code` string, required

## Response `202`

Operation accepted and queued for processing. Body is the Operation in its initial `validating` status. Poll `GET /strategies/operations/{operation_id}` or subscribe to webhooks to observe the terminal status. On idempotent re-submission the existing Operation is returned and the status code may be `200` instead.

- TradeStrategyOperationResponse
  - `message` object
    - `id` string, uuid — Unique identifier (UUID v4) for the Operation.
    - `strategy_id` string, uuid — Strategy the Operation runs under.
    - `request_id` string, uuid — Platform's idempotency key for this Operation (the `X-REQUEST-ID` sent at submission).
    - `type` 'enrollment' | 'top_up' | 'partial_sell' | 'rebalance' | 'liquidation' — Operation kind.
    - `status` 'validating' | 'pricing' | 'settling' | 'settled' | 'skipped' | 'failed' — Lifecycle status. `validating` / `pricing` / `settling` are non-terminal; `settled` / `skipped` / `failed` are terminal.
    - `status_reason` string — Set on terminal statuses to explain the outcome. Possible values: `no_executions`, `all_skipped`, `all_rejected`, `partial_success`. Empty on non-terminal and on clean `settled`.
    - `allocations` object[] — Target weights for this Operation. Present for enrollment / top_up / partial_sell / rebalance; empty for liquidation.
      - `underlying_currency` string, required — Underlying asset code (e.g., BTC, ETH).
      - `weight` string, required — Target weight in the allocation. Decimal string in [0, 1]. Weights across an allocation set must sum to exactly 1.0; a "0" weight in Rebalance means "fully exit this asset".
    - `created_at` string, date-time — When the Operation was created.
    - `updated_at` string, date-time — When the Operation was last updated.

## Other responses

- `400` — Bad Request
- `403` — Forbidden
- `404` — Strategy not found.
- `500` — Internal Server Error
- `503` — Service Unavailable

---

[API](https://skmtc.net/zerohash/apis/zerohash-api.md) · [All operations](https://skmtc.net/zerohash/apis/zerohash-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/zerohash/zerohash-api/revisions/8b647d934363/schema)