How to place your first automated trade in any market with one API

Automating your first trade does not require mastering five different APIs or surrendering custody of your funds. A single API can normalize access to stocks, crypto, perpetual futures, options, and prediction markets so that one program places orders in plain dollar amounts. You keep control of your wallet and your withdrawal addresses, while the agent receives scoped permission to spend within hard limits that you set. The rest of this article walks through the setup from an empty workspace to a tested, capped, ready-to-live key.

What do you need before you start?

Before you write any code, you need a wallet that you control and a firm decision about how much money you are willing to lose. Automated trading can lose money rapidly, including the entire amount you allocate, so the budget you choose should be money you can afford to lose without affecting your living expenses. You do not need separate accounts at a stock broker, a crypto venue, a perps venue, an options venue, and a prediction market. The single API abstracts the connection layer, but you still need to know which markets you intend to trade because each carries its own risk profile. Stocks settle through traditional clearing, crypto moves on chain, perpetual futures use margin and funding rates, options have strike prices and expiry dates, and prediction markets resolve based on events. You should understand these basics before you automate. If you have never automated a trade, read the practical checklist for non-custodial trading beginners to confirm your wallet setup, key storage, and basic risk posture. You do not need to be a professional quant, but you should be comfortable with environment variables, JSON, and the idea that a program will place orders while you sleep.

How do you connect the API safely?

Connection starts with a scoped key, not a master password. When you create a key, you lock it to specific markets, specific actions, and a specific spending ceiling. The system enforces these constraints at the infrastructure level, so even if your agent behaves unexpectedly, it cannot exceed the cap you set. You also define a maximum position size per market and an exit plan that triggers under conditions you choose. A panic switch sits above everything else. It flattens positions and revokes the key instantly if you trigger it. Withdrawal addresses are owner-approved only, which means the agent can spend within the limits you define but can never send funds to an external address you have not preauthorized. These controls are described in how a single API keeps AI trading agents safe by design. Once the key is generated, you store it in an environment variable and never commit it to source control. If you are using an MCP client, the key is passed to the tool context, not embedded in the agent prompt. Live trading requires explicit owner authorization of a key, so a generated key cannot accidentally touch real capital until you confirm it through your wallet or admin interface.

How does one API handle five different markets?

The API sits between your agent and the underlying venues. When you send an order, you specify the size in US dollars, the asset symbol, and the market type. The API translates that into the contract math, lot sizes, margin requirements, tick conventions, and settlement rules that each venue expects. A one-hundred-dollar order in a stock broker, a perps venue, and a prediction market uses the same request shape. The only difference is the market type flag. For stocks, the API handles fractional share logic. For crypto, it handles token decimals and chain-specific confirmation expectations. For perpetual futures, it translates your dollar amount into notional value and checks leverage against your scoped limits. For options, it handles contract multipliers and premium calculations. For prediction markets, it handles probability prices and collateral conversion. Because perpetual futures carry funding rates and liquidation risks, the agent execution path for perps includes additional safety checks. You can read more about those mechanics in how perpetual futures trading changes when an AI agent takes over execution. The normalization layer means your agent does not need to know whether a venue prices in ticks, cents, or basis points. It sends dollars, and the API handles the rest. That said, the underlying risk profiles differ significantly. A prediction market may have wide spreads and binary outcomes. An option may expire worthless. A perp may liquidate if margin is insufficient. Your budget caps should reflect the volatility and loss characteristics of the specific market you are entering.

What does a first order look like?

The exact request schema is in the docs; the shape looks like this. Suppose you want to buy fifty dollars of an asset. You send a POST request with your key in the header, the symbol, the side, the dollar amount, and the market type. If you are using an MCP client such as Claude or Cursor, the agent calls a tool with the same parameters rather than crafting raw HTTP.

curl -X POST \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"symbol":"EXAMPLE","side":"buy","dollar_amount":50,"market_type":"stock"}' \
  API_PLACEHOLDER

The API returns an order identifier, a status, and fill details. If the order exceeds your scoped key limits, the API rejects it before it reaches the venue. If you request a market type that is not in your key scope, the API returns a permission error. The response format is consistent across all five markets, so your agent can parse fills using one logic path. For a prediction market, the fill includes the probability price at which you entered. For an option, it includes the strike and expiry. For a perp, it includes the entry notional and the margin used. You can poll for status or configure a webhook to receive updates. The normalization means you do not need to rewrite your parsing logic when you move from stocks to crypto or from options to prediction markets.

How do you test without risking real money?

Felix provides paper trading that uses the same API surface as live trading. You request a paper key, set the same budget caps and position limits, and run your agent against live market data without committing real capital. This is the stage where you verify that your scoped key behaves as expected, that your panic switch flattens positions, and that your webhooks fire on fills. If you are using an AI agent through MCP, you can observe how it reasons about order sizing before it ever touches a live key. You should also test failure modes. Send an order that exceeds your cap and confirm the API rejects it. Trigger the panic switch and confirm the key revokes. Attempt a disallowed market type and verify the permission error. Paper trading is not a guarantee of future performance, and simulated fills do not account for slippage or liquidity gaps in exactly the same way live markets do. However, it is a necessary step to confirm that your automation logic, safety limits, and market assumptions align. Treat paper trading as a rehearsal for the safety choreography, not as a proof that you will make money.

When should you go live and what happens next?

Live trading requires explicit owner authorization of a key. You toggle the key from paper to live, but the system does not allow this unless you confirm the action through your wallet or admin interface. Once live, start with a budget you can afford to lose entirely. The hard limits you configured in the key creation step remain active and cannot be overridden by the agent. You should monitor fills, audit logs, and webhook notifications during the first sessions. The article how to trade every market through one API with hard limits the agent cannot cross explains how these boundaries are enforced at the protocol level. If the market moves against your position, the agent can lose the allocated budget, but it cannot access funds outside the cap or change the withdrawal address. Review performance regularly, adjust caps as you learn, and keep the panic switch within reach. Over time, you may add more markets or refine your exit plans, but the core principle remains the same. One API, one key, hard limits, and full custody.