One API for stocks, crypto, perps, options, and prediction markets
How a normalized API and symbology reduce integration work across five market types while runtime status and venue state govern current availability.
- 01One API and one symbology cover five marketed market types; runtime status reports which capabilities and venues are currently enabled.
- 02Every size is in US dollars via size_usd, so there is no contract math, lot sizes, or strike multipliers.
- 03The normalized order shape spans the five market types, while runtime, account, and venue state govern execution and reconciliation.
- 04Uniformity reduces integration surface and inconsistent request shapes; it does not guarantee model, system, data, or venue reliability.
- 05Unified rails make cross-market strategies, like hedging spot with a perp, simpler to express.
Ask a developer to build an agent that works across stocks, crypto, options, and prediction markets, and much of the work is plumbing. Each venue has its own auth, symbols, sizing, fees, and settlement. A unified trading API reduces that integration glue to one agent-facing interface. Runtime status, account eligibility, and venue state determine what is currently available.
One symbology across five market types
With Felix, the agent learns one way to name an instrument and one way to size a trade. Sizes are always in US dollars, so there is no contract math, no lot sizes, no strike multipliers to reason about.
Crypto / perp BTC, ETH, SOL (or crypto:BTC)
Stock NVDA, TSLA (or stock:NVDA)
Option option:BTC-20260711-70000-C
Prediction market pm:fed-cut-in-septemberInputs are forgiving. BTC, btc, and BTC-USD all resolve to the same thing, which matters when the caller is a language model that might phrase it any of a dozen ways.
The same request shape everywhere
Because the symbology is uniform, the supported integrations share one normalized order shape. Runtime, account, and venue state still determine whether a request can be accepted or filled:
POST /v1/orders {"instrument":"NVDA","side":"buy","size_usd":250}
POST /v1/orders {"instrument":"BTC","side":"buy","size_usd":50}
POST /v1/orders {"instrument":"option:BTC-20260711-70000-C","side":"buy","size_usd":40}
POST /v1/orders {"instrument":"pm:fed-cut-in-september","side":"yes","size_usd":20}Positions, fills, PnL, and balances use one normalized read model and reconcile against venue truth. One normalized model spans five market types; every executed order is real money, and current availability comes from runtime status.
Why this matters more for agents than for humans
A human trader can tolerate several apps and habits. An agent pays an integration cost for every additional request shape and edge case. Uniformity reduces integration surface and inconsistent request shapes, but it does not guarantee model, system, data, or venue reliability. Fewer shapes let more of the workflow focus on the decision instead of plumbing.
Cross-market strategies become simpler to express
When market integrations share one normalized language, cross-market strategies become simpler to express. Hedge a crypto position with a perp. Express a macro view with a prediction market and a stock at once. Roll an option and rebalance spot in the same loop. Runtime and venue state still govern each action. See the account model in How to give an AI agent a trading account.
Frequently asked questions
Felix exposes one normalized interface across stocks, crypto, perpetual futures, options, and prediction markets. Runtime status reports which capabilities and venues are currently enabled, and execution requires an owner-authorized key.
Always in US dollars via size_usd. There is no contract math, no lot sizes, and no strike multipliers, which is especially helpful when the caller is an AI model.
Agents are less tolerant of per-venue quirks than humans. One symbology and one request shape reduce the surface for error and let the model spend its reasoning on the trade, not the plumbing.
Yes. Positions, fills, PnL, and balances use one normalized response model across supported market types and reconcile against venue truth.
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine-readable referencefirst party
- Felix runtime statuslive status
Build with Felix now.
Felix infrastructure is live through MCP and the API. The full trading app launches September 17.
Real money does not mean unrestricted authority. Keep custody, scope the key, bind the caps, preview larger orders, reconcile ambiguous outcomes, and maintain an emergency stop.
Compare the live verified MCP and direct API paths, with owner authorization and runtime availability governing use.