Common mistakes when using one API for every market with real money

Using a single API for stocks, crypto, perpetual futures, options, and prediction markets removes integration complexity, but it does not remove the differences between those markets. Traders often treat the unified interface as proof that the underlying mechanics are identical, then discover that real money behaves differently once orders hit the wire. The most common mistakes are not in the API client code, but in assumptions about sizing, collateral, latency, and failure modes that the abstraction hides. Real losses happen when an agent treats a prediction market like a stock, or an option like a perpetual future, because the API shape looks the same even though the economics diverge.

Why does one API make sizing feel universal when it is not?

The Felix API normalizes order sizing into plain US dollars, which removes the need to think in contract units, satoshis, or share lots. This convenience is dangerous when traders forget that the dollar amount sent to the API is an input, not a measure of economic exposure. Suppose you send a $1,000 order to a stock broker. The broker buys roughly $1,000 of equity, and your maximum nominal loss is close to $1,000 if the stock goes to zero. Now suppose you send the same $1,000 notional value to a perps venue. If the venue offers 10x leverage, your position controls $10,000 of underlying exposure. A 1% adverse move in the underlying produces a 10% loss on your margin. A 10% move wipes out the position entirely. The API accepted the same number, but the risk profile is an order of magnitude larger. In options, the confusion is even subtler. A $1,000 order might represent premium, which can expire worthless even if the underlying stays flat. Or it might represent notional, which exposes you to assignment and delta risk that behaves nothing like the stock itself. In prediction markets, a $1,000 bet near expiry on a binary outcome can swing from nearly worthless to nearly full value on a single headline. The API accepted the same number in each case, but the path to profit or loss diverged sharply. If you build a single sizing heuristic across all markets, you will eventually allocate too much capital to the most volatile or leveraged instruments. You need to maintain a mapping layer between your strategy's intended dollar risk and the actual exposure each market type creates. That layer lives in your agent logic, not in the API.

How do margin rules differ across market types?

A unified balance view can make your capital look like one pool of spendable dollars, but each market type encumbers funds differently. Stock purchases typically lock cash until settlement, during which time you cannot withdraw that capital even if you sell immediately. The cash is effectively gone from your free balance for one or two days, depending on the broker's settlement cycle. Perpetual futures do not settle in the same way, but they deduct or credit funding payments every few hours. A flat position can still bleed money while you sleep if the funding rate is against you. Options positions tie up margin according to the greeks, and short options can trigger assignment at any moment. An agent that sells a call option might wake up to find it has been assigned and now holds a short stock position it never intended to enter. Prediction markets often lock collateral until the event resolves, and some binary contracts cease trading or shift to wide spreads as the resolution date approaches. If your agent tracks only total account balance, it will overestimate free capital and may double spend collateral that is already trapped. You should model each market type as its own ledger line, tracking not just position value but also settlement timing, funding accrual, and encumbrance rules. A multi-market agent that ignores this will accidentally pyramid risk because it thinks cash is available when it is merely parked. The non-custodial model keeps funds in your wallet, but it does not prevent you from committing those funds to multiple overlapping margin requirements at once.

Why do kill switches need market-specific logic?

Every automated trading system needs a panic switch, but a single flatten command does not translate cleanly across five market types. Imagine your agent hits a drawdown limit and the kill switch fires. A market order to exit a large perps position might execute instantly on a liquid order book, but the same market order on an illiquid options strike can fill at a catastrophic price. The options market might have no bids within 20% of the mark, and a market sell would simply hand your position to a market maker at a huge discount. Prediction markets near expiry can have such wide spreads that a market order is essentially a donation to the other side. Stocks might settle on a delay, so even after you submit a closing order, the cash is not available to halt further decisions. If your kill switch is one generic loop that fires market orders everywhere, you are likely to create the exact loss you are trying to prevent. Instead, an exit plan should specify the close mechanics per market type. For some instruments that means limit orders with patience. For others it means holding to expiry because the exit cost exceeds the expected move. For stocks it means accepting that the cash will be freed on settlement, not immediately. You should design the panic flow as carefully as the entry flow, with each branch aware of the instrument it is handling. The safety controls are only as good as the market logic wired into them.

When does paper trading hide the real problem?

Paper trading is essential for testing API connectivity and strategy logic, but it rarely replicates the cost structures that separate profitable agents from broken ones. Paper environments usually assume zero slippage, ignore funding rates, and let you exit any position at the last traded price. Real perps venues charge funding that can turn a sideways price into a steady loss. Real options markets have bid-ask spreads that widen when volatility spikes, and liquidity can vanish for out of the money strikes. Real prediction markets can run out of liquidity on one side of the book, leaving your exit order unfilled at any reasonable price. An agent that wins in paper mode by trading frequently can be demolished in live trading by fees and friction. Suppose your paper agent makes ten round trips per day and shows a 2% return. In live trading, each round trip might cost 0.1% in spread and fees, plus funding, which turns the 2% return into a loss. The correct use of paper trading is to verify that your code paths work, not to validate expected returns. After paper testing, you should move to live trading with the smallest possible size so you can measure the real fee landscape and fill quality. See how to backtest without fooling yourself for a longer discussion on simulation bias. Paper profits are not evidence of edge. They are debug output.

How should you scope keys and budgets per market?

A single API key can technically reach every market, but good risk hygiene means splitting access by domain. You should create scoped keys that restrict an agent to one market type, or to a subset of market types that share similar liquidity and risk profiles. A key that can trade both stocks and prediction markets gives a buggy agent twice the surface area to cause damage. If a logic error confuses a stock ticker with a prediction market outcome, the agent could deploy capital into the wrong instrument class entirely. Budget caps should also be set per market type, not just per account, because a 5% daily drawdown in a stock portfolio is a different event than a 5% drawdown in a perps account. The former might take a week of gradual selling. The latter might take five minutes during a liquidation cascade. You should also set position limits per market so that an agent cannot convert a small test into an oversized options short by misreading a signal. Scoped API keys let you enforce these boundaries at the infrastructure level rather than hoping your agent prompt behaves. If you run a multi-market portfolio, consider the advice in how to start multi-market management for structuring capital across domains. The goal is to make the API permission layer match your mental model of risk separation.

What does a safe integration actually look like?

The goal is not to avoid the unified API, but to wrap it in market-aware controls before any real money is deployed. You need a translation layer that converts your strategy's intended dollar risk into the correct exposure for each instrument type. You need a monitoring layer that tracks free cash separately from encumbered margin. You need an exit layer that knows whether to flatten aggressively or wait for settlement. You also need to test the live path with minimal capital before scaling, because only real fills reveal the true cost of each venue. The exact request schema is in the docs; the shape looks like this.

{
  "scope": "YOUR_KEY",
  "allowed_markets": ["stocks", "perps"],
  "daily_budget_usd": 1000,
  "max_position_usd": 500,
  "panic_action": "flatten_and_revoke"
}

This illustrative structure shows a key restricted to two market types with a hard daily budget and a kill switch that revokes access after flattening. In practice, you would create separate scopes for each market class, attach per-market drawdown limits, and wire the panic action to a market-specific close handler. The abstraction is helpful only when you respect what lies beneath it. Trading can lose money, including everything you allocate, so the integration layer should be designed to contain failure rather than assume success.