How to build a multi-market trading agent with one API

Felix exposes one API and one key that lets an agent trade stocks, crypto, perpetual futures, options, and prediction markets. The integration layer normalizes venue-specific contract math, order sizing, and safety controls so the developer writes logic once instead of maintaining separate integrations for each asset class. Funds remain in a wallet the owner controls because the agent receives scoped spending authority, not custody. This guide explains how to connect an agent, scope its permissions, and keep funds safe across every supported market.

What does one API for every market actually mean?

Traditionally, a developer who wants to trade across asset classes must integrate separate APIs for a stock broker, a crypto exchange, a perps venue, an options venue, and a prediction market. Each integration has its own authentication format, order schema, contract sizing, margin notation, and error handling. The surface area grows quickly, and the agent must carry logic to translate between them. A bug in one translation layer can cause an order to be sized incorrectly or sent to the wrong venue. Felix replaces that stack with a single endpoint and a single key. The agent sends orders in a common format, and the system handles routing, sizing, and settlement differences. This means the same agent code can buy shares, open a perp, or place a prediction market position without knowing which venue will fill it. The abstraction removes venue-specific contract math from the agent's reasoning loop, which reduces the chance of errors caused by mismatched lot sizes, tick sizes, or margin notation. The developer no longer needs to maintain client libraries for five different ecosystems. If you want to see how this pattern fits into a full agent architecture, read our guide on how to build an LLM-powered trading agent with one API.

Error handling also benefits from the unified layer. When a venue rejects an order for insufficient margin, a rate limit, or a stale price, the API translates that into a standard error code. The agent can catch the exception and decide whether to retry, resize, or abort, without needing venue-specific error dictionaries.

How does non-custodial access work in practice?

Non-custodial here means the owner keeps the funds in a wallet they control. The agent never receives a withdrawal key. Instead, the owner creates a scoped key that authorizes the agent to spend within limits. The agent can place orders, open positions, and manage exposure, but it cannot send funds to itself or to any address the owner has not pre-approved. Withdrawal addresses are owner-approved only. This structure matters because it removes the single greatest risk of automated trading: an agent that is compromised, prompted incorrectly, or simply buggy cannot drain the account. It can only lose what the owner has explicitly budgeted. Even if the agent's server is breached, the attacker gains the ability to trade within a capped budget, not the ability to steal the underlying capital. For a deeper look at the key model, see how scoped API keys let an agent trade without taking custody.

How do safety controls limit agent behavior?

Scoped keys are the first layer of defense, but they are not the only one. Felix adds several controls that constrain what the agent can do, how much it can lose, and how it can exit. These limits are set by the owner before the agent starts, and they are enforced by the infrastructure, not by the agent's own logic. That distinction is important. An agent cannot talk itself into raising its own cap because the cap lives outside the agent. The owner configures the budget, the position limits, and the exit rules through a separate interface, and the API rejects any request that violates them. This external enforcement is what makes the system autonomous but bounded. The agent has freedom inside the fence, but it cannot remove the fence.

• ·Budget caps set a maximum dollar amount the agent can deploy across all positions at any given time.
• ·Position limits restrict the size of any single trade or the total exposure in one market, such as a perps venue or an options venue.
• ·Exit plans define conditions under which the agent must close a position, such as a target level or a stop level, and the system can enforce these automatically.
• ·A panic or kill switch flattens all positions and revokes the key instantly, stopping all activity without waiting for the agent to cooperate.

These controls turn a black-box agent into a bounded operator. The owner defines the playing field, and the agent operates inside it. When you design an autonomous system, you should treat these limits as part of the integration step, not as an afterthought. Limits should be tested in paper trading before live authorization, because a cap that is too tight will block valid trades, while a cap that is too loose defeats the purpose. Our guide on how to control risks in autonomous trading systems that use MCP covers the configuration in more detail, and how to set guardrails for a trading agent without giving up custody explains the owner-side setup.

Why does dollar-normalized sizing matter for agents?

One of the most error-prone parts of multi-market trading is contract sizing. A perps venue might use coins, an options venue might use contracts with multipliers, and a stock broker might use fractional shares. When an LLM reasons about trades, it is safer to let it think in plain US dollars. The Felix API accepts order sizes in dollars and normalizes the translation to whatever the underlying venue requires. The agent says 'buy two hundred dollars worth' or 'reduce exposure by five hundred dollars,' and the system computes the corresponding number of shares, contracts, or coins. This removes an entire class of bugs where the agent confuses notional value with contract count, or sends an order that is ten times too large because of a decimal place. It also simplifies strategy logic. A portfolio rebalancing rule can say 'allocate ten percent to this asset' and trust the API to translate that dollar value into the correct venue units. The developer does not need to maintain tables of lot sizes, tick values, or margin ratios. The agent focuses on strategy, and the API handles the arithmetic. This is especially useful when the same strategy runs across markets with different conventions. A single line of logic can size a stock trade and a perp trade the same way, because both are expressed in dollars.

How should developers connect the agent?

Developers have two paths. The first is to connect through MCP tools from Claude, Cursor, or other MCP clients. This lets the agent discover available actions and invoke them through a standard protocol. The LLM sees a tool definition for placing an order, checking a balance, or reading a position, and it decides when to call each one. The second path is to call the REST API directly from custom code. This suits developers who want to manage the decision loop themselves, perhaps using a traditional algorithm or a custom model rather than an LLM. Both paths use the same key, the same safety controls, and the same order format. The choice depends on whether you want the LLM to manage the tool calling or you want to manage it yourself in code. In either case, the integration surface is small because the schema is uniform across all five market types.

For MCP users, the tool definitions are automatically generated from the API schema, so the LLM always sees the current set of available actions. There is no manual swagger file to maintain. When the API adds a new safety control or a new market type, the tool definition updates, and the agent can use it immediately.

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

{
  "key": "YOUR_KEY",
  "market_type": "perps",
  "side": "buy",
  "notional_usd": 500,
  "symbol": "BTC",
  "safety": {
    "max_position_usd": 2000,
    "kill_switch_url": "https://your-domain.com/alert"
  }
}

After the agent sends a request, the system validates it against the scoped key, checks the budget and position limits, translates the dollar size into venue units, and routes the order. The response returns the execution status in the same normalized format regardless of which market filled it. Errors are also normalized, so a rejection from an options venue looks the same as a rejection from a stock broker. This lets the agent handle failures with a single retry or fallback logic. For the full reference, see the documentation.

What is the difference between paper and live trading?

Paper trading exists so developers can test logic without risking real money. It uses the same API, the same order format, and the same safety controls, but execution happens against simulated liquidity. This lets you verify that your agent sizes orders correctly, respects limits, and handles errors before any capital is deployed. You can run paper trades across all five markets to confirm that the normalization layer behaves as expected. Moving to live trading requires an explicit owner authorization step. The owner must approve the key for real money, and the system records that authorization on the blockchain or in the account record. This gate exists to prevent an agent from silently switching from simulation to real execution. It is worth stating plainly: live trading can lose money, including the entire budget you allocate. Paper trading proves the plumbing works, but it does not prove the strategy is profitable. Volatility, slippage, and liquidity differences between simulated and real markets mean that a strategy that looks perfect in paper can still lose in live execution. Treat paper trading as a test of integration and safety, not as a promise of returns.

Developers should also test the kill switch during paper trading. Trigger the panic button and verify that positions flatten and the key revokes within seconds. If the agent holds positions across multiple markets, confirm that the flattening logic applies to all of them simultaneously. A kill switch that only works on one market type leaves exposure elsewhere.

How do you keep an agent safe across multiple markets?

Safety in a multi-market agent comes from layering controls. Start with the smallest viable budget cap and the narrowest scoped key you can. Test in paper trading across every market you intend to use, because each market has different volatility and settlement timing. A stock trade settles in a different cycle than a perp, and an options venue may have expiration mechanics that affect margin. Set position limits per market so that a bad signal in one venue cannot wipe out the entire budget. Configure an exit plan for every strategy, and attach a kill switch that a human or an external monitor can trigger. Review logs regularly to confirm the agent is staying within bounds. If you run multiple agents, consider giving each one its own scoped key so that a failure in one system does not affect the others. These habits matter more than the sophistication of the strategy, because an agent that cannot lose more than its cap is an agent you can iterate on safely. The goal is not to eliminate risk, which is impossible in trading, but to contain it so that the agent can run continuously without endangering the owner's full capital.

Monitoring is equally important. Because the API returns normalized execution data, you can build a single dashboard that tracks P&L, exposure, and error rates across stocks, crypto, perps, options, and prediction markets. This unified visibility makes it easier to spot anomalies early. If an agent starts trading outside its usual pattern, the monitor can trigger the kill switch before the budget cap is even reached.