Unusual Options Activity Scanner Developer Guide

An unusual options activity scanner is useful only if it explains why a contract is on the screen. Raw volume is not enough. A production scanner needs contract identity, expiration context, open interest, estimated premium, quote quality, DTE, moneyness, IV, Greeks, and a clean handoff into quotes and trades.

This guide connects the Unusual Options Activity Scanner, Options Chain API, Unusual Options Activity Scanner Model, Options Volume and Open Interest, and Options Flow False Positives.

Build the scanner as a review queue

The first design decision is language. Do not call a ranked row a signal. Call it a review candidate. A scanner can say a contract is active, large, short-dated, or tight. It cannot prove that a buyer has directional conviction.

Good labels:

• notable volume
• volume above open interest
• large estimated premium
• tight quote
• short DTE
• far OTM
• quote review required
• trade tape review required

Weak labels:

• smart money
• bullish whale
• bearish sweep
• guaranteed opening trade
• insider flow

The Options Chain Scanner Architecture doc covers the same principle for generic chain scanners. The unusual activity version needs even more care because users tend to overinterpret flow.

Use the chain as the first surface

Start from a chain snapshot because it gives breadth. For every underlying and expiration bucket, the scanner can inspect calls, puts, strikes, volume, open interest, latest quote, latest trade, IV, Greeks, and underlying price.

curl "https://api.cutemarkets.com/v1/options/chain/NVDA/?expiration_date=2026-06-19&limit=100" \
  -H "Authorization: Bearer YOUR_API_KEY"

The chain row is not the final evidence. It is the row selector. Once a row is selected, link to Quotes, Trades, Contract Snapshot, Options Liquidity Scanner, and Quote vs Trade Timeline.

Minimum score inputs

At a minimum, score:

Do not hide the components behind one score. Show the score, but keep the evidence visible. Users should see whether a row is notable because of premium, volume/OI pressure, tight spread, or short DTE.

Score example

def estimate_premium(volume, option_price):
    return volume * option_price * 100

def spread_percent(bid, ask, midpoint):
    if midpoint <= 0 or ask <= bid:
        return None
    return (ask - bid) / midpoint

def volume_oi_ratio(volume, open_interest):
    return volume / max(open_interest, 1)

These are not trading signals. They are ranking features. A high premium contract with a wide quote may still be rejected. A high volume/OI ratio may still be closing activity. A short-dated far-OTM call can look dramatic and still be noise.

Use Options Flow False Positives, Options Slippage Modeling, and Bid/Ask Spread Backtesting before treating a row as executable.

Add quote review

After the scanner selects an OCC ticker, pull a quote window:

curl "https://api.cutemarkets.com/v1/options/quotes/O:NVDA260619C00150000/?timestamp.gte=2026-06-04T13:30:00Z&timestamp.lt=2026-06-04T14:00:00Z&limit=500" \
  -H "Authorization: Bearer YOUR_API_KEY"

Quote review answers:

• Was there a usable bid?
• Was the ask stable or jumping?
• Was the midpoint meaningful?
• Was the spread percent acceptable?
• Was the quote fresh at the scanner timestamp?
• Did the row become untradable after a few minutes?

This is the same quote-aware discipline used in Why Option Quotes Matter More Than Last Price, Quote-Aware Options Fills, and Backtesting Execution Realism.

Add trade review

Trades validate printed activity. They do not replace quotes.

curl "https://api.cutemarkets.com/v1/options/trades/O:NVDA260619C00150000/?timestamp.gte=2026-06-04T13:30:00Z&timestamp.lt=2026-06-04T14:00:00Z&limit=500" \
  -H "Authorization: Bearer YOUR_API_KEY"

Trade review asks:

• Did volume arrive in one block or many smaller prints?
• Did prints cluster near the bid, ask, or midpoint?
• Did related strikes also print?
• Did the selected contract have enough activity after the scanner alert?
• Was the trade tape consistent with the chain row?

Use Trades, Historical Options Replay Runbook, and Historical Options Data API if the scanner is feeding research.

Store the artifact

A production scanner artifact should include:

{
  "underlying": "NVDA",
  "expiration": "2026-06-19",
  "contract": "O:NVDA260619C00150000",
  "score": 83,
  "volume": 4200,
  "open_interest": 380,
  "volume_oi_ratio": 11.05,
  "estimated_premium": 1270000,
  "dte": 15,
  "delta": 0.42,
  "iv": 0.61,
  "spread_percent": 0.045,
  "tags": ["volume > OI", "large premium", "tight quote"],
  "next_steps": ["quotes", "trades", "event_context"]
}

That artifact can feed Paper Trading, Backtest to Paper Trading Parity, or a daily research review without losing the evidence that created the alert.

Internal build path

Use these pages together:

1. Unusual Options Activity Scanner for the live browser workflow.
2. Unusual Options Activity Scanner Model for scoring semantics.
3. Options Volume and Open Interest for volume/OI terminology.
4. Options Flow False Positives for rejection logic.
5. Options Chain API for candidate discovery.
6. Historical Options Quotes API for bid/ask evidence.
7. Options Trades API for tape validation.
8. Options Data API for the full product surface.

That is how a scanner becomes a market-data workflow instead of a noisy leaderboard.

How the terminology applies

For Unusual Options Activity Scanner Developer Guide, the options data workflow should treat Option chain snapshot, Contract snapshot, Volume/OI pressure, Options flow false positive, Scanner artifact, and Historical REST window as operational state rather than glossary decoration. That framing keeps chain selection, contract snapshots, activity filters, quote state, and endpoint access tied to the exact contract the page is discussing.

A developer implementing this API Guide idea should persist Backfill, DTE bucket, Moneyness band, Quote condition, Trade condition, and IV skew beside the result, instead of leaving those words in a term card. It also makes false positives easier to diagnose because a high-activity contract can be separated from a tradable, timestamped, and entitled data object.

The review artifact for Unusual Options Activity Scanner Developer Guide becomes more useful when 0DTE contract, OCC root, Options data API, OPRA-originating data, OCC option symbol, and Bid/ask spread appear in the same body of evidence as the selected rows. When the article moves from concept to implementation, these fields should shape request order, cache boundaries, row labels, and review tables.

In production notes for this options data workflow, Midpoint, Quote/trade condition, Quote vs trade semantics, REST snapshot, WebSocket stream, and Entitlement gate define the checks that decide whether the workflow is reproducible. The result is a scanner or dashboard that explains why a contract was shown, skipped, refreshed, or passed into a downstream research step.

For Unusual Options Activity Scanner Developer Guide, the practical acceptance test is simple: another developer should be able to read the body, identify the exact inputs, reproduce the request sequence, and explain the accepted and rejected rows without relying on the bottom terminology grid. If a phrase appears in the page vocabulary, it should correspond to a stored field, a validation check, a replay step, or an implementation decision in the options data workflow.

This is also the reason the article should not measure success only by the final chart, table, or headline metric. The better standard is whether the data path, timing model, entitlement state, and evidence trail survive review. When those pieces are written directly into the body, the terminology becomes part of the workflow readers can implement.

Scanner rows should be auditable

An unusual-activity row should be more than ticker, volume, and direction. The row should preserve the option chain snapshot time, OCC option symbol, expiration, strike, right, volume, open interest, volume/OI pressure, bid, ask, bid size, ask size, implied volatility, Greeks, quote condition, trade condition, and exchange ID where available. The UI can show a compact score, but the stored scanner artifact should keep the raw market fields that created it.

That is the only way to separate attention from tradeability. A contract can have a large tick-level trade and still be a poor candidate if the top-of-book market is wide, the quote is stale, the bid is missing, or the contract came from a delayed source while the alert is presented as live. The scanner should log those cases as explicit reject reasons, not hide them behind a lower rank.

A production scanner also needs request discipline. Record the response envelope, pagination cursor, subscription topic, rate-limit budget, and backfill window used after reconnects. If a row cannot be rebuilt from those fields, the alert is not ready to become a backtest input or paper-trading candidate.