Options Analytics API - Developer Access

Last reviewed: by .

API Access

The core pricing, Greeks, calibration, exposure, and market-data surfaces in the webapp are also available as a REST API and WebSocket streaming service. The data-api serves 17 pricing models with webapp-aligned parameter names for the public pricing surface (10 standard plus 7 exotic: Barrier, Asian, Lookback, Digital, Compound, Chooser, Multi-Asset), auto-calibration for 5 of them against live chain data, real-time Greek exposure analytics, and pre-computed market data, programmatically, for devs and quants.

📖 Interactive API Documentation

Browse all endpoints, inspect request/response schemas, and try live requests directly from your browser:

data.optionsanalysissuite.com/docs →

The docs site includes full OpenAPI 3.0 specs, example requests, authentication details, and a "Try it" playground that makes real API calls with your key.

What the API offers

BYOK broker credentials

The API uses Bring Your Own Key for market data. Calibration and streaming endpoints accept your own Tradier or TastyTrade credentials via HTTP headers. You pay broker fees directly (often $0), and we handle all the compute on our end. Static compute endpoints (pricing, Greeks, analytics on passed-in data) don't require any broker credentials.

Authentication

All /v1/* endpoints require an API key: Authorization: Bearer oas_live_... or X-API-Key header. Generate keys from your Account page once you're on the API tier.

Quotas and Fair Use

API tier limits are enforced per-user (not per-key), and split into a few different pools:

When a limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header pointing to the next reset. Calibration quota resets at midnight UTC.

Fair-use clause: We reserve the right to throttle or suspend accounts exhibiting sustained usage patterns that disproportionately consume compute resources, even if technically within the documented limits (e.g., continuous calibration loops, indefinite WS sessions at max message rate). See the  Acceptable Use Policy and Terms of Service §16.2 for details.

Best Practices (especially for LLM-driven agents)

If you're wiring the API into an LLM agent (ChatGPT, Claude, Cursor, Windsurf, a custom MCP server), a handful of patterns keep your calls efficient and well under fair-use thresholds:

  1. Calibrate once, then persist the fitted params — not the calibrationId. The calibrationId returned by /v1/compute/calibrate is a short-lived handle into a 30-second in-memory cache; it works for immediate follow-up /price and /greeks calls but is not durable. For reuse across sessions or minutes later, save the fitted parameters from the calibration response and pass them as modelParams on subsequent calls. Either path avoids the 500/day calibration quota. Do not set resolve.calibration: true on every call for the same symbol — that re-fits each time and burns your daily cap.
  2. Prefer /v1/data/* over recomputing. Greeks history, IV surfaces, snapshot metrics, metrics-batch, scanner rankings, and regime classifications are precomputed or cached where available — typically much faster than recomputing from scratch. Don't call /v1/compute/greeks in a loop to reconstruct what /v1/data/greeks-history/:symbol already returns.
  3. Use batch endpoints where they exist. /v1/data/metrics/batch accepts multiple symbols in one call. Pricing and Greeks endpoints accept ticker lists via modelParams.tickers for MultiAsset. One batch call beats a loop of N single-symbol calls on rpm, latency, and cost.
  4. Use ticker auto-fill instead of fabricated numerics. LLMs sometimes hallucinate S, sigma, r, t from stale training data. Pass symbol + expiry and let the API resolve from cached market data — the response's resolved block tells you exactly which fields were filled from which source (snapshot, atmIv-expiry, hv-30d, fred-DGS3MO, etc.) so you can audit.
  5. Always inspect warnings and resolved before acting. When ticker auto-fill runs, the response includes a resolved block (what was filled and from where) and a top-level warnings array (stale quotes, missing fields, fallbacks used). Agents that ignore these can take action on a price computed with a one-week-old spot or a missing-dividend fallback. Check both before forwarding numbers downstream.
  6. Honor Retry-After on 429. When you hit a rate limit, the response includes Retry-After in seconds. Agents that retry instantly in a tight loop just bounce off the same limit and waste tokens. Sleep the suggested duration, then proceed.
  7. Don't repoll faster than the underlying data updates. Most /v1/data/* endpoints back tables that refresh once a day (or on a documented cron). If you're hitting /v1/data/history/:symbol every 30 seconds, you're getting the same bytes. The cache handles this server-side, but skipping the call entirely saves your rpm budget. Data responses include X-Cache-Status (values include HIT, MISS, DEDUP, NO_REDIS, and error/fallback statuses) — if you're seeing all HITs, you're polling too fast.
  8. Stream live data over WebSocket, don't poll REST. If you need intraday quote or exposure updates, the /v1/ws endpoint delivers them at up to 30 msg/sec across 50 symbols per session. Polling a REST endpoint every second for the same data burns your rpm and still has multi-second staleness.
  9. Match model to task. Black-Scholes and Binomial are sub-100ms and correct for vanilla European/American options. Reserve Heston, SABR, Local Vol, Jump Diffusion, and Monte Carlo for cases where skew, jumps, or path-dependence actually matter. An agent that defaults to Heston for every price/Greeks call is paying 10×–100× the latency for the same answer.
  10. Scope and secure keys. Create separate keys for compute-only, data-only, and streaming use cases — scopes limit blast radius if a key leaks. Never embed keys in client-side JS, browser extensions, public repos, or LLM tool manifests that get logged or shared.

This page is part of the Options Analysis Suite documentation hub. Browse the glossary for term definitions.