How to trade every market type through one API with real money

You can trade stocks, crypto, perpetual futures, options, and prediction markets through a single API and a single key. Felix normalizes order sizing in plain US dollars, enforces non-custodial safety limits, and requires explicit owner authorization before any live trading begins. The rest of this walkthrough explains how to connect, test, authorize, and run that unified setup without building separate integrations for each market type.

What does one API actually abstract away?

Most traders who automate strategies face a mess of credentials, data formats, and contract rules. A stock broker uses share counts and fractional logic that varies by market. A perps venue uses margin tiers, funding rates, and position sizes tied to notional value. An options venue uses strike spacing, multiplier logic, and delta adjustments that change across expiries. A prediction market uses outcome shares and binary payoff structures that look nothing like equity or derivative notation. Without a unified layer, your agent would need to learn each dialect, maintain separate keys, track different error codes, and manage venue-specific rate limits. Each integration introduces its own surface area for bugs, and each new venue requires a fresh audit of your agent's logic. Felix abstracts this into one interface. You connect once, using one key, and the API translates your intent into venue-specific instructions. You do not need to know the contract multiplier for a crude oil future or the share lot size for an international equity. Funds sit in a wallet you control, not in a pooled exchange account. The agent receives scoped permission to trade, but it cannot withdraw funds to itself or to any address you have not explicitly approved. This is non-custodial by construction, not by policy. The architecture prevents theft even if the agent's key is compromised, because the withdrawal whitelist is owner-controlled. If you want to understand the mechanics behind that custody model, read how an AI agent executes orders while you keep full custody.

How do you connect your agent to the API?

You have two paths. If you use Claude, Cursor, or another MCP client, you can attach Felix as an MCP tool and let the agent invoke trading actions through natural language or structured prompts. If you prefer a programmatic approach, you can call the REST API directly from your own code. Both paths use the same key, the same permission scopes, and the same safety limits. The only difference is whether your orchestration layer is a conversational model or a custom script. When you generate a key, you scope it to specific market types. A key might be allowed to trade crypto and perps but forbidden from options and prediction markets. You can also set read-only access for some markets and write access for others. This scoping happens at the infrastructure level, so the agent cannot bypass it by rewriting its own prompt. The key is the root of trust, and its permissions are enforced by the API, not by the agent's good behavior. The exact request schema is in the docs. The shape looks like this.

{
  "key": "YOUR_KEY",
  "market_type": "perps",
  "direction": "buy",
  "usd_amount": 500,
  "symbol": "ETH"
}

Notice that the order is expressed in plain US dollars. You do not need to calculate contract size, tick value, or margin fraction. The API handles venue normalization. The response returns the execution details in the same normalized format, so your agent can parse outcomes without knowing whether the underlying venue speaks in shares, contracts, or outcome tokens. The symbol field is also normalized; the agent does not need to remember that one venue calls an instrument BTC while another uses a different ticker convention. For a concrete example of an MCP-based setup, see how to run a trading agent from Claude using MCP.

How do you set safety limits before going live?

Before the agent touches real money, you should define what it is allowed to do. Felix provides several controls that are enforced server-side, so the agent cannot negotiate its way out of them. Scoped keys let you restrict which market types a key can access. Budget caps limit the total US dollars the agent can deploy over a given period. Position limits prevent the agent from taking oversized exposure in a single instrument. Exit plans define how the agent should reduce or close positions under predefined conditions, such as a drawdown threshold or a time-based expiry. Finally, a panic or kill switch flattens all positions and revokes the key instantly. These controls are not optional extras. They are structural guardrails that exist because trading can lose money, including everything. An agent with no budget cap can deploy your entire allocated capital on a single losing position. An agent with no position limit can concentrate risk in one volatile instrument. An agent with no exit plan can hold a drawdown far longer than your strategy intended, turning a manageable loss into a catastrophic one. The kill switch is your last line of defense. If the agent begins to act erratically, if market conditions shift outside your model's training range, or if you simply lose confidence in the strategy, you can flatten and revoke in one action. For a detailed guide on configuring these controls, read how to set spend caps and drawdown limits. You should also review a practical checklist for building your first LLM-powered trading agent before moving past the paper stage.

How do you move from paper trading to live markets?

Felix offers paper trading so you can test connectivity, prompt logic, and order flow without risking capital. Paper trading mirrors the live environment closely enough to surface integration bugs, but it is not a guarantee that your strategy will be profitable. Many developers make the mistake of assuming that paper success predicts live success. It does not. Slippage, latency, and market impact behave differently when real money is at stake. Other participants react to real flow, and liquidity can shift in ways that simulated fills do not capture. To switch to live trading, you must explicitly authorize the key. The owner, not the agent, performs this authorization. The agent cannot flip the switch itself. You will also need to approve withdrawal addresses if the setup requires any fund movement, though the agent can never add its own address. This authorization step is intentionally manual to prevent an autonomous system from escalating its own access. The owner approval requirement is a hard boundary. Even if the agent is compromised or misled by a malicious prompt, it cannot authorize live trading on your behalf. You should only authorize live trading after you have tested prompts, safety limits, and the kill switch in paper mode. Run the agent through a variety of market conditions. Verify that it respects budget caps. Confirm that the kill switch works and that positions flatten as expected. Paper trading is a rehearsal, not a promise. Live markets involve real loss, and the transition should be treated as a deployment to production, not a casual toggle.

How does order sizing work across different market types?

Suppose you send an order sized at $500. The API translates that amount into the correct number of shares, contracts, tokens, or outcome shares required by the underlying venue. This removes a major source of agent error. Imagine an agent that confuses notional value with margin requirement. It can accidentally take on ten times the intended exposure. By forcing the agent to think in dollars and letting the API handle the translation, you remove that footgun. However, normalization does not mean uniform risk. A $500 order in a stock is $500 of notional exposure. A $500 order in a perpetual future may carry a different effective exposure depending on the leverage available at that venue. A $500 order in an options market may control a much larger notional underlying, and the premium paid is only one component of the risk. The API handles the sizing math, but you must still configure your agent to understand the risk profile of each market type. You should set tighter position limits for leveraged products and ensure your agent knows whether it is trading delta, notional, or premium. The plain dollar amount is an interface convenience, not a risk metric. Your prompts and your guardrails must account for the underlying mechanics that the API abstracts away.

What should you monitor after your first live orders?

Once live, the agent will place orders, hold positions, and interact with markets continuously. You should monitor two things: the agent's behavior and the health of your safety controls. Review audit logs to confirm that orders match your intended prompts. Check that budget caps and position limits are enforced correctly. Verify that the kill switch is reachable and that you know how to trigger it without searching through documentation. It is wise to run a periodic fire drill where you manually trigger the kill switch to ensure the revocation path is still functional. If the agent's behavior drifts, flatten positions and revoke the key immediately. Do not wait for a theoretical recovery or assume the model will self-correct. Trading can lose money, including everything, and autonomous systems do not feel regret. They also do not get tired or distracted, which means they can compound errors at machine speed if left unchecked. A drift in behavior might be subtle at first, such as slightly larger position sizes or a shift toward more frequent trading. These small deviations can accumulate quickly. You should also review your prompts periodically to ensure they have not been manipulated or misinterpreted by the model. A prompt that made sense in paper trading may behave differently when market volatility increases and liquidity thins. Keep your prompts within strict bounds and avoid open-ended instructions that give the agent creative license over your capital. The more specific your prompt, the easier it is to audit the agent's actions against your intent. Regular review is especially important if your agent uses an LLM that may be influenced by context window changes or system prompt updates. Document every change to your strategy so you can correlate agent behavior with prompt versions.