How to evaluate a trading API for an AI agent

Evaluating a trading API for an AI agent means testing whether the API lets you constrain the agent more tightly than it lets you trade. You should look for scoped permissions, non-custodial access, built-in spend caps, and plain-dollar order sizing before considering any other feature. If the API treats safety as a wrapper around the venue rather than a property of the API itself, it will shift the burden of risk management onto your prompt engineering. The right API makes dangerous actions architecturally impossible, not merely discouraged.

What markets and permissions does the API expose?

An AI agent does not need universal access. It needs bounded access. The first question is whether the API supports the markets you intend to trade, such as stocks, crypto, perpetual futures, options, or prediction markets, through a single integration. A single key and a single interface reduce the complexity of the agent's reasoning, because it does not need to switch contexts between different venue conventions. However, market coverage is only relevant if the API also lets you scope what the agent can do within those markets.

Look for granular permissions. Can the key be restricted to read-only balance checks? Can it be limited to specific market types, or even specific instruments? Can it place orders but never modify account settings or withdrawal addresses? The API should treat permission scope as a primitive, not as a premium feature. If the only way to limit the agent is to share a master key and hope the prompt respects boundaries, the architecture has already failed. You are not evaluating a trading API at that point. You are evaluating your own ability to write perfect instructions, which is a different and much harder problem.

You should also ask how easy it is to rotate or revoke a key. If changing the agent's credentials requires resetting the owner account or disrupting unrelated integrations, the API is not designed for autonomous use. Key rotation should be a routine operation that takes seconds and affects only the agent's scope.

How does the API handle custody and withdrawal?

This is the most important architectural question. Non-custodial access means the agent can trade within limits you set, but it cannot take custody of the funds. The underlying funds should remain in a wallet or account that the owner controls. Withdrawal addresses should be owner-approved before the key is created, and the agent should never be able to add new destinations. If the API allows the agent to request a withdrawal to an arbitrary address, even with a confirmation step, that is a custody gap that logic errors or prompt injection can exploit.

A properly designed API enforces this at the infrastructure level. The agent's key is scoped to trading operations, and the API backend rejects any withdrawal request from that key regardless of headers, payload, or prompt state. This is what how scoped API keys let an agent trade without taking custody of your funds describes in detail. The distinction between policy and architecture matters. Policy says the agent should not withdraw. Architecture ensures it physically cannot. Before you connect an AI agent to real money, verify that the API provider can explain exactly how the withdrawal path is blocked by the key scope itself.

Can the agent reason about orders in plain dollars?

AI agents reason well in natural language and simple numbers. They do not reason well in contract multipliers, lot sizes, tick increments, or margin tiers. If the API forces the agent to compute the number of contracts, shares, or lots based on current prices and margin requirements, you have introduced an unnecessary translation layer where errors compound. A miscalculation of a single decimal place or contract unit can turn a small intended exposure into a leveraged position that is many times larger than expected.

The better model is an API that accepts orders sized in plain US dollars. The agent decides it wants to allocate one hundred and fifty dollars to a position, and the API normalizes that into the correct venue-specific units. This removes the need for the agent to understand whether it is trading perpetual futures on one venue or shares through a stock broker. The abstraction also protects you from common mistakes that happen when agents miscalculate notional value. Common position sizing mistakes when letting an AI agent trade real money covers the risks of letting the agent handle contract math directly. Plain-dollar sizing is not a convenience. It is a safety boundary that reduces the error surface by removing ambiguous calculations from the agent's path.

What safety controls are enforced by the API rather than the user?

Every trading API will claim to be secure. The question is where the controls live. Safety controls should be API-level primitives, not UI toggles or client-side suggestions. At minimum, you should be able to set a hard budget cap, a maximum position size per instrument, a daily or weekly loss limit, and an exit plan that triggers under defined conditions. These constraints should travel with the key, meaning they are enforced server-side on every request.

A budget cap is only useful if the API rejects orders that would exceed it, even if the agent sends multiple requests in rapid succession. A position limit is only useful if it prevents the agent from opening a larger position by splitting the order across several smaller requests. The API should maintain its own accounting of the agent's current exposure and enforce the limit as a hard ceiling. If the agent must track its own spending to stay within bounds, the control is not API-level. It is a suggestion.

The most critical control is the kill switch. It should flatten open positions and revoke the key in a single action. The agent must not be able to override, delay, or ignore this signal. The mechanism should work from first principles, as discussed in how kill switches work from first principles for trading agents. If the kill switch is implemented as a separate bot that polls for orders and tries to cancel them, it will race against the agent. If it is implemented as a revocation of the key's core permissions, it wins instantly. Ask the API provider how the kill switch terminates the key. If the answer involves polling, retries, or optimistic checks, look elsewhere.

How does the agent connect to the API?

There are two common patterns. The agent can connect through MCP tools, which allow an AI coding assistant or autonomous runtime to discover trading actions as native tools, or it can connect directly through a REST API. MCP integration is useful when the agent is running inside an environment like Claude, Cursor, or another MCP client. The agent sees trading as structured function calls rather than raw HTTP requests, which reduces the chance of malformed payloads.

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

curl -X POST https://api.felix.trade/orders \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "BTC-USD",
    "side": "buy",
    "notional": "150.00"
  }'

Regardless of the connection style, the transition from testing to live trading should be explicit. Paper trading must be available for validation, and live trading should require a distinct authorization step for the key. The agent should not be able to accidentally promote a paper key to live status because of a prompt ambiguity. How to run your first trading agent from an AI code editor using MCP walks through the setup process for developers who prefer the MCP path.

What is the path from paper testing to live authorization?

Before an AI agent trades real money, it should trade fake money for long enough to reveal edge cases. Paper trading lets you test order sizing, error handling, and safety triggers without exposing capital. The API should offer paper trading as a first-class environment, not as a limited demo mode. You need to see how the agent behaves when it hits a position limit, when a kill switch fires, and when a market moves quickly. You also need to see how the API reports errors back to the agent, because malformed responses can cause loops or incorrect state assumptions.

When you are ready to go live, the authorization should be deliberate. The owner should generate or promote a key explicitly, review the attached scopes and caps, and confirm the withdrawal block. There should be no automatic graduation from paper to live based on performance. Trading can lose money, including everything, so the first live trades should use the smallest limits the API allows. An API that blurs the line between test and real capital is dangerous for autonomous systems. Keep the environments separate, and treat the live key as a credential that requires human ceremony.