How to backtest AI trading strategies through a single API

Backtesting an AI trading strategy through a single API means running the agent's full decision loop against historical or simulated market data before it handles real capital. The goal is to observe how the agent generates signals, sizes orders in US dollars, and responds to safety boundaries such as budget caps and kill switches. A useful backtest validates not only the strategy logic but also the operational constraints that will govern the agent in production.

Why backtest before allocating live capital?

Backtesting is an operational rehearsal, not just a statistical exercise. The agent must prove it can generate orders, respect scoped keys, and handle errors without human intervention. When an agent trades across multiple market types from one integration, the complexity compounds. A stock signal might trigger an options hedge that then affects a perps position, all within the same API session. Simulation reveals whether the agent's reasoning loop stays coherent when capital is constrained and venues return unexpected responses.

Trading can lose money, including everything. A backtest that ignores fees, latency, or partial fills will paint a misleading picture. The API normalizes order sizing into plain US dollars, which helps compare performance across asset classes, but the developer must still model the friction of real execution. Suppose an agent sends a $500 order into a thin prediction market. In simulation, it may fill instantly at mid price. In live trading, it might walk the book. The backtest should account for this by applying conservative slippage assumptions rather than idealized fills.

Developers should also simulate the non-custodial structure. Funds sit in a wallet the owner controls, and the agent can spend within limits but can never withdraw to itself. During a backtest, the simulation should enforce this by rejecting any request that attempts to move capital to an unapproved address. If the agent logic assumes it can rebalance across venues freely, the test will reveal that assumption is false.

How does paper trading fit into the backtest workflow?

Felix offers paper trading for exactly this purpose. A paper key uses the same REST endpoints and MCP tools as a live key, but it executes against simulated liquidity. This lets the agent experience the full request and response cycle, including rate limits and validation errors, without owner risk. The safety controls remain active. Budget caps, position limits, and exit plans all apply to paper keys, so the agent cannot accidentally generate a thousand phantom orders and exhaust API quota.

Paper trading is not a substitute for historical backtesting on offline data. It is a complement. Historical simulation answers the question, what would this agent have done last year? Paper trading answers, what does this agent do right now when I connect it to the API? Both are necessary. A developer might run a thousand historical episodes to refine a signal, then run the same agent in paper mode for several days to catch integration bugs. How to start an AI agent with a small budget discusses why beginning with minimal capital and full simulation is the safer path.

The transition between the two phases matters. After historical testing, the developer should switch to paper mode without changing the agent's prompt or code. If the agent behaves differently when it detects a test flag, the backtest is worthless. The paper environment should return realistic error messages, including rejected orders when the agent exceeds its scoped budget. This fidelity is what makes paper trading a true dress rehearsal rather than a demo.

What should a historical simulation include?

A useful backtest needs more than a CSV of prices. It needs a faithful representation of the agent's operating environment. At minimum, the simulation should include these components:

• ·Timestamped price feeds for the relevant markets
• ·A model of order entry latency and confirmation delays
• ·Venue-specific fee structures, even if approximate
• ·Slippage assumptions that worsen with order size
• ·The exact safety rules that will be enforced in production

Because the API abstracts contract math across stocks, crypto, perps, options, and prediction markets, the agent reasons in dollars. The backtest should mirror this. If the agent decides to allocate $200 to an option and $200 to a perpetual future, the simulation should track those dollar commitments separately, then convert them into notional exposure based on the leverage or delta of each instrument. Never assume zero fee trading. Even small friction, when compounded across frequent agent decisions, can erase hypothetical edges.

Developers should also simulate the kill switch. At random intervals, or during drawdown thresholds, the simulation should force a full flatten and revoke the key. If the agent cannot recover gracefully from this event, the backtest has revealed a critical bug. How to build a kill switch your trading agent cannot override covers the architecture of these controls.

Margin is another variable. A perpetual futures position might require collateral that changes with volatility. The simulation should model margin calls or liquidation prices, even if simplified, so the agent can test deleveraging logic. If the backtest ignores this, the agent might enter live trading with no concept of how to reduce size when its buying power shrinks.

How do you structure the backtest against the API?

The exact request schema is in the docs; the shape looks like this:

{
  "key": "YOUR_KEY",
  "mode": "paper",
  "action": "submit_order",
  "symbol": "EXAMPLE_MARKET",
  "side": "buy",
  "dollar_amount": 250
}

In a backtest, you replace the live network layer with a local simulator that reads historical data and returns synthetic responses. The agent code remains unchanged. It still calls the same helper functions, still parses the same normalized JSON, and still passes decisions to the safety middleware. The only difference is that the simulator, not a remote venue, provides the fill. This approach catches logic errors in the agent's prompt or code without exposing secrets to the internet.

For MCP-based agents, the pattern is similar. The Claude or Cursor client invokes the same tool definitions, but the tool implementation routes to your local backtest harness instead of the production REST API. The agent does not know it is in simulation. This is important. If the agent behaves differently when it detects a test flag, the backtest is worthless. The harness should return realistic error messages, including rejected orders when the agent exceeds its scoped budget.

What common mistakes break backtests?

Many developers optimize for hypothetical profit and forget to validate risk controls. A backtest that shows positive returns but ignores spend caps is dangerous. The agent may learn to overtrade, and the first live day will hit the cap and halt. Another mistake is using identical slippage for all market types. A $500 order in a large stock behaves differently from the same dollar amount in a prediction market. The simulation must scale its friction assumptions by venue and by time of day.

It is also common to paper trade for too short a window. A few hours of simulation will not capture the fat-tail events that matter. A useful backtest runs across different volatility regimes, including sharp drops and gaps. The agent should face at least one simulated panic where the kill switch fires. If the developer skips this step, they are assuming the safety layer is theoretical rather than tested. Common mistakes with spend caps and drawdown limits for trading agents explains why these boundaries fail in production when they are not exercised in simulation.

Another error is inventing performance numbers. Never quote a win rate, Sharpe ratio, or return figure that came from a backtest as if it were a verified result. These are internal tools for debugging, not marketing material. Presenting hypothetical results as historical fact will mislead both the developer and the owner. Trading can lose money, including everything. The purpose of a backtest is to find failure modes, not to guarantee profits.

When is the agent ready for live authorization?

An agent is ready for live trading only after it has passed three gates. First, it must complete a historical backtest across multiple market conditions without breaching safety rules. Second, it must run in paper mode for a duration long enough to catch integration issues, which typically means at least several days of continuous operation. Third, the owner must explicitly authorize a new scoped key for live trading, with its own budget cap and approved withdrawal addresses.

This authorization step is deliberate. The API requires explicit owner consent to move from paper to live. Even if the agent code is identical, the key itself is different. This prevents a developer from accidentally promoting a test configuration into production. Once live, the same observability and audit logs that applied in paper mode continue to record every decision. If the agent behaves differently with real money at stake, the logs will reveal the divergence.

Trading can lose money, including everything. A clean backtest and a smooth paper run reduce the chance of technical failure, but they do not reduce market risk. The agent is still exposed to price movements, gaps, and unexpected correlations. Developers should treat the first live authorization as a small, capped experiment rather than a full deployment. Scale only after the agent demonstrates disciplined behavior under real conditions.