create_portfolioCreate a portfolio that runs multiple whole strategies together under one allocation policy.
Area
Portfolios
Group
Portfolios
Access
Write
Risk
May change server state
Details
Full description
Details
Create a portfolio composed of member strategies. Use when a project has 2+ validated strategies you want to run together as one allocated book — a portfolio holds whole strategies and applies a cross-strategy allocation / rotation policy.
To combine conditions within a single strategy, use builder_compose instead — that is a different level.
Members — each needs strategy_id and may carry an optional weight (0 < x <= 1.0). With 2+ members, supply a weight for every member (summing to 1.0) for explicit allocation, or omit weight on all for an equal split. A single member carries no allocation. All members must belong to project_id — cross-project portfolios are rejected.
Allocation — pass allocation to set a policy directly, which OVERRIDES member-weight-derived allocation. Supports trailing_return rotation (rank members by their own trailing realized return, hold the top_n, re-rank on a calendar cadence) and member_signal_rotation (rank logic-bearing members by a declared shared_signals value, reduce-only, holding the top_n while member logic keeps running).
Returns the created portfolio_id and full portfolio details.
Capabilities
Bounded options and operating modes surfaced above the full JSON schema.
Required Inputs
membersarray<object>Member listnamestringHuman-readable portfolio nameproject_idstringResearch project this portfolio belongs to. Every member strategy must already belong to this same project — a portfolio cannot span multiple research projects.Optional 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.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.