Insights
Point-in-Time Optionable Tickers API
Alphanume Team · August 8, 2026
Query the optionable equity universe for a historical month, retain the returned snapshot date, and join membership into a backtest before selecting any options trade.
A point-in-time optionable tickers API answers which US equities had listed option chains at a historical snapshot. Alphanume's Historical Optionable Tickers dataset records monthly membership on the first trading day of each month. It also provides the mean of four expiration gaps and a weekly-style density flag set when that average is under nine days.
The historical optionable tickers guide explains the dataset in a research workflow. The API is a universe source, not an options tape. It does not provide contract prices, strikes, bid-ask spreads, open interest, volume, fills, or execution quality.
Request the historical snapshot directly
Use equal date_gte and date_lte bounds for one known snapshot, or wider date bounds for a range. A request described as January 2023 should use the actual served snapshot date for that month, which is the first trading day rather than an assumed calendar date. Always carry that returned date into the downstream join.
Field | What it establishes | What it does not establish |
|---|---|---|
date | Snapshot observation date | Trade execution time |
ticker | Listed option-chain membership | A specific contract existed at a chosen strike |
avg_days_between | Mean of four gaps after the first observed gap | Liquidity or spread quality |
has_weeklies | Whether that mean is under nine days | Guaranteed weekly contracts throughout the month |
The expiration metric averages the four gaps after the first observed expiration gap. A value near seven indicates a dense weekly-style calendar. It is not proof of exact consecutive weekly contracts or a tradability score. A listed chain can still be unsuitable after costs or lack the exact maturity required by a strategy.
Paginate without losing membership rows
Large multi-month pulls use keyset pagination ordered by date and ticker. If has_more is true, return both cursor_date and cursor_ticker from the provided cursor. Validate uniqueness on the date and ticker pair after collecting the pages.
GET /v1/optionable-tickers
date_gte=2023-01-01
date_lt=2023-02-01
snapshot = unique returned date for the month
universe = set of returned ticker values
for each signal_date:
eligible_snapshot = latest snapshot where date <= signal_date
is_optionable = signal_ticker in universe[eligible_snapshot]
keep eligible_snapshot beside the simulated tradeThe exact join rule should depend on the strategy's rebalance timing. A monthly strategy can use that month's first-trading-day snapshot for later observations in the month. A signal earlier than the first available snapshot should use the prior snapshot or be excluded. It should never use a future snapshot because that introduces option-listing information unavailable at the time.
Make universe selection precede the signal test
Build the dated eligible universe first, then apply the strategy signal. This order prevents the research code from starting with symbols that survived into today's optionable list. If the strategy requires the served weekly-style density threshold, add has_weeklies=1 at the same snapshot. If it only requires some listed chain, do not add that filter after seeing performance.
- Store the snapshot date selected for every trade candidate.
- Keep monthly additions and removals instead of backfilling membership.
- Resolve ticker changes with a dated security master when histories are long.
- Version the extracted universe with the research run.
A useful QA table lists total members, weekly members, additions, removals, and median expiration spacing for every snapshot. Sudden changes may be real, but they can also expose an incomplete pagination loop or a bad date join. Inspect them before computing performance.
When the trading model uses daily signals, materialize the membership join as its own table rather than embedding it inside return code. Include signal date, selected snapshot, ticker, membership result, weekly flag, and expiration spacing. This makes it possible to verify eligibility without rerunning the strategy and exposes any signal that was matched to a later snapshot. It also prevents a later change in trade logic from silently changing the historical universe.
Do not simulate prices the API does not contain
The main failure mode is treating membership as sufficient for an options backtest. Point-in-time optionability removes one form of survivorship bias, but execution still requires historical contract definitions and quotes. A full simulation needs selection rules for expiration and strike, corporate-action adjustments, quote filters, spread and slippage assumptions, and a policy for missing or crossed markets.
A second failure is assigning one monthly snapshot to dates before it existed. A convenient month label is not a timestamp. Use the served first-trading-day date and report how pre-snapshot signals were handled. This distinction becomes important around holidays and month boundaries.
Run a one-month join audit
As a concrete next action, query January 2023, record the returned snapshot date, and save every ticker with both density fields. Join that universe to one month of dated strategy signals using the latest-eligible-snapshot rule. Export accepted and rejected candidates with the snapshot used and rejection reason. Then verify several symbols against the raw response. Only after that audit should historical contract data and execution assumptions be attached.