Why a List of 317 Strategies Is Useless Without the Data Map
Search for a crypto trading strategies API and you get two kinds of result: a list of strategy names with a paragraph each, or a signals vendor selling the output of one strategy it will not describe. Neither helps an agent that has been told "pick a funding-carry strategy and run it". The agent needs the playbook, the conditions it checks, and which endpoint and which field measures each condition.
That third part is the hard one. A playbook says "enter when funding is crowded". The agent has to translate that into a route, a parameter, a response field and a threshold, and it has to do it for every rule on the page. Get one translation wrong and the backtest is testing a different strategy from the one it reports.
This post walks through the two catalogues that do the translation for you: /api/v1/strategies (317 strategies in 22 groups) and /api/v1/indicators/catalog (187 indicators in 12 groups), both carrying an endpoints mapping, plus the per-condition gates on AlgoBrain strategy pages that go one level deeper, to the exact field. All of it is readable with a Free key.
What /api/v1/strategies Returns
The strategy library is compiled from the AlgoBrain wiki, the same source behind the /trading-strategies pages. One call lists every strategy, or one group:
curl "https://cryptodataapi.com/api/v1/strategies?group=funding-carry-basis" \
-H "X-API-Key: cdk_live_your_key"
Each list row carries slug, name, group, summary, timeframe (one of scalp, intraday, day, swing, position, long-term), complexity, indicators as [{slug, name, group}] and endpoints, the API paths that feed it. An unknown group is a 400 unknown_group that includes valid_groups, so an agent can recover without a second lookup. GET /api/v1/strategies/groups lists the 22 groups with a description and strategy_count.
The detail call adds what the list leaves out. This is the real basis-trading record, trimmed:
{
"slug": "basis-trading",
"group": "funding-carry-basis",
"timeframe": "swing",
"complexity": "intermediate",
"edge_source": ["structural", "behavioral", "risk-bearing"],
"data_required": ["spot-price", "futures-price", "perp-mark-price",
"funding-rates", "open-interest", "days-to-expiry", "borrow-rate"],
"indicators": [{"slug": "funding-rate", "name": "Funding Rate", "group": "derivatives-positioning"},
{"slug": "open-interest", "name": "Open Interest", "group": "derivatives-positioning"},
{"slug": "basis", "name": "Basis", "group": "derivatives-positioning"}],
"endpoints": ["/api/v1/derivatives/funding-rates", "/api/v1/hyperliquid/funding-rates",
"/api/v1/derivatives/open-interest", "/api/v1/hyperliquid/open-interest",
"/api/v1/sentiment/macro", "/api/v1/hyperliquid/candles"],
"backtest_status": "cost-corrected",
"wiki_path": "wiki/strategies/algorithmic/basis-trading.md",
"prompts": [{"title": "Build it with an AI agent", "prompt": "..."},
{"title": "Backtest it", "prompt": "..."}]
}
Three fields deserve a warning label. edge is the edge mechanism as the playbook states it, and it is an empty string when the playbook states none. backtest_status is the playbook's own validation label (untested, cost-corrected, live and so on), not a result we measured. And indicators is what the playbook links to or requires, so it is empty for a strategy that declares none. An unknown slug is a 404 strategy_not_found.
The Indicator Catalogue: Definitions, Not Live Values
/api/v1/indicators/catalog is the other half. It lists 187 indicators in 12 groups (derivatives-positioning, volatility, momentum-oscillators, on-chain, market-breadth-regime and the rest), each with summary, aliases and endpoints, the paths that serve the indicator or its raw inputs.
It is a definitions catalogue. The live numbers stay where they always were: /indicators/technical, /indicators/signum-rgg, /indicators/adx, /volatility/* and the other signal routes. The catalogue tells you which of those to call.
The detail call, /api/v1/indicators/catalog/{slug}, adds tags, difficulty, used_by (up to 12 catalogue strategies that use it, so you can walk from an indicator back to strategies), wiki_path and a compute prompt. For funding-rate the endpoints list names /api/v1/derivatives/funding-rates, /api/v1/derivatives/open-interest, /api/v1/market-intelligence/liquidations and /api/v1/derivatives/binance/long-short-ratio, and used_by includes basis-trading, which closes the loop with the example above.
An unknown slug is a 404 indicator_not_found. Like the strategy routes, every indicator route answers any valid key, Free included.
How Does an Agent Resolve Every Strategy Condition to an Endpoint and Field?
The catalogue's endpoints list says which routes feed a strategy. It does not say which field answers which rule. That is what the gates on AlgoBrain strategy pages are for, added on 2026-10-10.
Fetch a page by its wiki_path and read the gates array:
curl "https://cryptodataapi.com/api/v1/algobrain/page?path=wiki/strategies/arbitrage/hyperliquid-hlp-basis-arbitrage.md" \
-H "X-API-Key: cdk_live_your_key"
Each gate is one condition the strategy checks, with a role of universe, entry, filter, exit, stop or sizing. This is a real gate from that page:
{
"id": "funding_divergence_5bp",
"role": "entry",
"rule": "Open paired positions when Hyperliquid funding diverges from Binance funding by more than 5 bp per 8h: short the venue paying more, long the other",
"runnable": true,
"endpoint": "/api/v1/derivatives/funding-rates?coin={coin}",
"field": "hyperliquid.current_rate",
"replay": "/api/v1/backtesting/funding?symbol={coin}&exchange=hyperliquid&grain=hourly&start={start}",
"replay_field": "data[].funding_rate",
"note": "binance.current_rate is in the same response. Hyperliquid's rate is hourly: multiply by 8 before subtracting Binance's 8h rate (the page's pseudocode skips this step). ..."
}
Read it as a contract. runnable: true means one endpoint and one response field measure the rule. replay and replay_field name the history route that reproduces the same field for past dates, which is what a backtest reads instead of the live route. note carries the unit conversion the playbook forgot. Placeholders such as {coin} and {start} are yours to fill; field paths use a.b, a[].b for list items and a.{coin}.b for coin-keyed maps.
The resolution loop for an agent is then mechanical:
- Pick a strategy from
/strategiesand read itswiki_path. - Fetch
/algobrain/page?path=and iterategates. - For each gate with
runnable: true, callendpointlive andreplayfor history, and comparefieldagainst the threshold inrule. - For
runnable: "partial", do the same and surfacenoteto a human: the endpoint measures part of the rule and a judgement remains. - For
runnable: false, stop. Nothing we serve measures it, there is noendpoint, andnotesays what is missing.
Two other shapes appear. input: "position" marks a condition on your own position, such as a time stop, which no market endpoint can answer. input: "derived" with inputs: [gate ids] marks a condition built from other gates on the page, such as a composite score. gates is null on a page that has not been mapped and on every non-strategy page.
Filtering 450 Strategy Pages Down to Ones You Can Run
/api/v1/algobrain/search is the front door to the wider wiki (about 5,000 pages, roughly 450 of them strategies). Its strategy filters are each an any-of match:
| Filter | Values | What it means |
|---|---|---|
backtest_status | untested, naive-backtested, cost-corrected, walk-forward-validated, paper-traded, pilot, live, paused, retired | The author's validation label. cost-corrected|walk-forward-validated|live selects the pages with the most evidence. |
horizon | scalp, intraday, swing, position, long-term | A holding style, not a bar interval. The wiki has no 1h/4h field. |
strategy_type, complexity, crowding_risk, market | e.g. crowding_risk=low, market=crypto | Frontmatter facets. |
runnable | all, partial, none | Gate coverage: all means every gate on the page resolves to an endpoint and field. |
Strategy results carry a strategy block with backtest_status, horizon[], crowding_risk, expected_sharpe, expected_max_drawdown, breakeven_cost_bps and expected_sharpe_source: "author_estimate". Those are the authors' expectations, not results we measured, and search never ranks by them. Since 2026-10-10 the block also carries runnable and gate_counts as {total, runnable, partial, not_runnable}, and /algobrain/stats reports by_runnable for the whole index.
A practical query for a cautious agent:
import httpx
H = {"X-API-Key": "cdk_live_your_key"}
r = httpx.get("https://cryptodataapi.com/api/v1/algobrain/search",
params={"q": "funding", "backtest_status": "cost-corrected,live",
"crowding_risk": "low", "limit": 20}, headers=H).json()
for hit in r["results"]:
s = hit["strategy"]
print(hit["title"], s["runnable"], s["gate_counts"], hit["read"])
Ranking changed on the same date: a page named by the query comes first (match: "exact_title"), then title phrases, then title terms, then body matches. Concept and strategy pages outrank the generated per-coin pages inside each tier. And both /algobrain/search and /algobrain/page now return 400 unknown_parameter for a query parameter they do not read, instead of silently ignoring it.
Catalogue endpoints vs Page Gates: Which Mapping Do You Need?
The two mappings answer different questions, and an agent usually needs both in sequence.
/strategies/{slug} endpoints | /algobrain/page gates | |
|---|---|---|
| Granularity | Routes that feed the strategy | One endpoint + one field per condition |
| Thresholds | None (read the playbook) | In rule, with unit caveats in note |
| History | Not stated | replay / replay_field per gate |
| Honesty about gaps | Lists what exists | runnable: false names what is missing |
| Coverage | All 317 catalogue strategies | Mapped pages only; null elsewhere |
| Tier | Any key | Any key |
When the gates shipped, the 51 Hyperliquid basket pages were mapped first: 659 gates, of which 417 were runnable, 207 partial and 35 not runnable, and no page was fully runnable yet. Mapping has extended across the strategy pages since; /algobrain/stats by_runnable is the live count, and runnable=all on search is the only honest way to find a page an agent can run end to end.
How to Use This in a Bot (and Where It Stops)
Use the catalogue to choose, and the gates to build. Filter /strategies by group and timeframe, confirm the backtest_status label is one you accept, then let the page's gates decide whether the strategy is runnable on this data at all. A runnable: false gate on an entry rule is a stop sign, not a detail to improvise around.
Backtest from replay, not from the live route. The live endpoint answers "now"; the replay route answers "then" with the same field. Most replays land on /backtesting/*, which is Pro Plus and served from an isolated container with its own per-key rate limit, so budget for that before promising a 90-day result.
Do not treat expected_sharpe as a measurement. It is labelled author_estimate for a reason. The same goes for backtest_status: live means the author says it ran live, nothing more.
Where it stops. The catalogue maps strategies to our endpoints, so a rule that needs data we do not serve (an options chain, a vault's NAV history) is marked not runnable rather than approximated. Horizon filters are holding styles, so "4h strategies" is not a query the wiki can answer. And the catalogue is a build artifact of the wiki: when the wiki changes, the index is rebuilt and /algobrain/stats built_at and source_commit move.
If you prefer the agent to discover all of this itself, the MCP server exposes the same search and page tools: claude mcp add --transport http cryptodataapi https://cryptodataapi.com/mcp, with a browser sign-in on the first tool call. The background on why the wiki is organised this way is in 1.5 Million Crypto Trading Strategies, Free.
Frequently asked questions
What does the crypto trading strategies API return?
GET /api/v1/strategies lists 317 strategies in 22 groups, each with slug, name, group, summary, timeframe, complexity, the indicators it uses and the endpoints that feed it. The detail call adds edge, edge_source, markets, data_required, backtest_status, tags, wiki_path and two AI-agent prompts. Any key works, including Free.
Is backtest_status a measured result?
No. It is the playbook author's own validation label (untested, cost-corrected, live and others). expected_sharpe on search results is likewise an author estimate, flagged by expected_sharpe_source, and search never ranks by it.
How do I map a single strategy rule to an endpoint and field?
Read the strategy page with GET /api/v1/algobrain/page?path= and iterate its gates array. A gate with runnable true names one endpoint and one field, plus a replay route and replay_field for history. partial gates leave a human judgement, described in note; false gates mean nothing we serve measures the rule.
How do I find strategies an agent can run end to end?
Call GET /api/v1/algobrain/search with runnable=all. Each strategy result carries strategy.runnable (all, partial, none) and gate_counts, and GET /api/v1/algobrain/stats reports by_runnable for the whole index.
Does the indicator catalogue return live indicator values?
No. GET /api/v1/indicators/catalog is a definitions catalogue of 187 indicators with the endpoints that serve each one. Live values stay on routes such as /indicators/technical, /indicators/signum-rgg, /indicators/adx and /volatility/*.



