Paper Trading Bot Data Stack
A paper trading bot only works if its live data path matches the assumptions used in research. For options strategies, that means the data stack must handle contract identity, quote quality, trade prints, aggregate bars, expirations, and broker boundaries explicitly.
CuteMarkets is market-data infrastructure. It is not a brokerage API. A paper bot can use CuteMarkets to discover and validate option contracts, then use a separate broker adapter to submit paper orders.
Required data objects
| Object | Why the bot needs it | CuteMarkets surface |
|---|---|---|
| Expirations | Build the eligible expiry window before selecting contracts | GET /v1/tickers/expirations/{ticker}/ |
| Contracts | Select historically or currently valid option instruments | GET /v1/options/contracts/ |
| Chain snapshots | Inspect the current option surface, Greeks, open interest, and quotes | GET /v1/options/chain/{ticker}/ |
| Contract snapshot | Recheck a selected contract before entry or exit | GET /v1/options/snapshot/{u}/{contract}/ |
| Quotes | Measure spread, staleness, and executable bid/ask context | GET /v1/options/quotes/{options_ticker}/ |
| Trades | Validate that the contract is actually printing | GET /v1/options/trades/{options_ticker}/ |
| Aggregates | Replay bars and compute indicators or exit paths | GET /v1/options/aggs/... |
| Open/close | Build daily checks and post-session review | GET /v1/options/open-close/{ticker}/{date}/ |
The bot should treat these as different evidence types, not interchangeable prices. A last trade is not a quote. A chain snapshot is not a full historical replay. A contract list is not proof that the contract was liquid enough to trade.
Contract discovery
Contract discovery should be deterministic:
- Start from the underlying ticker, session date, and strategy DTE window.
- Fetch listed expirations and contract candidates.
- Filter by call or put direction, DTE, strike distance, open interest, and premium constraints.
- Rank candidates with the same rule used in backtests.
- Recheck quote quality near the live decision point.
For historical research, use an as_of contract workflow where available so the backtest does not accidentally select a contract based on a modern chain. For live paper, use the current contract surface but still log the exact selected ticker and all rejection reasons.
Quote quality
Short-horizon option strategies are sensitive to bad fill assumptions. The paper bot should record quote diagnostics before it opens or closes a position:
- bid
- ask
- mid
- spread
- spread as percent of mid
- quote age
- selected limit price
- max allowed spread
- fallback policy if the order does not fill
If quotes are missing or stale, the bot should reject the trade or route through a documented fallback. Silent midpoint assumptions are not enough for paper-bot validation.
Broker boundary
Separate the market-data adapter from the broker adapter.
The data adapter answers:
- Which contracts exist?
- What did the option market quote?
- What traded?
- Which aggregate bars support the signal and exit path?
The broker adapter answers:
- What account is active?
- What paper orders were submitted?
- Which orders filled, rejected, canceled, or stayed open?
- Which positions are still open?
Do not let broker fills rewrite the research data silently. Paper trading is useful precisely because it compares the live route against the research route.
Storage
Use persistent storage for both cached market data and runtime artifacts.
For research and backtesting, cutebacktests uses a DuckDB-backed cache for objects such as stock bars, option chains, option bars, option quotes, contract caches, signals, backtest trades, and paper orders. For live paper execution, add session-scoped files or tables for state, trade logs, funnel logs, and execution decisions.
Recommended storage rules:
- one writable database per experiment or paper loop
- no shared writable DuckDB across unrelated concurrent jobs
- immutable logs for submitted orders and close attempts
- explicit run labels for every smoke, parity, and paper loop
- enough data in each row to replay the decision later
Data failure modes
Paper bots should fail closed on data ambiguity. Watch for:
- missing underlying bars at the signal time
- stale option quote
- empty contract candidate set
- contract not supported by the broker
- spread wider than the strategy allows
- quote/trade history unavailable for the plan tier
- mismatch between backtest option mode and live option selection
- provider rate limits or partial pages
Each failure should land in the funnel log as a named rejection reason. A named no-trade is a valid output; a silent no-trade is an operations bug.
Using cutemarkets-python
The public Python client wraps the same API surface with typed sync and async clients. Use it when a bot needs explicit pagination, typed errors, rate-limit metadata, or async fan-out over a watchlist.
Example workflow:
from cutemarkets import CuteMarkets
client = CuteMarkets()
contracts = client.options.contracts.list(
underlying_ticker="SPY",
expiration_date_gte="2026-05-01",
limit=1000,
)
for contract in contracts:
print(contract.ticker, contract.expiration_date, contract.strike_price)
The exact ranking and routing logic belongs in your bot. The API client should stay a transport layer, not a hidden strategy engine.