---
title: "Regime-Aware Strategy Performance (per-asset)"
method: GET
path: "/api/v1/strategy/performance-by-regime"
tags: ["Insights"]
---

# Regime-Aware Strategy Performance (per-asset)

`GET /api/v1/strategy/performance-by-regime`

## Request

- Base URL: `https://tradingstrategies.work`
- URL: `https://tradingstrategies.work/api/v1/strategy/performance-by-regime`
- Auth: HTTP bearer

Backtest performance for ONE (strategy, asset, interval) SPLIT BY macro regime (sweet_spot / late_cycle_warning / crisis / recovery — classified at each trade's entry date via the macro-regime composite), PLUS the CURRENT live regime for self-alignment. Answers 'WHEN has this strategy worked?' — deliberately no recommendation field: the former verdict was removed (2026-08-15) because it ranked regimes on the pooled trade sum and could flip when another user's backtest changed the pool. Each regime bucket has trades, trades_per_config (trade counts POOL all parameter-variant configs — see top-level config_count), win_rate, avg_pnl_pct (PER-TRADE return, not annualized), reward_risk_ratio (per-trade mean/stddev — honest, NOT annualized Sharpe), share_of_time_pct (calendar-day-weighted share of the period spent in that regime — each regime observation counts the days until the next one, so the mixed weekly/daily cadence of the regime history does not skew the share), rating. A `benchmark` block anchors the payload with the buy-and-hold CAGR of the same combination (identical numbers as /api/v1/strategy/performance vs_buy_hold — regime avg_pnl_pct without this anchor is a trajectory, not an excess). Aggregated across all parameter variants; filter-neutral (see /api/v1/strategy/filter-effect for filter impact). [Free tier]

## Query parameters

- `strategy` string, required
- `asset` string, required
- `interval` '1d' | '2d' | '3d' | '1w' | '1M'
- `asset_type` 'crypto' | 'tokenized_equity' | 'tokenized_etf' | 'commodities'

## Response `200`

Regime-aware performance breakdown + current live regime (descriptive, no recommendation).

## Other responses

- `400`: Invalid input — fehlt Pflichtfeld oder Wert außerhalb des erlaubten Bereichs.
- `401`: Unauthenticated — kein gültiger Bearer-Token im Authorization-Header.
- `403`: Tier-Insufficient — Endpoint braucht höheren API-Tier. Response enthält upgrade_url.
- `404`: Not-Found — Resource existiert nicht oder gehört nicht dem aktuellen User.
- `429`: Rate-Limit überschritten — Tier-Quota (hourly/daily) oder Per-Endpoint-Quota erreicht. Retry-After-Header gesetzt.
- `500`: Internal Error.
- `503`: Upstream-Failure — Datenquelle nicht erreichbar (Binance, EODHD, etc.).

---

[API](https://skmtc.dev/tradingstrategies/apis/backtesting-arena-public-api.md) · [All operations](https://skmtc.dev/tradingstrategies/apis/backtesting-arena-public-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tradingstrategies/apis/backtesting-arena-public-api/revisions/f82e8d6eecd7?raw)