Skip to main content
Strategy specs are immutable, versioned records. Once a spec is persisted, it cannot be mutated — a new version is created instead. This guarantees that a backtest run always references an exact, reproducible input.

List strategies

Returns all strategy specs for the tenant, with their latest version.

Response

Propose a strategy

The body is a full StrategySpec. See StrategySpec for the schema.
Proposing a strategy requires the strategy:author scope. Without it the request is rejected with 403.

Server-stamped fields

The server assigns id, version, and tenant_id. If the request body includes any of these, they are silently ignored. See StrategySpec.

Response

Immutability

A strategy spec is write-once. To “edit” a spec, you propose it again with the same name; the server creates a new row with an incremented version. Backtest runs pin a specific spec_id + spec_version, so they always reference the exact spec they were run against.
This means you can safely re-run an old backtest months later and get the same result — the spec it references hasn’t changed.

Validation errors

If the spec fails schema validation, the response is 422 with field-level details: