End-to-end workflow with Mangrove SIEVE
This guide walks the shortlist-screening chain: you build a fixed set of candidate strategies, cheaply screen them with SIEVE, bulk-backtest the survivors, and register the winner.This is not a parameter sweep. Here you generate a fixed candidate list and SIEVE screens it. If instead you want the engine to generate and search a parameter space for you, that’s the Experiments / sweep API — a different tool. Screening a list ≠ searching a space.
Each phase corresponds to one or two SDK calls. The Python tabs use the
mangroveai SDK 1.4.0+; the cURL tabs hit the underlying /api/v1/* surface directly.
Tier note. This walkthrough uses two endpoints, each capped at 99 items per call:
sieve_score (the screen) and backtest/bulk (the backtest). Keep your candidate list ≤99 and it’s one call of each. (That 99 is a per-call batch size for these two endpoints — it is unrelated to sweep-experiment sizing, which is governed by your tier’s max_backtests_per_sweep.)Prerequisites
- A MangroveAI API key (
prod_…). See Authentication. - The
mangroveaiPython SDK 1.4.0+ (pip install -U mangroveai).
Phase 1 — Discover the signal catalog
The Oracle catalog ships 223 signals across five categories (momentum, trend, volume, volatility, patterns). Each signal carries a type (TRIGGER or FILTER) and a requires list naming the OHLCV columns it consumes.
list_signals() returns a list of plain dicts (one per signal) — keyed by "name", "type", "params", "requires", "category", "description".
Phase 2 — Generate candidates + SIEVE filter
Build N parameter combinations of the chosen signal mix (≤99), then score them in one round-trip through SIEVE. Use the binary head to drop candidates that won’t fire (p_no_trades high), then the 4-class head to rank the survivors by P(winning). Treat both as a cheap screen that orders what’s worth backtesting — not a verdict. Only the backtest in Phase 3 decides whether a strategy is actually good.
Python
sieve_score takes a SieveScoreRequest object, not a bare strategies= keyword):
Python
Phase 3 — Bulk-backtest the top survivors
The cleanest endpoint for “backtest these specific N candidates with the same date range and risk config” isPOST /api/v1/oracle/backtest/bulk. One HTTP call, shared OHLCV fetches across the batch, results in a single response.
This guide uses raw HTTP (Python
requests) for the bulk-backtest step. The mangroveai SDK 1.4.0 typed wrapper currently marks the 17 required risk-mgmt fields as Optional (None default), but the server requires every one explicitly — see the warning callout on Oracle backtest for the SDK ↔ server contract gap. Until the SDK Optional typing is reconciled, raw HTTP is the cleanest pattern.strategy_configs entry, fetch canonical execution defaults, then issue one bulk call:
Python
Python
trade_count == 0, the surviving candidates didn’t fire entries in this window — widen the parameter ranges in Phase 2 and re-rank. SIEVE’s p_no_trades is the cheaper place to catch that.
For the full request/response shape see Oracle backtest reference. If instead of backtesting a fixed shortlist you want the engine to search a parameter space for you, that’s the Experiments / sweep API — a different workflow, not a scaled-up version of this one.
Phase 4 — Register the winner + run it
The winning candidate becomes a registered MangroveAI strategy. From there, you choose how to run it.Python
Running it
client.strategies.update_status(strategy_id, status) transitions the strategy. Pick the path that matches your appetite:
Python
Live trading gating
Goinglive is gated server-side on a wallet with a confirmed backup, an allocation block (wallet_address, token, amount, slippage_pct), and an explicit confirmation flag — none of which are exposed by strategies.update_status(strategy_id, status) in SDK 1.4.0. The live transition currently requires a raw PATCH against /api/v1/strategies/{id}/status with the allocation block in the body. See Creating a strategy for the live contract and wallet-connect gating. Paper trading has no such gating and can run anywhere.
Saving the provenance
Every SIEVE response carriesmodel_version and code_version; experiment results carry their own provenance stamps. Log them next to every decision so a future you can tell which model + corpus snapshot drove the call.
Python
See also
- Filtering Strategies with Mangrove SIEVE — deeper dive on the SIEVE prefilter step in isolation
- Oracle backtest reference — full request/response shapes for the single-strategy backtest endpoints + data corpus query
- Experiments — the parameter-search sweep API (a separate workflow; Phase 3 here uses bulk-backtest, not a sweep)
- SIEVE API reference — endpoint details for
sieve/score - Creating a strategy — strategy-object shape, status transitions, and the wallet/allocation gating for
live mangroveaiPython SDK