A beginner's guide to trading every market through one API

A single API can route orders to stocks, crypto, perpetual futures, options, and prediction markets using one key and normalized US dollar sizing. Beginners do not need to learn separate contract specifications, margin rules, or venue APIs for each asset class. Instead, you create one scoped key, set a budget cap, and test in paper mode before authorizing live trading with real capital.

What does one API for every market actually provide?

Traditionally, accessing multiple asset classes means managing separate accounts, data feeds, and order formats. A stock broker uses share quantities and dollar notional values. A crypto venue uses base and quote precision. A perps venue requires margin calculations and leverage ratios. An options venue expects contract multipliers and expiration codes. A prediction market uses outcome shares and binary payoffs. Learning each system takes time, and small formatting errors can produce expensive mistakes. The Felix API abstracts these differences. You send orders denominated in plain US dollars, and the infrastructure translates the amount into whatever contract math the underlying venue requires. This means your agent can buy five hundred dollars of a stock, five hundred dollars of a crypto position, or five hundred dollars of a prediction market outcome using the same parameter. The normalization layer handles tick sizes, lot sizes, and minimum increments so you do not have to. You no longer need to maintain five different authentication flows or parse five different error formats. The API returns a unified response structure whether you are trading an option or a perpetual future.

Under the hood, the API routes to the appropriate venue type without exposing you to its native interface. Stocks flow through a stock broker. Crypto spot and perpetual futures flow through their respective crypto and perps venues. Options flow through an options venue. Prediction markets flow through a prediction market venue. You never manage API keys for those venues directly. You hold one scoped key that grants execution rights only within the limits you define. The key cannot access your broader exchange account, withdraw funds, or change your venue passwords. This consolidation reduces both operational complexity and attack surface. Beginners can focus on strategy and risk management rather than juggling multiple exchange SDKs and documentation sets. If you want to rebalance a portfolio that includes both equities and crypto, you issue one request for the stock portion and one request for the crypto portion using identical syntax. The API handles the routing and settlement tracking separately.

How does the non-custodial model work?

Non-custodial means your funds remain in a wallet or account that you control, not in a pooled account managed by the API operator. When you create a trading key, you whitelist withdrawal addresses and set spending limits. The agent receives a scoped key that can sign orders and request trades, but it cannot move funds to an unapproved address. Even if an attacker fully compromises the agent or the machine running it, the worst they can do is trade within your preset budget. They cannot steal the underlying capital. This is structurally different from traditional custodial APIs, where you deposit money into a third party account and hope their security and withdrawal policies protect you. Here, the permissions are cryptographically bound to your key design.

The safety model is built into the key itself, not into the agent's prompt or behavior. This means a rogue or hallucinated instruction cannot override the scope. If the key is permitted to trade only crypto and stocks, an attempt to route an options order will be rejected at the API level. If the daily budget cap is one thousand dollars, the second order that would exceed it is blocked. These are infrastructure guarantees. Algorithmic traders can automate without giving up custody covers the cryptographic and architectural details in more depth. For beginners, the important point is that automation does not require surrendering control of your money.

Why should you start with paper trading?

Paper trading uses the same API endpoints, the same market data, and the same safety controls as live trading, but it executes against a simulation engine rather than real venues. When you place an order in paper mode, the system checks your logic, validates the parameters against your scoped limits, and returns a simulated fill based on real market prices. You see position updates, profit and loss calculations, and error messages exactly as you would in live mode. The only difference is that no real money moves. This lets beginners test connectivity, observe how the agent interprets instructions, and catch bugs in position sizing or market selection before capital is at risk.

New agents often make predictable mistakes. They might misinterpret a prompt and trade the wrong market. They might size a position too aggressively because they do not yet account for volatility. They might loop on an error and generate dozens of duplicate orders. Paper trading reveals these patterns without financial consequences. It is the default state for new keys, and you must explicitly authorize a key to switch from paper to live. You can read more about the mechanics in How paper trading works for AI agents from first principles. Treat paper mode as a requirement, not a suggestion, especially when you are learning how a single API handles five different market types.

How do you connect your first agent?

There are two main ways to connect: through MCP tools or through the REST API directly. MCP, or Model Context Protocol, is a standard that lets AI assistants in Claude, Cursor, and other MCP clients discover available tools. You configure the MCP integration with your scoped key, and the assistant gains access to functions such as checking balances, placing orders, and reading positions. You can then describe your strategy in natural language. The assistant translates your intent into the correct API calls. This path is often the fastest for beginners because you do not need to write custom code or manage polling loops. The agent handles the interaction, and the API enforces the safety boundaries you set on the key.

If you prefer to write your own logic, the REST API accepts standard HTTP requests and returns JSON. You can build agents in Python, JavaScript, or any language that can make web requests. Both connection methods use the same scoped key and the same safety model. The exact request schema is in the docs; the shape looks like this.

export FELIX_API_KEY="YOUR_KEY"

curl -X POST "https://api.felix.trade/..." \
  -H "Authorization: Bearer $FELIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market_type": "crypto",
    "side": "buy",
    "usd_amount": 500
  }'

Whether you use MCP or REST, the safety controls are identical. The API does not trust the client. It validates every request against the key's scope, budget, and allowed markets before forwarding it to the underlying venue. This means a bug in your script or a misunderstood prompt in your MCP assistant cannot bypass your limits. The normalization layer and the permission layer operate independently of how you connect.

What limits should you set before going live?

Live trading requires explicit owner authorization. Before you grant it, configure structural limits that the API enforces automatically. These are not polite suggestions that the agent should follow. They are hard constraints encoded into the key. A budget cap sets the maximum US dollars the agent can deploy across all markets. A position limit caps the size of any single trade or the total exposure in one market. An allowed markets list restricts the key to specific asset classes, such as stocks and crypto only. An exit plan defines conditions for closing positions, whether by time, loss threshold, or profit target. Finally, a panic switch lets you flatten all positions and revoke the key instantly if behavior diverges from expectations.

• ·Budget cap: the total USD the agent can risk before the API rejects new orders.
• ·Position limit: the maximum notional value of a single order or an open position.
• ·Allowed markets: a whitelist of which five market types the key can access.
• ·Exit plan: automated or manual rules for closing trades to prevent runaway losses.
• ·Panic switch: a one-click flatten and revoke that stops all activity immediately.

The full safety architecture is explained in How a single API keeps AI trading agents safe across every market. Because these controls live at the key level, a compromised agent cannot override them by generating clever prompts or recursive instructions. The API simply denies out-of-scope requests. This is critical for beginners who may not yet know how to audit an agent's reasoning chain. You do not need to trust the agent. You trust the key design.

When should you move from paper to live trading?

Transition only after you have observed the agent across multiple sessions and market conditions. Paper trading validates logic and connectivity, but it cannot perfectly simulate slippage, liquidity gaps, or latency. You should see the agent consistently respect your budget caps, handle rejected orders gracefully, and produce clean audit logs. Start with a small live budget that you can afford to lose entirely. Trading can lose money, including everything, and a strategy that appears profitable in paper mode may fail when real market impact and emotional pressure enter the equation. Authorization is a deliberate step. You review the scope, confirm the limits, and activate the key. You can revoke it at any time.

How do you monitor and audit live activity?

Every order, cancellation, fill, and error generates an immutable audit log tied to your scoped key. You can review what the agent ordered, when the request was received, and whether the underlying venue accepted or rejected it. This observability is essential for accountability. If the agent behaves unexpectedly, the logs reveal whether the issue was a prompt misunderstanding, an API error, or a market condition. You do not need to trust the agent to report honestly. For a deeper look at log structure, see How audit logs and observability keep MCP trading agents accountable.

Monitoring is not primarily about celebrating returns. It is about verifying that the agent operates within its scoped permissions. Beginners should review logs daily at first, looking for unexpected markets, oversized positions, or repeated error codes. If you see drift, invoke the panic switch, revoke the key, and return to paper trading. Debugging in paper mode is far less expensive than debugging with live capital. Over time, as you gain confidence in both the agent and the API boundaries, you can lengthen the review cycle, but the panic switch should always remain accessible.