update_portfolioUpdate a portfolio's name, project, members, and/or allocation policy.
Area
Portfolios
Group
Portfolios
Access
Write
Risk
May change server state
Details
Full description
Details
Update a portfolio's name, project, members, and/or allocation.
Members — if provided, each needs strategy_id and may carry an optional weight. With 2+ members, supply a weight for every member (summing to 1.0) or omit weight for an equal split. All members (new or existing) must belong to the portfolio's project — pass project_id to re-scope the portfolio, but every member must already belong to that project.
Allocation — pass allocation to set the policy directly, which OVERRIDES member-weight-derived allocation and is how you enable trailing_return or member_signal_rotation rotation. When allocation is omitted the existing allocation is preserved — unless members is supplied, which re-derives it from the new member weights.
Capabilities
Bounded options and operating modes surfaced above the full JSON schema.
Required Inputs
portfolio_idstringPortfolio identifierOptional Inputs
allocationanyOf (2 variants)Optional portfolio allocation policy (cross-member weighting + rebalance + capital model). When provided it OVERRIDES the member-weight-derived allocation. 'trailing_return' member rotation ranks members by their OWN trailing realized return and holds the top_n, re-ranking on a calendar cadence. Shape: {'construction': {'type': 'trailing_return', 'top_n': 2, 'lookback_bars': 30}, 'rebalance': {'type': 'calendar', 'schedule': 'weekly'}, 'capital_model': 'partitioned'}. 'member_signal_rotation' ranks logic-bearing members by a declared shared_signals value (reduce-only), keeping each held member's own entry/exit logic running, e.g. {'type': 'member_signal_rotation', 'score_signal': 'momentum', 'top_n': 1} — requires a calendar rebalance and a declared 'shared_signals' entry named 'momentum'. 'construction.type' may also be 'equal_weight' or 'manual_weights' ({'type': 'manual_weights', 'weights': {strategy_id: fraction}}), or 'rank_based' with a 'score_signal' (construction-managed rotation — rejects logic-bearing members, unlike 'member_signal_rotation'). 'rank_based' with a raw 'score_ref' / 'signal_proportional' are universe-only and rejected — use 'trailing_return' or 'member_signal_rotation' to rotate members. Optional 'constraints' and 'collection_risk' dicts are accepted; fields the engine does not enforce are rejected fail-closed.membersanyOf (2 variants)New member listnameanyOf (2 variants)New portfolio nameproject_idanyOf (2 variants)Re-scope this portfolio to a different research project. All (new or existing) member strategies must belong to this project — cross-project portfolios are rejected.shared_signalsanyOf (2 variants)Portfolio-level cross-member shared signals. Each entry is {'name': str, 'source': <market ValueRef>}, e.g. {'name':'mom20','source':{'type':'indicator','indicator':'ema','period':20}}. Declared once, then referenced inside member entry/exit conditions via {'type':'shared_signal','name':'mom20'} so a member can gate on its rank / relationship vs sibling members. Source must be a market-derived per-symbol metric (indicator / price / volume); cross-sectional / state / event refs are rejected. Only valid on a 2+ member portfolio. On update_portfolio, omit to preserve the existing shared_signals; pass a list (including []) to replace them.