How to build your first autonomous trading system with one API

You can start an autonomous trading system by connecting an agent to a single API that normalizes order entry, position tracking, and risk controls across stocks, crypto, perpetual futures, options, and prediction markets. The owner keeps custody of funds while the agent receives scoped permissions that limit how much it can spend, what it can trade, and where it can send withdrawals. Paper trading lets you test the integration and logic before authorizing live keys, and hard budget caps with a kill switch protect against runaway behavior once the system is live.

What does a single API actually abstract away?

Every market type has its own conventions for sizing, margin, and settlement. A stock broker counts shares. A perps venue uses contract sizes and margin ratios. An options venue handles strikes, multipliers, and expiration dates. A prediction market uses binary outcome shares. Crypto spot markets pair base and quote assets. If you integrated each venue separately, your agent would need to manage distinct authentication flows, rate limits, error codes, and data formats. It would also need to convert intended dollar exposure into venue native units, which introduces risks like decimal place errors or misapplied multipliers.

A unified API removes this burden. You send an order in plain US dollars, and the system normalizes the quantity, checks margin requirements, and routes the instruction. The API returns positions and balances in a common format, so the agent can track total exposure across asset classes without writing normalization logic. This reduces the chance that a contract size mistake turns a small intended position into an oversized one.

The abstraction also covers market data and connectivity. Some venues offer only REST, while others rely on websockets with custom reconnection behavior. The API presents a uniform interface for prices, order books, and order events. The agent can focus on strategy rather than venue specific plumbing.

How do you connect the agent safely?

There are two main integration paths. Developers can connect through MCP tools, which let agents inside Claude, Cursor, or other MCP clients invoke trading functions as part of their reasoning loop. Alternatively, you can call the REST API directly from a standalone program. In both cases, the connection is scoped. The key is not a private key to the owner’s wallet, and it is not a master password for a brokerage account. It is a permission object that lists allowed actions, budget limits, and approved market types. Suppose the scope says the agent can buy stocks and crypto spot, but not options or perps. It might say the agent can spend up to one thousand dollars per day. It might say withdrawals are disabled entirely.

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

{
  "key": "YOUR_KEY",
  "market": "crypto",
  "side": "buy",
  "dollar_amount": 150,
  "symbol": "BTC"
}

When you are building your first agentic trading system, start by testing the key with a read only scope. Let the agent fetch prices and balances. Once you trust the connection, expand the scope to paper trading. Only after the paper results look stable should you authorize a live key.

Why is non-custodial access important for autonomous agents?

Custodial services take control of your funds. Non-custodial infrastructure leaves funds in a wallet that the owner controls. The agent can spend within the owner’s limits, but it can never withdraw funds to itself or to an address the owner has not pre-approved. This matters because autonomous agents run continuously. A bug, a bad prompt, or a compromised model could issue harmful instructions. If the agent held custody, those instructions could drain the account.

With scoped keys, the worst case loss is bounded by the daily or total budget cap. The owner can also set position limits, so the agent cannot concentrate the entire budget in one volatile instrument. If behavior becomes erratic, the panic switch flattens all positions and revokes the key instantly.

How scoped API keys work without custody explains the architecture in detail. The short version is that the owner signs an approval that creates a limited session. The agent uses that session. The session can be terminated at any time without moving funds or waiting for withdrawal processing. This design also makes it easier to iterate. Owners are more willing to deploy new strategies when they know the funds never leave their wallet. It simplifies accounting and reduces the operational risk of managing separate custodial accounts for each venue.

How do you control dollar-based order sizing and risk?

Order sizing is where many first-time agents fail. A strategy might look good in a spreadsheet but break when the agent must translate a percentage of portfolio into actual shares or contracts. Felix sizes orders in plain US dollars. You tell the API to buy one hundred and fifty dollars of an asset, and the system handles the conversion to shares, contracts, or units.

This removes an entire class of errors. The agent does not need to know that one options contract represents one hundred shares, or that a perps contract has a specific notional value. It simply specifies the dollar exposure. The API checks the scope, verifies that the owner has sufficient margin or balance, and executes the appropriate quantity.

Risk controls sit at the API level, not just the strategy level. The owner sets a hard spend cap. The owner sets a drawdown limit. The owner sets a maximum position size per symbol and per market type. These are enforced outside the agent’s logic, so a bug in the strategy cannot bypass them. Risk management for a first-time trading agent covers how to set these limits for a new system. You should also control the risks of dollar-based order sizing by starting with small dollar amounts and verifying that the executed position matches your intent before scaling up.

What should you test before going live?

Paper trading exists for a reason. It lets the agent run through the full lifecycle of a strategy without committing real capital. During paper testing, you should verify more than just profit and loss. Check that the agent handles errors gracefully. Check that it respects the scope. Check that the kill switch actually flattens positions. Check that disconnections do not leave orphaned orders.

Live trading requires explicit owner authorization. The system will not let a paper key trade real money by accident. When you authorize the live key, start with the smallest dollar amounts your strategy allows. Observe the first few orders manually. Compare the intended size in dollars with the executed position. Look for slippage, latency, and partial fills.

Some owners run paper and live side by side for a period. They send a small fraction of intended capital to the live key while the majority stays in paper mode. This lets them compare fill quality and behavior under real conditions without taking full exposure. Trading can lose money, including everything. Paper profits do not guarantee live results. Markets move, liquidity changes, and the agent’s speed can be an advantage or a liability. The goal of the first live session is not to make a profit. It is to confirm that the system behaves exactly as it did in paper mode.

How do you maintain the system after launch?

Autonomous does not mean unattended forever. A healthy deployment includes regular log review, budget reconciliation, and scope rotation. Check that the agent’s daily spend matches your expected frequency. If the agent is supposed to trade twice a day but is trading fifty times, that is a signal to inspect the logic.

Keep the panic switch accessible. If the market regime changes, or if the agent starts producing orders that do not match your current understanding of the strategy, flatten positions and revoke the key. You can always create a new scoped key after you fix the bug. It is cheaper to restart with a fresh key than to recover from a drawdown that hit the limit because you hesitated to act.

Rotate keys periodically as a hygiene practice. If a key was accidentally logged or exposed, rotation limits the window of vulnerability. Review your exit plan regularly. Some strategies need time to close positions. Others should close immediately. The API supports exit plans that trigger automatically when a limit is breached. Make sure these are configured and tested. An exit plan that was never tested in paper mode is a wish, not a control.