API Documentation

Alphanume exposes every dataset through a single, query-parameter–based REST API. This page walks through account setup, authentication, and the request pattern shared by all endpoints.

Create an Account

To access the Alphanume API, create an account at the sign-up page. After registering and setting your password, your API key will be emailed to you automatically.

Base URL

All Alphanume API requests are made against:

https://api.alphanume.com/v1

Example Request

The API follows a simple, query-parameter–based request structure. Below is a sample request to the Historical Market Cap endpoint:

import requests

url = "https://api.alphanume.com/v1/historical-market-cap"
params = {
    "ticker": "AAPL",
    "date": "2026-02-06",
    "api_key": "alp_abc123"
}

response = requests.get(url, params=params)
data = response.json()

print(data)

curl "https://api.alphanume.com/v1/historical-market-cap?ticker=AAPL&date=2026-02-06&api_key=alp_abc123"

Header-Based Auth

You can also pass your API key via the X-API-Key header instead of a query parameter.

curl "https://api.alphanume.com/v1/historical-market-cap?ticker=AAPL&date=2026-02-06" \
  -H "X-API-Key: alp_abc123"

Response Format

Responses are returned in JSON and are designed to be immediately usable in research pipelines.

{
  "count": 1,
  "data": [
    {
      "date": "2026-02-06",
      "ticker": "AAPL",
      "market_cap": 4109599296360.0,
      "shares_outstanding": 14776353000.0
    }
  ]
}

General Pattern

All Alphanume endpoints follow the same structure:

GET /v1/{endpoint}?param1=value&param2=value&api_key=alphanume_api_key

This makes it easy to programmatically construct requests across datasets without learning new schemas.

Rate Limits

• Free tier: 60 requests per minute
• Pro tier: 600 requests per minute
• Exceeding the limit returns HTTP 429

Next Steps

• Explore the available datasets in the sidebar
• Review authentication and API key setup
• Integrate directly into your backtests or production systems

Alphanume runs a hosted MCP (Model Context Protocol) server that exposes every dataset in the catalog as 25 callable tools. Connect it to Claude Code, Cursor, or any MCP client and query the datasets conversationally; the model constructs the calls, the server returns the same point-in-time data as the REST API.

Server URL

https://alphanume.fastmcp.app/mcp

The server speaks streamable HTTP, the current MCP transport standard.

Connect from Claude Code

claude mcp add alphanume --transport http https://alphanume.fastmcp.app/mcp --header "X-API-Key: alp_YOUR_KEY"

For other MCP clients, point the client at the server URL and attach your key as an X-API-Key header. Authorization: Bearer alp_... is also accepted.

Authentication

The MCP server uses the same API key as the REST API; there is no separate MCP account. Keys are emailed automatically at sign-up. If no key is configured, tool calls return a clear error explaining how to set one.

Tiers and Limits

• Free tier: rolling 30-day window of delayed data (the most recent observation is reserved for Pro), 60 requests per minute
• Pro tier: full history, 600 requests per minute

Available Tools

One tool per dataset, matching the references in this sidebar:

• Equity selection: next-day movers, Quant Galore Momentum Index
• Index & volatility:SPX 0-DTE strike band, S&P 500 risk regime, IV/HV premium, IV/HV rank (52-week), vol-of-vol
• Earnings: implied vs realized move history
• Corporate events: dilution filings, shelf registrations, de-SPAC events, corporate default events
• Regulatory & enforcement: SEC trading suspensions, cyber incidents, crypto enforcement actions
• Biotech & FDA: FDA response events, advisory committee votes
• Dividends: dividend capture
• Reference data: historical market cap (plus ticker coverage list), optionable tickers, ticker classification
• Alternative data: Wikipedia views, SEC filing intensity
• Utility: API status

Response Conventions

• Responses mirror the REST API: {"count": N, "data": [...]}
• Every data tool accepts max_rows (default 500); prefer narrowing date or ticker filters over raising it
• Volatility tools update intraday and settle after the close; pass only_final=true to restrict to settled values
• Large datasets paginate with cursor_date and cursor_ticker, returned as next_cursor when has_more is set

The Next-Day Movers dataset provides a daily, model-ranked collection of equities most likely to experience large price moves in the following trading session.

Each observation contains one of the top names selected from a universe of liquid optionable equities, based on a predictive model designed to identify securities with elevated next-day realized movement potential. Behind the scenes, the model evaluates features such as implied volatility, realized volatility, and related volatility structure information to rank candidates by expected next-day movement.

All observations are stored historically and remain fixed once published, allowing the dataset to be used safely in systematic research and backtesting workflows without lookahead bias.

Why it's useful

• Identify equities most likely to experience outsized next-day moves
• Build directional or non-directional volatility trading strategies
• Screen for high-movement candidates before the next session opens
• Study the relationship between implied volatility, realized volatility, and future movement
• Backtest systematic workflows built around next-day mover selection

Endpoint

GET /v1/next-day-movers

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/next-day-movers"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/next-day-movers?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date: observations for a single trading date (YYYY-MM-DD).
• date_gte / date_lte / date_gt / date_lt: filter by date range. Any logically valid combination is accepted.

If no date filters are provided, all available historical observations are returned.

Response Format

{
  "count": 2,
  "data": [
    { "date": "2026-03-09", "ticker": "AAOI", "return": 8.92, "absolute_move": 8.92 },
    { "date": "2026-03-09", "ticker": "FIGR", "return": 21.29, "absolute_move": 21.29 }
  ]
}

Forward Return Availability

For the most recent observation date, return and absolute_move will appear as null. These fields represent realized movement during the following trading session. Until a full trading day has completed after the selection date, the outcome cannot yet be calculated. Once the next session has closed, the values are populated automatically and remain fixed thereafter.

// Most recent date
{ "date": "2026-03-10", "ticker": "NVDA", "return": null, "absolute_move": null }

// Historical observation
{ "date": "2026-03-09", "ticker": "FIGR", "return": 21.29, "absolute_move": 21.29 }

Response Fields

Notes on Data Behavior

• New selections are generated daily at 3:30 PM (America/New_York Time)
• Historical observations are stored point-in-time
• Once published, observations are not retroactively altered
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC

The Quant Galore Momentum Index provides the historical and live constituents of a rules-based, cross-sectional equity momentum strategy.

Each observation represents a stock included in the 10-stock monthly basket on a specific rebalance date, along with its rank within that basket. This dataset is designed for systematic traders, researchers, and allocators who want clean, point-in-time access to a maintained momentum index without reconstructing the full ranking pipeline.

Why it's useful

• Replicate or track the Quant Galore Momentum strategy
• Run independent performance attribution or turnover analysis
• Study cross-sectional momentum concentration effects
• Measure post-rebalance drift and decay
• Build overlays (options, hedging, leverage) on top of a rules-based equity core

Index Overview

• Universe: Deeply liquid U.S. equities with at least six consecutive weeks of listed weekly option expirations
• Construction: Cross-sectional momentum ranking
• Basket Size: Top 10 stocks
• Rebalance Frequency: Monthly
• Ranking: Highest momentum = rank 1

The dataset reflects the actual basket at that specific date, not a reconstructed or retroactively altered list.

Endpoint

GET /v1/quant-galore-momentum-index

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/quant-galore-momentum-index"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/quant-galore-momentum-index?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date (optional): return basket constituents for a single rebalance date (YYYY-MM-DD). Cannot be combined with range parameters.
• date_gte / date_lte / date_gt / date_lt (optional): filter by rebalance date range. Any logically valid combination is accepted.

Validation rules:

• date_lte must be ≥ date_gte
• date_lte must be > date_gt
• date_lt must be > date_gte

If no date filters are provided, all available historical observations are returned (subject to tier-based limits).

Response Format

{
  "count": 970,
  "data": [
    { "date": "2026-02-02", "ticker": "BE", "rank": 10 },
    { "date": "2026-02-02", "ticker": "IREN", "rank": 9 }
  ]
}

Response Fields

Notes on Data Behavior

• Constituents update monthly upon rebalance at 4:05 PM (America/New_York Time)
• Each rebalance date contains exactly 10 stocks
• Rankings are deterministic and stored historically
• Historical baskets remain fixed once published
• Results are ordered by date DESC
• Dates are returned in YYYY-MM-DD format
• Invalid date formats return a 400 response
• Mixing date with range parameters returns a 400

The S&P 500 0-DTE Strike Band dataset provides a daily, model-derived strike range representing the expected intraday price bounds for the S&P 500 index during the current trading session.

Each observation contains a lower and upper strike level that define the range in which the index is expected to remain with high probability through the close of the same-day (0-DTE) options cycle. The band is calculated using forward-looking implied probability distributions and broader market risk factors, and is designed to assist traders in strike selection and risk management for intraday option strategies.

All observations are point-in-time and stored historically. Once published, values are never retroactively altered, allowing the dataset to be used safely in systematic research and backtesting workflows.

Why it's useful

• Identify statistically informed strike levels for same-day SPX options
• Structure intraday spreads, condors, or volatility-selling strategies
• Quantify expected index movement using implied probability information
• Filter or validate discretionary strike selection decisions
• Analyze historical containment probabilities for intraday index ranges

Endpoint

GET /v1/spx-0dte-strike-band

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/spx-0dte-strike-band"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/spx-0dte-strike-band?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date: strike band for a single trading date (YYYY-MM-DD).
• date_gte / date_lte / date_gt / date_lt: filter by date range. Any logically valid combination is accepted.

If no date filters are provided, all available historical observations are returned (subject to tier-based limits).

Response Format

{
  "count": 1,
  "data": [
    {
      "date": "2026-03-05",
      "lower_strike": 6740,
      "upper_strike": 6880,
      "instrument": "SPX"
    }
  ]
}

Response Fields

Strike Band Definition

The lower_strike and upper_strikevalues represent the model-derived strike range within which the S&P 500 index is expected to remain through the close of the same-day options session. The band is calculated using forward-looking implied probability distributions, realized volatility data, and broader market risk factors. Strikes are rounded to the nearest listed SPX option increment.

Notes on Data Behavior

• New observations are published daily at 10:30 AM (America/New_York Time)
• Values are point-in-time and reflect information available at calculation time
• Historical strike bands remain fixed once published
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC

The S&P 500 Risk Regime dataset provides a daily, point-in-time binary classification of prevailing equity market conditions.

Each observation reflects whether the S&P 500 was classified as being in a risk-off (1) or risk-on (0) regime on that date. The dataset is designed for systematic traders and researchers who require a stable, reproducible market state signal for filtering, sizing, or regime-aware modeling.

Why it's useful

• Filter strategies during elevated volatility or selloff regimes
• Dynamically scale position size based on market conditions
• Improve risk-adjusted returns via regime-aware allocation
• Segment backtests into bull vs stress environments
• Study behavioral or factor performance across volatility states

Endpoint

GET /v1/sp500-risk-regime

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/sp500-risk-regime"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/sp500-risk-regime?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date (optional): return regime classification for a single date (YYYY-MM-DD).
• date_gte / date_lte / date_gt / date_lt (optional): filter by date range. Any logically valid combination is accepted.

If no date filters are provided, all available historical observations are returned (subject to tier-based limits).

Response Format

{
  "count": 522,
  "data": [
    { "date": "2026-02-23", "risk_regime": 1 }
  ]
}

Response Fields

Regime Definition

1 → Risk-Off: elevated volatility and/or stress conditions. Historically associated with defensive positioning and higher downside risk.

0 → Risk-On: lower volatility and constructive equity conditions. Historically associated with trend persistence and risk-seeking behavior.

The classification is derived from forward-looking implied volatility metrics and is stored as a fixed daily regime label. Historical values are not retroactively altered.

Notes on Data Behavior

• New observations are updated daily at 10:10 AM (America/New_York Time)
• Dates are returned as YYYY-MM-DD
• Values are point-in-time
• Historical regime labels remain fixed once published
• Results are ordered by date DESC

The IV/HV Premium dataset answers a single recurring question for every liquid US equity: are this name's options rich or cheap right now? For each ticker and trading day it pairs the annualized at-the-money implied volatility of the listed expiry nearest ~30 calendar days (iv) against the annualized 30-trading-day close-to-close realized volatility (hv).

From that pair it derives the volatility risk premium two ways, the spread (iv − hv) and the ratio (iv / hv, where > 1 = rich and < 1 = cheap), and adds daily cross-sectional ranks and z-scores so a value can be read both against the name's own history and against the rest of the universe that day.

Every past date is settled and fixed, so the series can be used in systematic research and backtesting without lookahead bias. Volatilities are annualized; notional_volume (underlying volume × VWAP) is carried as a liquidity reference.

Why it's useful

• Screen the universe for the richest or cheapest options by iv_hv_ratio on any given day
• Rank names cross-sectionally with the daily percentile and z-score fields for relative-value vol trades
• Size a vol-selling or vol-buying book by how far implied sits above or below realized
• Backtest premium-capture strategies on a point-in-time, no-lookahead history

Endpoint

GET /v1/iv-hv-premium

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/iv-hv-premium"
params = {
    "date": "2026-06-12",
    "min_ratio_rank": 0.9,
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/iv-hv-premium?date=2026-06-12&min_ratio_rank=0.9&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, all tickers are returned.
• date (optional): exact trading date (YYYY-MM-DD). Cannot be combined with date range parameters.
• min_iv_hv_ratio / max_iv_hv_ratio (optional, float): screen on the iv / hv ratio.
• min_ratio_rank (optional, float 0–1): floor on iv_hv_ratio_ranked; e.g. 0.9 returns the richest decile that day.
• only_final (optional, true/1/yes): return settled rows only. Default false.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-06-12",
      "ticker": "AAPL",
      "iv": 0.1795,
      "hv": 0.2333,
      "iv_hv_spread": -0.0538,
      "iv_hv_ratio": 0.769,
      "iv_ranked": 0.22,
      "hv_ranked": 0.61,
      "iv_hv_spread_ranked": 0.18,
      "iv_hv_ratio_ranked": 0.31,
      "iv_z": -0.42,
      "hv_z": 0.55,
      "iv_hv_spread_z": -0.60,
      "iv_hv_ratio_z": -0.48,
      "notional_volume": 8410000000,
      "notional_volume_ranked": 0.99,
      "notional_volume_z": 4.1,
      "days_to_exp": 31,
      "exp_date": "2026-07-17",
      "atm_strike": 290,
      "spot": 291.36,
      "is_final": 0,
      "last_updated": "2026-06-12 15:31:04"
    }
  ]
}

Notes on Data Behavior

• One row per ticker per trading date over a point-in-time liquid US-equity universe
• Today's row is provisional intraday (is_final = 0) and settled after the close (is_final = 1, ~16:30 ET)
• Volatilities are annualized; typical iv/hv ≈ 0.15–0.80
• Cross-sectional ranks and z-scores are computed across that day's universe
• Once a date settles, its values are fixed and not retroactively altered
• Results are ordered by date DESC, ticker ASC

The IV/HV Rank dataset answers is volatility high or low for this name?For each ticker and trading day it places the current ~30-day implied vol and 30-day realized vol within that name's own trailing 52-week (strict 252-observation) range, as both a 0–100 rank and a 0–100 percentile.

Rank measures position within the year's high–low band; percentile measures the share of the trailing year that traded below the current value:

• *_rank = (value − 52w_low) / (52w_high − 52w_low) × 100
• *_percentile = share of trailing-year observations below the current value × 100

The dataset is derived from the same iv/hv series as IV/HV Premium, over the same universe and update cadence. A ticker appears only once it has a full year of history; daily cross-sectional rank and z-score fields add context against the rest of the universe.

Why it's useful

• Find names whose implied vol is historically cheap (low IV Rank) or expensive (high IV Rank) for premium timing
• Compare IV Rank against HV Rank to spot where implied is stretched relative to a name's own realized regime
• Screen for high-percentile vol candidates with min_iv_percentile
• Build mean-reversion or breakout signals on a name-relative, point-in-time vol measure

Endpoint

GET /v1/iv-rank

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/iv-rank"
params = {
    "ticker": "AAPL",
    "min_iv_rank": 80,
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/iv-rank?ticker=AAPL&min_iv_rank=80&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, all tickers are returned.
• date (optional): exact trading date (YYYY-MM-DD). Cannot be combined with date range parameters.
• min_iv_rank / max_iv_rank (optional, float 0–100): screen on 52w IV Rank.
• min_hv_rank / max_hv_rank (optional, float 0–100): screen on 52w HV Rank.
• min_iv_percentile (optional, float 0–100): floor on 52w IV Percentile.
• only_final (optional, true/1/yes): return settled rows only. Default false.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-06-12",
      "ticker": "AAPL",
      "iv": 0.1795,
      "iv_rank": 31.4,
      "iv_percentile": 28.0,
      "iv_52w_high": 0.42,
      "iv_52w_low": 0.135,
      "iv_52w_median": 0.21,
      "hv": 0.2333,
      "hv_rank": 58.2,
      "hv_percentile": 61.0,
      "hv_52w_high": 0.39,
      "hv_52w_low": 0.11,
      "hv_52w_median": 0.20,
      "n_obs_52w": 252,
      "notional_volume": 8410000000,
      "iv_rank_cs_ranked": 0.34,
      "iv_rank_cs_z": -0.41,
      "hv_rank_cs_ranked": 0.62,
      "hv_rank_cs_z": 0.39,
      "is_final": 0,
      "last_updated": "2026-06-12 15:31:04"
    }
  ]
}

Notes on Data Behavior

• A ticker appears only once it has a full year (252 observations) of iv-hv-premium history
• Today's row is provisional intraday (is_final = 0) and settled after the close (is_final = 1, ~16:30 ET)
• Rank uses the high–low band; percentile uses the share of the trailing year below the current value
• Once a date settles, its values are fixed and not retroactively altered
• Results are ordered by date DESC, ticker ASC

The Vol-of-Vol Index answers whose volatility is most unstable? For each ticker and trading day it measures the coefficient of variation (standard deviation ÷ mean) of that name's own ~30-day implied vol and 30-day realized vol over a trailing 21 observations (~1 month). Higher values mean the name's volatility is itself more variable.

The measure is dimensionless, so it is directly comparable across names, and a daily cross-sectional ranking surfaces the most vol-unstable names on any given day. It is derived from the same iv/hv series as IV/HV Premium, over the same universe and update cadence.

The first ~month of each ticker's history is absent while the 21-observation window warms up.

Why it's useful

• Rank the universe by which names have the most unstable implied or realized vol on a given day
• Filter for stable-vol names (low vol-of-vol) when a strategy depends on a steady vol regime
• Flag names whose vol is churning ahead of catalysts or regime shifts
• Combine with IV/HV Premium and IV/HV Rank for a fuller picture of a name's vol behavior

Endpoint

GET /v1/vol-of-vol

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/vol-of-vol"
params = {
    "min_iv_vov_rank": 0.9,
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/vol-of-vol?min_iv_vov_rank=0.9&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, all tickers are returned.
• date (optional): exact trading date (YYYY-MM-DD). Cannot be combined with date range parameters.
• min_iv_vov / max_iv_vov (optional, float ≥ 0): screen on raw implied vol-of-vol.
• min_hv_vov / max_hv_vov (optional, float ≥ 0): screen on raw realized vol-of-vol.
• min_iv_vov_rank / min_hv_vov_rank (optional, float 0–1): daily percentile floor on the implied / realized vol-of-vol rank.
• only_final (optional, true/1/yes): return settled rows only. Default false.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-06-12",
      "ticker": "AAPL",
      "iv": 0.1795,
      "iv_vov": 0.084,
      "iv_mean_21": 0.1822,
      "iv_std_21": 0.0153,
      "hv": 0.2333,
      "hv_vov": 0.121,
      "hv_mean_21": 0.2210,
      "hv_std_21": 0.0267,
      "n_obs_vov": 21,
      "notional_volume": 8410000000,
      "iv_vov_cs_ranked": 0.41,
      "iv_vov_cs_z": -0.22,
      "hv_vov_cs_ranked": 0.73,
      "hv_vov_cs_z": 0.64,
      "is_final": 0,
      "last_updated": "2026-06-12 15:31:04"
    }
  ]
}

Notes on Data Behavior

• The first ~month of each ticker's history is absent while the 21-observation window warms up
• Vol-of-vol is the coefficient of variation (std ÷ mean), so it is dimensionless and comparable across names
• Today's row is provisional intraday (is_final = 0) and settled after the close (is_final = 1, ~16:30 ET)
• Once a date settles, its values are fixed and not retroactively altered
• Results are ordered by date DESC, ticker ASC

The Earnings Implied vs Realized dataset is a per-ticker track record of how each company's earnings move was priced versus how it actually moved. For every earnings event, it captures the pre-earnings at-the-money straddle (the market's implied move) and compares it to the realized post-earnings move.

Alongside each event it carries running, point-in-time statistics for the ticker: how often the straddle over- or under-priced the move, and the trailing averages of implied move, realized move, and over/under-pricing. This answers the recurring question: does this name usually over- or under-price its earnings?

All observations are stored historically and remain fixed once the post-earnings session has resolved, so the dataset can be used safely in systematic research and backtesting without lookahead bias.

Why it's useful

• Answer “does TICKER usually over- or under-price its earnings?” with a running hit rate
• Rank or screen names by their straddle over/under-pricing tendency ahead of an earnings season
• Study the implied-vs-realized edge for earnings vol selling or buying
• Backtest earnings strategies conditioned on a ticker's historical move ratio and hit rate
• Compare straddle-implied moves to consensus EPS surprises and realized reactions

Endpoint

GET /v1/earnings-move-history

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/earnings-move-history"
params = {
    "ticker": "AAPL",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/earnings-move-history?ticker=AAPL&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, events across all tickers are returned.
• date (optional): earnings date filter (YYYY-MM-DD). Cannot be combined with date range parameters.

If no date filters are provided, all available historical events are returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-01-29",
      "ticker": "AAPL",
      "time": "amc",
      "capture_date": "2026-01-29",
      "reaction_date": "2026-01-30",
      "spot": 232.14,
      "atm_strike": 232.5,
      "exp_date": "2026-01-30",
      "days_to_exp": 1,
      "atm_call_px": 4.85,
      "atm_put_px": 4.70,
      "straddle": 9.55,
      "implied_move_pct": 4.11,
      "implied_move_dollars": 9.55,
      "atm_iv": 0.68,
      "realized_return_pct": -2.34,
      "realized_abs_move_pct": 2.34,
      "over_under_pct": 1.77,
      "move_ratio": 0.57,
      "overpriced": true,
      "eps_estimated": 2.35,
      "eps_actual": 2.41,
      "notional_volume": 184320000,
      "n_events_to_date": 18,
      "hit_rate_to_date": 0.67,
      "avg_implied_move_to_date": 4.42,
      "avg_realized_abs_to_date": 3.61,
      "avg_over_under_to_date": 0.81
    }
  ]
}

Notes on Data Behavior

• Updated daily after the market close (EOD)
• For an event whose post-earnings session has not yet closed, the realized fields (realized_return_pct, realized_abs_move_pct, over_under_pct, move_ratio, overpriced) are not yet populated
• Running statistics (n_events_to_date, hit_rate_to_date, the trailing averages) are point-in-time: they reflect only events up to and including each row
• Once an event resolves, its values are fixed and not retroactively altered
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC, ticker ASC

The Dilution dataset captures U.S. equity dilution risk at the moment it enters the market. It is a point-in-time record of S-1 registration statements, enriched with market context and lifecycle tracking, designed for traders and researchers who need to identify and manage dilution-driven risk with precision.

Each record represents a filing as it was known on the filing date, labeled for its dilutive impact and later resolved as the filing becomes effective or is withdrawn.

Why it's useful

• Identify dilution risk at inception, not in hindsight
• Filter or size exposure around secondary offerings and resale pressure
• Build short-biased or risk-aware strategies in small- and mid-cap equities
• Study post-filing outcomes, including time-to-effectiveness or withdrawal

Endpoint

GET /v1/dilution

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/dilution"
params = {
    "date_gte": "2026-02-06",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/dilution?date_gte=2026-02-01&api_key=alp_abc123"

Request Parameters

• api_key (optional): your API key. Enables full dataset access and reduces per-request limits. If omitted, a limited subset is returned.
• ticker (optional): stock ticker filter (case-insensitive, exact match). If omitted, data across all tickers are returned.
• date (optional): filing date filter (YYYY-MM-DD). If omitted, a ticker must be provided.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-02-02",
      "filing_timestamp": "2026-02-02T16:05:51-05:00",
      "ticker": "IVDA",
      "company_name": "Iveda Solutions, Inc.",
      "market_cap_at_filing": 2557918.88,
      "dilutive": 1,
      "resale": 0,
      "shares_offered": 5434782.0,
      "became_effective": 0,
      "effective_date": "",
      "days_to_effective": null,
      "offering_withdrawn": 0,
      "withdrawal_date": "",
      "days_to_withdrawal": null,
      "root_file_number": "333-293126",
      "accession_number": "0001493152-26-004743",
      "filing_url": "https://www.sec.gov/Archives/edgar/data/1397183/000149315226004743/0001493152-26-004743-index.htm",
      "last_updated": "2026-02-02 23:01:15.364519-05:00"
    }
  ]
}

Core Filing Fields (Point-in-Time)

Market Context (Point-in-Time)

Dilution Classification

Lifecycle Resolution

Metadata

Notes on Data Behavior

• Records are never removed once published
• Point-in-time fields remain fixed
• Only lifecycle fields update as events occur
• All dates are returned as YYYY-MM-DD strings

The Shelf Registrations dataset is a point-in-time capacity ledger of S-3 and F-3 shelf registration statements. A shelf registration is a company's pre-approval to sell securities in the future: it says how much the company may sell, in what forms, before any actual sale happens. Every base filing, amendment, and automatic (WKSI) shelf is one row, labeled with the registered dollar capacity, the securities covered, and the resale flag.

Each row is then tracked forward: when the shelf became effective (the SEC's EFFECT notice, or effective on filing for automatic shelves), how many days that took, an estimated expiry three years from effectiveness, and any 424B5 takedown activity linked by file number. Market cap and shares outstanding as of the session before the filing are attached for context, so capacity can be compared to company size without a second lookup.

Important framing: authorization is not issuance. This dataset records what a shelf registers, not what was sold. It is the upstream signal behind dilution screeners, not a record of completed offerings.

Why it's useful

• Screen for fresh shelf capacity filed in recent weeks, before any offering prices
• Compare capacity_amount to market_cap_at_filing to find small caps with outsized authorized dilution
• Separate primary dilution risk (shelf_type=new, is_resale=0) from resale registrations and routine WKSI shelves
• Study the timeline from filing to effectiveness to first takedown
• Pull one ticker's full shelf history as background for a position

Endpoint

GET /v1/capital/shelf-registrations

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/capital/shelf-registrations"
params = {
    "ticker": "PLUG",
    "date_gte": "2026-06-01",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/capital/shelf-registrations?ticker=PLUG&date_gte=2026-06-01&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, filings across all tickers are returned.
• cik (optional): SEC CIK number, digits only.
• form (optional): exact form type. One of S-3, F-3, S-3/A, F-3/A, S-3ASR, F-3ASR.
• shelf_type (optional): one of new, amendment, automatic.
• date (optional): filing date filter (YYYY-MM-DD). Cannot be combined with date range parameters.
• updated_since (optional, YYYY-MM-DD): only rows whose last_updated is on or after this date. Useful for catching EFFECT and takedown refreshes without re-pulling history.
• cursor_date / cursor_accession (optional, together): keyset pagination cursor. Pass the date and accession_number from a previous response's next_cursor to fetch the next page. Both must be provided or neither.

If no date filters are provided, all available historical filings are returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format and filter on the filing date. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "record_id": "0001140361-26-028514",
      "date": "2026-08-14",
      "filing_timestamp": "2026-08-14 17:12:44",
      "ticker": "PLUG",
      "cik": "1093691",
      "company_name": "Plug Power Inc.",
      "accession_number": "0001140361-26-028514",
      "form": "S-3",
      "file_number": "333-281204",
      "shelf_type": "new",
      "capacity_amount": 1000000000.0,
      "securities": "common stock, preferred stock, debt securities, warrants",
      "is_well_known_seasoned": 0,
      "is_resale": 0,
      "became_effective": 1,
      "effective_at": "2026-08-21",
      "days_to_effective": 7,
      "expiry_estimate": "2029-08-21",
      "takedown_count": 0,
      "first_takedown_at": null,
      "market_cap_at_filing": 1284000000.0,
      "outstanding_shares_at_filing": 812500000,
      "filing_url": "https://www.sec.gov/Archives/edgar/data/1093691/000114036126028514/0001140361-26-028514-index.htm",
      "refused": 0,
      "last_updated": "2026-08-22 11:20:05"
    }
  ]
}

Notes on Data Behavior

• New filings are picked up nightly after the EDGAR filing day closes; effectiveness (EFFECT) and takedown status are refreshed daily
• Authorization is not issuance. capacity_amount is what the shelf registers, not what was sold; takedown_count is linkage evidence, not a usage ledger
• Automatic (WKSI) shelves and other indeterminate registrations have capacity_amount = null by design, never a guessed number
• Rows where the extraction model refused to label the filing are still served with refused = 1 and NULL extraction fields; the filing event itself is real
• Amendments are separate rows (shelf_type = amendment), not merged into the base filing's row
• expiry_estimate is an estimate (effectiveness plus 3 years); actual expiry can differ under Rule 415(a)(5)/(6) transition rules or early replacement
• Takedown counts are refreshed for shelves filed in the trailing 400 days; older shelves' counts freeze at their last refresh
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC, accession_number ASC
• Responses are capped at 50,000 rows. When has_more is true, pass next_cursor's date and accession_number back as cursor_date and cursor_accession to fetch the next page

The De-SPAC Events dataset provides a point-in-time record of completed de-SPAC transactions, identifying when special purpose acquisition companies (SPACs) formally consummate their business combinations and transition into operating companies.

Each observation represents a confirmed de-SPAC completion event derived from SEC filings (typically Super 8-K disclosures). These events mark the structural transition from a blank check company into a publicly traded operating entity.

All observations are stored historically and remain fixed once published, allowing the dataset to be used safely in systematic research and backtesting workflows without lookahead bias.

Why it's useful

• Identify newly public companies emerging from SPAC mergers
• Build event-driven strategies around post de-SPAC performance
• Study structural inefficiencies following SPAC business combinations
• Track regime shifts in liquidity, float, and ownership post-merger
• Construct short-bias or mean-reversion strategies targeting de-SPAC cohorts
• Backtest systematic workflows conditioned on corporate transition events

Endpoint

GET /v1/de-spac-events

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/de-spac-events"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/de-spac-events?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date (optional): return observations for a single date (YYYY-MM-DD).
• date_gte / date_lte / date_gt / date_lt (optional): filter by date range. Any logically valid combination is accepted.

If no date filters are provided, all available historical observations are returned.

Response Format

{
  "count": 1,
  "data": [
    {
      "date": "2026-03-20",
      "ticker": "MRLN",
      "filing_url": "https://www.sec.gov/Archives/edgar/data/0000000000/...",
      "confidence": 0.97,
      "evidence_quote": "On March 18, 2026, the Company consummated the business combination...",
      "new_company_name": "Marlin Technologies, Inc.",
      "prior_spac_name": "Aurora Acquisition Corp.",
      "new_ticker": "MRLN",
      "warrant_ticker": "MRLNW",
      "exchange": "NASDAQ",
      "closing_date": "2026-03-18",
      "trading_commencement_date": "2026-03-19",
      "effective_date": "2026-03-18",
      "target_business_name": "Marlin Technologies, LLC",
      "business_description": "Maritime autonomy and marine sensor systems.",
      "sponsor_name": "Aurora Sponsor LLC",
      "source_form_types": "8-K,424B3,8-A12B",
      "filing_count": 4,
      "event_status": "completed",
      "redemption_shares": 18200000,
      "redemption_amount_usd": 187460000,
      "trust_remaining_usd": 42300000,
      "pipe_amount_usd": 125000000,
      "gross_proceeds_usd": 167300000,
      "pro_forma_shares_outstanding": 96400000,
      "enterprise_value_usd": 1180000000,
      "equity_value_usd": 985000000
    }
  ]
}

Response Fields: Core

Response Fields: Event identity & status

Response Fields: Event economics

Dataset Definition

Each observation corresponds to a confirmed de-SPAC completion event, identified through systematic parsing of SEC filings. A de-SPAC event is defined as the consummation of a business combination in which a SPAC merges with or acquires an operating company and ceases to function as a shell entity.

Events are primarily sourced from filings that explicitly indicate completion of the transaction, including language such as:

• “consummated the business combination”
• “completion of the business combination”
• “closed the business combination”

Additional confirming signals may include change in shell-company status, name change following the transaction, and commencement of trading under a new ticker. Only filings that clearly indicate completion (not proposals or pending transactions) are included.

Notes on Data Behavior

• Events are recorded using the filing date of the de-SPAC completion disclosure
• This date may occur shortly after the first day of trading under the new ticker
• Observations are point-in-time and reflect only information available at the time of filing
• Historical records are not retroactively altered
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC

The Corporate Default Events dataset provides a historical, point-in-time log of public-company default events, labeled from SEC filing text and normalized into a clean event feed.

Each observation represents a date where a company was flagged as being in default status (is_default = 1), along with the associated ticker and the SEC filing URL used as source evidence.

The dataset is designed for systematic traders and researchers who need a reproducible event series for distress screens, event studies, short baskets, and credit-risk proxies.

Why it's useful

• Build distress / default event studies and measure post-event drift
• Screen for credit-like equity behavior without requiring CDS data
• Create short candidate universes based on documented default status
• Filter long strategies to avoid names entering default or restructuring conditions
• Train ML models using default events as labels or regime triggers

Endpoint

GET /v1/corporate-default-events

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/corporate-default-events"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/corporate-default-events?api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date (optional): return events for a single date (YYYY-MM-DD). Cannot be combined with range parameters.
• date_gte / date_lte / date_gt / date_lt (optional): filter events by date range. Any logically valid combination is accepted.

Validation rules:

• date_lte must be ≥ date_gte
• date_lte must be > date_gt
• date_lt must be > date_gte

If no date filters are provided, all available historical observations are returned (subject to tier-based limits).

Response Format

{
  "count": 517,
  "data": [
    {
      "event_date": "2026-02-09",
      "ticker": "ESGH",
      "filing_url": "https://www.sec.gov/Archives/edgar/data/1883835/000152013826000054/0001520138-26-000054-index.htm",
      "confidence": 0.93,
      "evidence_quote": "The Company failed to make the interest payment due on the Notes...",
      "event_type": "missed_interest_payment",
      "obligation_name": "8.5% Senior Secured Notes due 2028",
      "obligation_type": "senior_secured_notes",
      "creditor_name": "Wilmington Trust, N.A. (as Trustee)",
      "principal_outstanding_usd": 145000000,
      "amount_accelerated_usd": null,
      "missed_payment_amount_usd": 6162500,
      "default_date": "2026-02-02",
      "grace_period_end_date": "2026-03-04",
      "acceleration_declared": false
    }
  ]
}

Response Fields

Notes on Data Behavior

• Results are filtered to default-only events (is_default = 1)
• Dates are returned as YYYY-MM-DD
• Results are ordered by event_date DESC
• Invalid date format returns a 400 with the expected format
• If date is combined with any date range parameter, the API returns a 400

The SEC Trading Suspensions dataset covers every trading suspension the SEC has ordered under Section 12(k) of the Securities Exchange Act since 1995: the release that stopped the quote, the issuers it names, the exact suspension window (start and end date plus the ET time of day), the reason the Commission cited normalized to a four-value taxonomy, and the first NYSE session on which trading may legally resume.

Orders that name many issuers are exploded to one row per issuer, so a single 55-company delinquency order returns 55 rows sharing a release_number. Row counts therefore run far above order counts (4,736 rows across 1,340 releases); use issuer_count and issuer_index to collapse back to order level.

A suspension is a maximum 10-business-day stop, not a delisting. And resumption_at is when trading may resume, not when it did: Rule 15c2-11 bars quotations until a market maker requalifies the security, and many suspended names never quote again.

Why it's useful

• Answer “was this name ever suspended by the SEC?” in one call, by ticker, CIK, or issuer name
• Screen microcap and OTC universes for terminal-risk history before taking a position
• Run event studies around suspension starts and permitted resumption dates
• Isolate the modern pump-and-dump regime with cited_reason=market_manipulation
• Reconstruct which names were untradeable on any given date with active_on
• Verify every row against the primary source via the linked SEC order document

Endpoint

GET /v1/market-structure/sec-suspensions

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/market-structure/sec-suspensions"
params = {
    "cited_reason": "market_manipulation",
    "date_gte": "2020-01-01",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/market-structure/sec-suspensions?cited_reason=market_manipulation&date_gte=2020-01-01&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): exact ticker match, case-insensitive input. Ticker is NULL on rows where the order states no symbol, so name-only rows will not match.
• cik (optional): SEC CIK number, digits only. The survivorship-proof identifier for dead shells; sparse before 2016.
• release_number (optional): Exchange Act release id. Both 34-92362 and bare 92362 are accepted; a bare number is prefixed with 34-. Returns every issuer row of that order.
• cited_reason (optional): one of delinquent_filings, market_manipulation, accuracy_adequacy_of_information, other. Any other value returns a 400 with the expected list.
• issuer_name (optional): case-insensitive substring match on the issuer name. The only handle on rows with no ticker or CIK.
• has_resumed (optional): true / false / 1 / 0. false isolates issuers under an active suspension right now.
• single_issuer (optional): true / false / 1 / 0. true keeps only one-issuer orders (mostly the modern manipulation cases); false keeps only multi-issuer bulk orders.
• active_on (optional): YYYY-MM-DD. Returns rows whose suspension window covers that day (suspended_at <= active_on <= suspension_end_at). This is a point-in-time universe cut the release-date filters cannot express.
• date (optional): release date filter (YYYY-MM-DD). Cannot be combined with date range parameters.
• updated_since (optional): YYYY-MM-DD, on last_updated. Incremental sync; the resumption sweep rewrites has_resumed, resumption_at, and the day counts on existing rows.

If no date filters are provided, all available historical rows are returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format and filter on date, the release date. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "record_id": "34-103412#0",
      "release_number": "34-103412",
      "date": "2026-06-11",
      "issuer_name": "Meridian Bio Innovations, Inc.",
      "ticker": "MRBI",
      "cik": "1874550",
      "listing_venue": "OTC Link",
      "issuer_index": 0,
      "issuer_count": 1,
      "cited_reason": "market_manipulation",
      "cited_reason_detail": "questions regarding recent unusual and unexplained market activity in the company's stock",
      "suspended_at": "2026-06-12",
      "suspension_start_time_et": "04:00",
      "suspension_end_at": "2026-06-25",
      "suspension_end_time_et": "23:59",
      "resumption_at": "2026-06-26",
      "suspension_business_days": 10,
      "days_to_resumption": 14,
      "has_resumed": 1,
      "order_url": "https://www.sec.gov/litigation/suspensions/2026/34-103412.pdf",
      "see_also_url": "https://www.sec.gov/litigation/suspensions/2026/34-103412-o.pdf",
      "last_updated": "2026-06-26 12:10:04"
    }
  ]
}

Notes on Data Behavior

• Updated daily from SEC.gov; new releases are picked up overnight, and a separate daily sweep flips has_resumed and refreshes resumption_at and the day counts
• A Section 12(k) suspension is a maximum 10-business-day trading stop, not a delisting; the security may still exist and trade again afterward
• resumption_at is permission, not fact: it marks the first session trading may legally resume, but Rule 15c2-11 bars quotations until a market maker requalifies the security, and many names never quote again
• ticker is NULL on rows where the order states no symbol, and cik is sparse before roughly 2016; issuer_name is the only identifier present on every row
• suspension_start_time_et matters for event studies: most suspensions start at 09:30 (the open), but modern manipulation orders start at 04:00 (pre-market), which changes what the last tradeable print was
• Multi-issuer orders are exploded to one row per issuer; deduplicate on record_id or (release_number, issuer_index), never on release_number alone
• Every served row carries a parsed suspension window and a taxonomy value; rows the labeling pipeline declined are never served
• has_resumed is served as 0/1; the input parameter also accepts true/false
• Results are ordered by date DESC, release_number ASC, issuer_index ASC, a stable total order
• Responses are paginated at 50,000 rows (the full corpus fits in one page today). When more data is available, has_more is true and next_cursor returns {date, release_number, issuer_index}; pass all three back as cursor_date, cursor_release_number, and cursor_issuer_index to fetch the next page
• Dates are returned as YYYY-MM-DD

The Cyber Incidents dataset tracks material cybersecurity incident disclosures: every Form 8-K filed under Item 1.05, the disclosure item created by the SEC's 2023 cyber rule, plus its 8-K/A amendments. One row per filing. Item 1.05 has existed only since 2023-12-18 and material-incident disclosures are rare, so the corpus is small by nature: roughly 80 filings is the entire population, not a coverage gap.

Each row keeps four date roles distinct: incident discovered (incident_discovered_date), materiality determined (materiality_determined_date), disclosed (disclosed_date), and amended (amended_date). Each extracted date carries a companion precision enum (day / month / quarter / year / unstated). On top of the dates sit the derived intervals (investigation time, compliance time, total latency), an attack-type taxonomy, seven three-state incident flags, and amendment linkage back to the original 8-K.

Flags are three-state: 1 means the filing states yes, 0 means the filing states no, and nullmeans the filing does not say. “Did not say” and “said no” are different disclosure facts and are never collapsed.

Why it's useful

• Run event studies on breach disclosures with the exact EDGAR acceptance timestamp (before or after the close)
• Screen incidents by attack type, data compromise, operational disruption, or vendor origin
• Measure disclosure latency: discovery to determination to disclosure, per filing
• Track how an incident's story changed across its 8-K/A amendments
• Study the complete population of Item 1.05 filings since the rule took effect

Endpoint

GET /v1/regulatory/cyber-incidents

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/regulatory/cyber-incidents"
params = {
    "attack_type": "ransomware",
    "is_amendment": "0",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/regulatory/cyber-incidents?attack_type=ransomware&is_amendment=0&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). A few filings have no listed ticker and are only reachable by cik.
• cik (optional): SEC CIK number, digits only with no zero-padding (e.g. 310764). The only identifier present on every row.
• is_amendment (optional): 1 = 8-K/A amendments only, 0 = original 8-Ks only.
• attack_type (optional): one of data-breach, unauthorized-access, ransomware, business-email-compromise, other, unstated. Any other value returns 400.
• amended_flag (optional): 1 = originals that were later amended, 0 = originals that were not. Amendment rows carry null here and are excluded by either value.
• data_compromised_flag (optional): 1 = filing states data was compromised, 0 = filing states it was not. Rows where the filing is silent (null) are matched by neither value.
• operations_disrupted_flag (optional): 1 or 0, same three-state behavior.
• third_party_incident_flag (optional): 1 or 0, same three-state behavior. Screens for incidents that originated at a vendor or third party.
• refused (optional): 0 = labeled rows only, 1 = rows where the labeler declined the filing text.
• date (optional): exact disclosure date (YYYY-MM-DD). Cannot be combined with date range parameters.
• updated_since (optional): YYYY-MM-DD, filters on last_updated. Returns rows touched by the amendment-linkage sweep since that date.
• cursor_date + cursor_accession (optional): keyset pagination cursor. Both must be provided together.

All filters are optional and AND-combined. Date filters act on date, which is the disclosure date: the EDGAR filing date of this filing. It equals disclosed_date on originals and amended_dateon amendments. If no date filters are provided, all filings are returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "record_id": "0001104659-26-061234",
      "date": "2026-05-12",
      "filing_timestamp": "2026-05-12T17:05:12-04:00",
      "ticker": "ACME",
      "cik": "1234567",
      "company_name": "Acme Industrial Corp.",
      "accession_number": "0001104659-26-061234",
      "form": "8-K",
      "is_amendment": 0,
      "items_reported": "1.05,9.01",
      "event_date_reported": "2026-05-08",
      "incident_discovered_date": "2026-05-02",
      "incident_discovered_precision": "day",
      "materiality_determined_date": "2026-05-08",
      "materiality_determined_precision": "day",
      "disclosed_date": "2026-05-12",
      "amended_date": null,
      "incident_description": "Ransomware attack encrypted portions of the company's internal IT systems and disrupted order processing.",
      "attack_type": "ransomware",
      "third_party_incident_flag": null,
      "systems_affected": "internal IT systems and order processing applications",
      "data_compromised_flag": 1,
      "operations_disrupted_flag": 1,
      "materiality_basis": "expected impact on results of operations from disrupted order fulfillment",
      "containment_stated_flag": 1,
      "systems_restored_flag": null,
      "investigation_ongoing_flag": 1,
      "law_enforcement_notified_flag": 1,
      "amendment_reason": null,
      "days_discovery_to_determination": 6,
      "days_determination_to_disclosure": 4,
      "days_discovery_to_disclosure": 10,
      "original_accession_number": null,
      "original_disclosed_date": null,
      "days_original_to_amendment": null,
      "amended_flag": 1,
      "amendment_count": 1,
      "latest_amendment_date": "2026-06-02",
      "market_cap_at_filing": 2140000000.0,
      "outstanding_shares_at_filing": 51300000.0,
      "filing_url": "https://www.sec.gov/Archives/edgar/data/1234567/000110465926061234/0001104659-26-061234-index.htm",
      "refused": 0,
      "last_updated": "2026-06-02"
    }
  ]
}

Notes on Data Behavior

• Updated daily from SEC EDGAR by a nightly pipeline (discovery, labeling, projection, then an amendment-linkage sweep)
• Three-state flags (data_compromised_flag, operations_disrupted_flag, third_party_incident_flag, containment_stated_flag, systems_restored_flag, investigation_ongoing_flag, law_enforcement_notified_flag) are 1 = filing says yes, 0 = filing says no, null = filing does not say. Filtering flag=1 returns only stated-yes rows and flag=0 only stated-no rows; silent rows match neither, so the two filtered counts will not sum to the unfiltered count
• is_amendment vs amended_flag: is_amendment is structural (this filing IS an 8-K/A); amended_flag is a property of an ORIGINAL (this 8-K has since been amended). amended_flag and amendment_count are null on amendment rows because they describe an original; null there does not mean never amended
• Imprecise extracted dates are normalized to the first day of the stated period (a month-precision date becomes the 1st of that month). Filter on the companion precision column if you need day-level precision
• days_determination_to_disclosure is measured in calendar days, while the SEC's Item 1.05 deadline is four business days. Do not read a value above 4 as a compliance violation
• Rows with refused = 1 are served with null extracted fields: the labeler declined the filing text, so the nulls are policy, not silence. The disclosure event itself is still real and the row is never hidden
• Expected sparsity, not gaps: materiality_determined_date is filled on roughly 14% of rows (many filings never state one), so both intervals that depend on it are equally sparse. incident_discovered_date is filled on roughly 83% of rows and market_cap_at_filing on roughly 79%
• Amendments are separate rows joined back to their original via original_accession_number. An amendment may legitimately have null linkage when the original was filed under a different 8-K item
• The linkage sweep rewrites original_accession_number, amended_flag, amendment_count, latest_amendment_date, and days_original_to_amendment on rows that were already served. Cached clients should poll updated_since on last_updated, not only date_gte
• Results are ordered by date DESC, accession_number ASC
• Cursor pagination: when more rows remain, the response includes has_more: true and a next_cursor object; pass its values back as cursor_date and cursor_accession (both required together)
• The corpus is small by design: Item 1.05 exists only from 2023-12-18 and material-incident disclosures are rare, so roughly 80 filings is the entire population

The Crypto Enforcement dataset is a normalized record of US digital-asset enforcement actions brought by the SEC (litigation releases and administrative proceedings), the CFTC (enforcement press releases), and the DOJ (criminal announcements), from 2024 onward. Every action is exploded to one row per named respondent, so a complaint against three defendants returns three rows sharing one action_key.

Each row carries what was alleged (multi-category), which tokens and assets were involved, which statutes were cited, what monetary relief was ordered, whether the matter settled, and follow-up linkage that chains successive actions by the same agency against the same respondent (complaint to consent order, indictment to guilty plea).

Dates are two-tier: published_dateis structural (the date the agency published the release, taken from the agency's own index and never inferred), while action_dateis extracted from the document's own words and carries an explicit action_date_precision.

Why it's useful

• Track the regulatory-pressure regime for crypto: which agency is active, against what conduct, and how it changes over time
• Pull every action against one party with respondent_key and follow a matter through its stages via the follow-up chain
• Screen actions by allegation category (fraud, unregistered offering, market manipulation, AML/BSA, sanctions, and more)
• Filter by asset named in the document, settlement status, or size of monetary relief
• Event-study listed issuers when a document itself names one (listed_issuer_ticker)

Endpoint

GET /v1/crypto/enforcement

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/crypto/enforcement"
params = {
    "agency": "sec",
    "allegation": "fraud",
    "date_gte": "2026-06-01",
    "date_lte": "2026-06-30",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/crypto/enforcement?agency=sec&allegation=fraud&date_gte=2026-06-01&date_lte=2026-06-30&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• date (optional): exact published_date filter (YYYY-MM-DD). Cannot be combined with date range parameters.
• updated_since (optional): YYYY-MM-DD, compared against last_updated. Returns rows touched since that date, including rows updated by the follow-up sweep.
• action_key (optional): exact action id (e.g. sec-lr:LR-26456). Returns every respondent row of one action (1 to 22 rows).
• record_id (optional): exact row id (<action_key>#<respondent_index>). Returns exactly one row.
• agency (optional): which agency brought the action. One of sec, cftc, doj. Filters source_agency.
• source_index (optional): document kind. One of litigation-release, administrative-proceeding, press-release.
• action_type (optional): one of civil_complaint, administrative_proceeding, settled_order, criminal_indictment, criminal_plea, trial_verdict, other.
• action_date_precision (optional): one of day, month, quarter, year, unstated. The escape hatch for consumers that need true day precision on action_date.
• respondent (optional): case-insensitive substring search over respondent_name and respondent_key (e.g. bankman).
• respondent_key (optional): exact match on the normalized name key. The “every action against this party” call, and the grouping the follow-up sweep itself uses.
• respondent_kind (optional): person or company. Rows with a null kind (the document did not say) are excluded by either value.
• allegation (optional): one of fraud, unregistered_offering, unregistered_exchange_or_broker, market_manipulation, aml_bsa, sanctions, misappropriation, other. Matches the category anywhere in allegation_categories.
• primary_allegation (optional): same enum as allegation, but matches the leading theory only.
• asset (optional): case-insensitive substring over the raw assets_involved list. A substring rather than an exact element match, because the list holds unnormalized document literals (Bitcoin, bitcoin, and BTC all occur).
• min_monetary_relief / max_monetary_relief (optional): numeric bounds on monetary_relief_usd. Both implicitly drop rows where relief is null (SQL comparison semantics); use has_monetary_relief for the null-safe question.
• has_monetary_relief (optional): 1 = a dollar amount was stated, 0 = none stated.
• settled (optional): three-state, string-valued. true = the document says settled, false = the document says not settled, unknown = the document did not say (settled_flag IS NULL).
• is_followup (optional): 0 or 1. 1 = this action follows an earlier action by the same agency against the same respondent.
• has_followup (optional): 0 or 1. 1 = a later action in the chain exists (followup_action_key is set).
• cursor_published_date, cursor_action_key, cursor_respondent_index (optional): pagination cursor. Provide all three (from a previous response's next_cursor) or none; a partial cursor returns 400.

All filters are optional and AND-combined. Invalid enum values return a 400 with the expected values. The producer-internal names served_model, prefilter_terms, refused, and is_crypto_related are rejected with a 400 rather than silently ignored.

Date Filtering

All dates must be provided in YYYY-MM-DD format and filter published_date. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "record_id": "sec-lr:LR-26312#1",
      "action_key": "sec-lr:LR-26312",
      "source_agency": "sec",
      "source_index": "litigation-release",
      "release_number": "LR-26312",
      "file_number": null,
      "published_date": "2026-06-18",
      "action_date": "2026-06-17",
      "action_date_precision": "day",
      "days_action_to_publication": 1,
      "action_type": "civil_complaint",
      "respondent_index": 1,
      "respondent_count": 2,
      "respondent_name": "Meridian Digital Capital LLC",
      "respondent_kind": "company",
      "respondent_key": "meridian digital capital",
      "assets_involved": ["Bitcoin", "ETH"],
      "asset_count": 2,
      "allegation_categories": ["fraud", "unregistered_offering"],
      "allegation_count": 2,
      "primary_allegation": "fraud",
      "statutes_cited": [
        "Securities Act Section 17(a)",
        "Exchange Act Section 10(b)"
      ],
      "monetary_relief_usd": 4500000.0,
      "monetary_relief_basis": "$3.2 million in disgorgement and $1.3 million in civil penalties",
      "has_monetary_relief": 1,
      "settled_flag": null,
      "listed_issuer_name": null,
      "listed_issuer_ticker": null,
      "summary": "The SEC charged a crypto asset manager and its founder with defrauding investors in an unregistered digital asset offering.",
      "title": "SEC Charges Crypto Asset Manager With Fraudulent Digital Asset Offering",
      "document_url": "https://www.sec.gov/litigation/litreleases/lr-26312",
      "see_also_url": null,
      "prior_action_key": null,
      "is_followup": 0,
      "followup_action_key": null,
      "followup_count": 0,
      "days_to_followup": null,
      "last_updated": "2026-06-18 06:12:44"
    }
  ]
}

Notes on Data Behavior

• monetary_relief_usd is not deduplicated across respondents. The same amount repeats on every respondent row of one action (one CFTC action carries $12.7bn on both its FTX Trading and Alameda Research rows), so summing monetary_relief_usd across rows double-counts. Aggregate over DISTINCT (action_key, monetary_relief_usd) pairs instead.
• monetary_relief_usd sums heterogeneous relief types (penalty, disgorgement, prejudgment interest, restitution, forfeiture) because the three agencies report the mix differently. monetary_relief_basis records what the number covered. Amounts describing the size of the scheme are excluded.
• settled_flag is three-state: 1 = the document said yes, 0 = it said no, null= it did not say. Roughly a quarter of rows are null; never collapse null into “did not settle”.
• respondent_key is a name-string normalization, not an entity resolution: different parties with the same name share a key, and the same party under a different name does not.
• Nothing links across agencies, by design. The same matter can appear once per agency (an SEC complaint and a DOJ indictment over the same conduct are separate actions), and followup_action_key chains stages within one agency only.
• assets_involved, allegation_categories, and statutes_cited are served as real JSON arrays; an empty list is [] and never null. Asset strings are unnormalized document literals.
• Coverage starts 2024-01-08; earlier actions are out of scope
• Results are ordered by published_date DESC, action_key ASC, respondent_index ASC, which keeps a multi-respondent action's rows contiguous and in the document's own listing order
• When more data is available, the response includes has_more: true and a next_cursor object; pass its three values back as the cursor parameters to fetch the next page
• Updated daily from the agencies' own indexes, with a separate daily sweep that maintains the follow-up linkage; use updated_since to catch rows the sweep has re-linked

The FDA Response Events dataset tracks adverse FDA regulatory actions as disclosed by US-listed companies in SEC Form 8-K filings: Complete Response Letters (the FDA reviewed a drug application and declined to approve it in its current form), full and partial clinical holds (the FDA ordered a trial paused, entirely or in part), and Refuse-to-File letters (the FDA declined to even begin review of an application).

Each row is one filing, not one event. A single FDA action can produce up to three filings over its life: the initial_disclosure, later follow_up_update filings, and a final resolution filing (hold lifted, resubmission accepted, approval). Rows about the same drug program are linked to each other via the prior_event_* and resolution_*columns, so an original disclosure row also answers “was this ever resolved, and how long did it take?”

Every event carries a graded severity together with the evidence flags the grade was derived from (new trial required, manufacturing related, resubmission path stated, hold lifted), the drug program and indication affected, the development phase, both date roles (when the FDA acted vs when the company disclosed it), and market cap at the time of filing. By default only classified FDA events are returned; the corpus is built by a recall-first full-text sweep of EDGAR, and the swept-in filings that were audited and rejected are available with include_rejects=true.

Why it's useful

• Event studies on biotech drawdowns: how do stocks react to a CRL vs a clinical hold, conditioned on severity?
• Screen for unresolved clinical holds or CRLs older than N days as potential resolution catalysts
• Measure disclosure latency: how many days between the FDA letter and the 8-K
• Study resolution cycles: time from hold to lift, or from CRL to resubmission acceptance
• Condition on development phase and market cap: a registrational CRL on a micro-cap is a different fact than a Phase 1 hold on a large cap

Endpoint

GET /v1/biotech/fda-response-events

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/biotech/fda-response-events"
params = {
    "event_type": "crl",
    "filing_role": "initial_disclosure",
    "date_gte": "2025-01-01",
    "date_lte": "2025-12-31",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/biotech/fda-response-events?event_type=crl&filing_role=initial_disclosure&date_gte=2025-01-01&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (exact match, upper-cased server-side).
• cik (optional): SEC CIK number, digits only. More stable than ticker for companies that renamed or re-listed.
• form (optional): 8-K or 8-K/A. Amendments are separate rows.
• event_type (optional): comma-separated, one or more of crl, clinical_hold_full, clinical_hold_partial, refuse_to_file, other_fda_action. not_a_setback_event is accepted only when include_rejects=true; otherwise it returns a 400.
• filing_role (optional): comma-separated, one or more of initial_disclosure, follow_up_update, resolution. filing_role=initial_disclosure is the de-duplicated event feed.
• severity (optional): comma-separated, one or more of program_terminated, major_delay_new_trial_required, manufacturing_only, addressable_deficiencies, safety_signal_no_path_stated, unstated, not_restated.
• severity_rank_gte / severity_rank_lte (optional): integers 1 to 6. Rank encodes grading precedence, not market impact (see Notes). Rows with a NULL rank (not_restated, rejects) drop out when either bound is set.
• development_phase (optional): comma-separated, one or more of preclinical, phase_1, phase_1_2, phase_2, phase_2_3, phase_3, registrational, post_marketing, unstated.
• event_letter_date_precision (optional): comma-separated, one or more of day, month, quarter, year, unstated. Use day when working with days_letter_to_disclosure.
• asset_key (optional): exact program key. Your input is normalized case- and punctuation-insensitively, so ABC-123, abc 123 and abc123 all resolve to the same program.
• drug_search (optional): case-insensitive substring match on drug_or_asset_name, minimum 3 characters.
• indication_search (optional): case-insensitive substring match on indication, minimum 3 characters.
• resolved (optional): 0 or 1, filters on resolved_flag. Note that resolved=0 excludes resolution rows, whose flag is NULL by construction.
• market_cap_gte / market_cap_lte (optional): numeric USD bounds on market_cap_at_filing. Rows with a NULL market cap drop out when either bound is set.
• include_rejects (optional): true or false, default false. true widens the response to the full audited corpus: the not_a_setback_event rows the sweep retrieved and the labeler rejected, plus any refused=1 rows.
• updated_since (optional): YYYY-MM-DD, filters on last_updated. Important for syncing: linkage columns are updated in place long after the original disclosure date (see Notes).
• date (optional): disclosure date filter (YYYY-MM-DD). Cannot be combined with date range parameters.
• cursor_date / cursor_accession (optional): keyset pagination cursor, both required together (see Notes).

If no date filters are provided, all available history is returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format and apply to disclosed_date (the EDGAR filing date). Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted. Every date parameter also has a disclosed_date alias (disclosed_date, disclosed_date_gte, disclosed_date_lte, disclosed_date_gt, disclosed_date_lt) so the parameter name can match the served field name. Either spelling works; supplying both spellings of the same bound with different values returns a 400.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "disclosed_date": "2026-03-02",
      "filing_timestamp": "2026-03-02T08:05:12-05:00",
      "ticker": "ACDB",
      "cik": "1834501",
      "company_name": "Arcadia Biotherapeutics, Inc.",
      "accession_number": "0001834501-26-000034",
      "form": "8-K",
      "items_reported": "Item 8.01: Other Events",
      "event_date_reported": "2026-02-27",
      "sic_code": "2836",
      "sic_description": "Biological Products, (No Diagnostic Substances)",
      "event_type": "crl",
      "filing_role": "initial_disclosure",
      "severity": "manufacturing_only",
      "severity_rank": 3,
      "drug_or_asset_name": "ARC-101",
      "asset_key": "arc101",
      "indication": "moderate-to-severe atopic dermatitis",
      "development_phase": "registrational",
      "fda_stated_reasons": "Deficiencies observed at a third-party fill-finish facility; no clinical or safety issues cited",
      "new_trial_required_flag": 0,
      "manufacturing_related_flag": 1,
      "resubmission_path_stated_flag": 1,
      "hold_lifted_flag": null,
      "event_letter_date": "2026-02-27",
      "event_letter_date_precision": "day",
      "days_letter_to_disclosure": 3,
      "guidance_timeline_stated": "Resubmission planned for mid-2026 following facility remediation",
      "event_description": "Received a Complete Response Letter for the ARC-101 BLA citing deficiencies at a third-party manufacturing facility; the company plans to resubmit in mid-2026.",
      "prior_event_accession_number": null,
      "prior_event_disclosed_date": null,
      "days_since_prior_event": null,
      "resolved_flag": 0,
      "resolution_accession_number": null,
      "resolution_disclosed_date": null,
      "days_to_resolution": null,
      "market_cap_at_filing": 412356800.0,
      "outstanding_shares_at_filing": 58908114,
      "filing_url": "https://www.sec.gov/Archives/edgar/data/1834501/000183450126000034/0001834501-26-000034-index.htm",
      "refused": 0,
      "last_updated": "2026-03-02"
    }
  ]
}

Notes on Data Behavior

• severity_rank is grading-precedence order (1 = the first grading rule that fired), not market impact. safety_signal_no_path_stated (rank 5) is a worse commercial outcome than manufacturing_only (rank 3). Do not read severity_rank_lte=3 as “the worst three”.
• Row counts are filings, not events. One FDA action can appear as up to three rows (initial disclosure, follow-up, resolution), so an unfiltered count overstates events by roughly 2.4x. Use filing_role=initial_disclosure for a de-duplicated event count, and group by (cik, asset_key) to collapse a program's filings into one chain.
• resolved_flag = null means the row is itself a resolution, not “unknown”. resolved=0 therefore returns open events only and excludes resolution rows by construction.
• days_letter_to_disclosure is a disclosure-latency measure only on initial_disclosure rows, ideally restricted to event_letter_date_precision=day. On follow_up_update rows it measures distance back to the original letter (up to 1,000+ days). It is in calendar days and can go negative when a low-precision letter date is extracted as a future date, so screen out values below 0 before using it.
• The evidence flags (new_trial_required_flag, manufacturing_related_flag, resubmission_path_stated_flag, hold_lifted_flag) are three-state: 1 = the filing said yes, 0 = the filing said no, null = the filing was silent. The two are different facts; never collapse null to 0.
• Selective disclosure is the structural limitation: the corpus covers actions disclosed in 8-K filings. An FDA action a company disclosed only in a 10-Q, in a press release without an 8-K, or never, is not here.
• By default the response contains real classified FDA events only (refused = 0 and event_type not not_a_setback_event). include_rejects=true returns the full audited corpus, including the swept-in filings the labeler classified as non-events and any rows the labeler declined (refused = 1, payload fields null).
• The linkage sweep updates prior_event_*, resolved_flag, resolution_* and the day-count columns in place, potentially months after disclosed_date. Clients syncing incrementally should poll updated_since on last_updated, not only a date range.
• Results are ordered by disclosed_date DESC, accession_number ASC
• Responses are paginated at 50,000 rows. When has_more is true, pass the returned next_cursor values as cursor_date and cursor_accession (both required together) to fetch the next page.
• Updated daily from SEC EDGAR after the filing day closes; coverage begins 2024-01-02

The FDA Advisory Committee Votes dataset covers every FDA advisory committee (AdCom) meeting on a drug or biologic product since 2024-01-01. An advisory committee is a panel of outside experts the FDA convenes to vote on questions about a product before the agency makes its own decision. The dataset has one row per vote question, with the committee's yes/no/abstain tally read out of the official minutes PDF.

Because vote questions are worded in both directions (“is the benefit-risk favorable?” vs “should use be restricted?”), each row also resolves the polarity of the question: favorable_answer says which answer was the product-favorable one, and vote_outcome_favorable says whether that side won (1), lost (0), or the outcome is undetermined (null, which covers ties and votes with no product-favorable side such as vaccine strain selection).

Meetings that produced no tally are kept as vote_seq = 0 placeholder rows whose vote_evidence says why (minutes not posted yet, a discussion-only agenda, or a meeting that never happened), so the forward calendar and the coverage denominator survive intact. Every row links to the FDA meeting page, minutes, transcript, and questions documents, so any tally can be checked against the source.

Why it's useful

• Track scheduled AdCom meetings as dated binary catalysts for biotech names
• Answer “how did the committee actually vote?” with tallies verified against the official minutes
• Compute base rates: how often the product-favorable side wins, by committee or topic type
• Study the lag between an AdCom vote and the eventual FDA decision
• Group every AdCom appearance of one asset via asset_key and the prior/next meeting linkage

Endpoint

GET /v1/biotech/advisory-committees

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/biotech/advisory-committees"
params = {
    "committee": "ODAC",
    "date_gte": "2024-01-01",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/biotech/advisory-committees?committee=ODAC&date_gte=2024-01-01&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• meeting_key (optional): exact FDA meeting-page slug. Returns every vote at one meeting.
• committee (optional): committee abbreviation (e.g. ODAC) or a name substring (e.g. Oncologic). An abbreviation also matches joint meetings where that committee is the second committee.
• center (optional): owning FDA center. Accepts CDER, CBER, or OC, or the full stored center name.
• meeting_status (optional): one of held, scheduled, postponed, cancelled. scheduled rows are the forward calendar.
• meeting_topic_type (optional): one of product_specific, compounding_nominations, strain_selection, safety_review, policy_or_class_review.
• vote_evidence (optional): one of minutes_tally, minutes_no_tally, no_vote_held, minutes_not_posted, meeting_not_held.
• has_tally (optional): true returns only rows carrying numeric vote counts; false returns only rows without them.
• vote_outcome_favorable (optional): true returns votes the product-favorable side won; false returns votes it lost. Both exclude rows where the outcome is undetermined (null), so true plus false do not sum to the total row count.
• drug (optional): case-insensitive substring of drug_name (2 to 100 characters).
• sponsor (optional): case-insensitive substring of sponsor_company (2 to 100 characters).
• asset_key (optional): exact normalized asset key. A match key, not an identifier.
• application (optional): substring of application_identifiers (2 to 100 characters). Matches a bare number like 220359 as well as a full BLA 125842.
• date (optional): meeting start date filter (YYYY-MM-DD). Cannot be combined with date range parameters.
• updated_since (optional): YYYY-MM-DD, filters on last_updated. Useful for picking up rows that re-labeled after FDA posted new materials.

If no date filters are provided, all available rows are returned (subject to your tier's visible window).

Date Filtering

All dates must be provided in YYYY-MM-DD format and apply to the meeting start date. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "record_id": "september-26-2024-meeting-oncologic-drugs-advisory-committee-meeting-announcement:1",
      "meeting_key": "september-26-2024-meeting-oncologic-drugs-advisory-committee-meeting-announcement",
      "date": "2024-09-26",
      "meeting_end_date": "2024-09-26",
      "meeting_status": "held",
      "committee_abbrev": "ODAC",
      "committee_name": "Oncologic Drugs Advisory Committee",
      "all_committees": "Oncologic Drugs Advisory Committee",
      "is_joint_meeting": 0,
      "center": "Center for Drug Evaluation and Research",
      "meeting_title": "September 26, 2024: Meeting of the Oncologic Drugs Advisory",
      "meeting_topic_type": "product_specific",
      "meeting_summary": "The committee discussed whether PD-1 inhibitor benefit in first-line gastric and esophageal cancer depends on PD-L1 expression level.",
      "vote_seq": 1,
      "question_number": 1,
      "session_label": "Morning Session",
      "question_voted": "Is the risk-benefit profile of PD-1 inhibitors favorable in first-line HER2-negative, microsatellite-stable gastric/GEJ adenocarcinoma with PD-L1 expression < 1?",
      "vote_yes": 2,
      "vote_no": 10,
      "vote_abstain": 1,
      "vote_total_votes": 13,
      "vote_margin": -8,
      "favorable_answer": "yes",
      "vote_outcome_favorable": 0,
      "vote_evidence": "minutes_tally",
      "sponsor_company": null,
      "drug_name": "PD-1 inhibitors",
      "asset_key": "pd1inhibitors",
      "indication": "first-line HER2-negative, microsatellite-stable gastric/GEJ adenocarcinoma",
      "application_identifiers": null,
      "fda_decision_type": "not_stated",
      "fda_decision_date": null,
      "days_meeting_to_decision": null,
      "prior_meeting_key": null,
      "prior_meeting_date": null,
      "days_since_prior_meeting": null,
      "next_meeting_key": null,
      "next_meeting_date": null,
      "days_to_next_meeting": null,
      "revisited_flag": 0,
      "materials_url": "https://www.fda.gov/advisory-committees/advisory-committee-calendar/september-26-2024-meeting-oncologic-drugs-advisory-committee-meeting-announcement",
      "minutes_url": "https://www.fda.gov/media/184545/download",
      "transcript_url": "https://www.fda.gov/media/184832/download",
      "questions_url": "https://www.fda.gov/media/182247/download",
      "agenda_url": "https://www.fda.gov/media/182245/download",
      "briefing_document_count": 2,
      "n_materials": 11,
      "refused": 0,
      "last_updated": "2026-08-24 09:58:12"
    }
  ]
}

Notes on Data Behavior

• Updated daily from FDA.gov (meeting calendar crawl plus minutes extraction)
• Coverage starts at meetings from 2024-01-01, and the forward calendar is included: upcoming meetings appear as meeting_status = "scheduled" rows with no tallies yet
• A meeting with no tally is still a row: vote_seq = 0 placeholder rows are included by default, and vote_evidence says why there are no numbers. Pass has_tally=true to keep only rows with counts
• FDA posts official minutes months after a meeting, so recent meetings sit at vote_evidence = "minutes_not_posted" with null tallies. Rows re-label automatically when FDA posts or changes the meeting materials; use updated_since to pick up those changes
• Polarity is resolved per question: favorable_answer names the product-favorable side and vote_outcome_favorable is a three-state field (1 won, 0 lost, null undetermined). Null covers placeholders, ties, and questions with no product-favorable side (e.g. strain selection)
• The FDA decision fields (fda_decision_type, fda_decision_date, days_meeting_to_decision) are only filled from the meeting materials themselves, which are written before the decision exists, so they are currently empty by design
• No pagination in v1: the response is the plain {"count", "data"} envelope
• Results are ordered by date DESC, meeting_key ASC, vote_seq ASC, so a meeting's votes stay contiguous and come back in the order they were taken
• Dates are returned as YYYY-MM-DD and date filters apply to the meeting start date

The Dividend Capture dataset is a calendar-driven view of ex-dividend events. For each event it measures how much the stock dropped on the ex-date relative to the dividend paid (the drop ratio), the net amount captured after that drop, and how many trading days the position took to recover back to breakeven.

Historical ex-day behavior is joined to the forward ex-dividend schedule, so the same endpoint answers both “how have ex-days behaved for this name?” and “which dividends are coming up?”, a ready-made dividend-capture screen.

Why it's useful

• Run a ready-made dividend-capture screen across upcoming ex-dividend dates
• Gauge how much of the dividend is typically given back via the ex-day price drop
• See historical recovery odds (within 1 / 3 / 5 / 10 / 20 trading days) before committing capital
• Pull a forward ex-dividend calendar for a single name or the whole market
• Filter to events that did or did not recover to breakeven for post-trade analysis

Endpoint

GET /v1/dividend-capture

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

Pull the upcoming ex-dividend calendar for the next two weeks:

import requests

url = "https://api.alphanume.com/v1/dividend-capture"
params = {
    "upcoming": "true",
    "future_days": 14,
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/dividend-capture?upcoming=true&future_days=14&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, events across all tickers are returned.
• date (optional): ex-dividend date filter (YYYY-MM-DD). Honored as-is even if it falls beyond the forward horizon. Cannot be combined with date range parameters.
• recovery_status (optional): filter by recovery state (case-insensitive). Isolates events by whether the position recovered to breakeven.
• upcoming (optional): true / 1 / yes returns only the forward schedule: events where today < ex-date ≤ the horizon cutoff.
• future_days (optional): forward horizon in days. Defaults to 7, capped at 120. Sets how far past today the calendar reaches.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted. Note that the forward edge of range queries is always capped at today + future_days, so an open-ended or forward-looking range will not return months of un-actionable future ex-dates. Past-only queries are unaffected.

Response Fields

Example Response

{
  "count": 1,
  "data": [
    {
      "date": "2026-05-08",
      "ticker": "KO",
      "declaration_date": "2026-04-16",
      "record_date": "2026-05-11",
      "pay_date": "2026-07-01",
      "cash_amount": 0.51,
      "frequency": 4,
      "dividend_type": "regular",
      "annual_dividend": 2.04,
      "capture_yield_pct": 0.72,
      "cum_date": "2026-05-07",
      "cum_close": 70.84,
      "ex_open": 70.41,
      "ex_close": 70.55,
      "price_drop_close": 0.29,
      "price_drop_open": 0.43,
      "drop_ratio_close": 0.57,
      "drop_ratio_open": 0.84,
      "net_capture_pct": 0.31,
      "breakeven_price": 70.33,
      "recovery_status": "recovered",
      "days_to_recover_breakeven": 2,
      "days_to_recover_price": 4,
      "recovery_date": "2026-05-12",
      "recovered_within_1d": false,
      "recovered_within_3d": true,
      "recovered_within_5d": true,
      "recovered_within_10d": true,
      "recovered_within_20d": true,
      "recovery_window_days": 20,
      "bars_observed": 20,
      "last_updated": "2026-06-08"
    }
  ]
}

Notes on Data Behavior

• Updated daily after the market close (EOD)
• Forward (upcoming) events carry the dividend schedule but have empty ex-day and recovery fields until the ex-date has passed and price bars are observed
• Nothing is published beyond a 120-day forward horizon; future_days is clamped to that ceiling
• Dates are returned as YYYY-MM-DD
• Results are ordered by date DESC, ticker ASC

The Historical Optionable Tickers dataset captures the point-in-time universe of U.S. equities with listed options chains.

It is a monthly snapshot of stocks with available options contracts, enriched with structural expiration information to help traders construct optionable universes with precision. Each record reflects the option listing structure as it existed on the first trading day of the respective month.

Why it's useful

• Construct historically accurate optionable universes
• Filter equities by expiration density (weekly vs non-weekly structures)
• Study the evolution of options availability over time
• Backtest strategies that require confirmed option chain presence
• Identify securities with robust weekly expiration coverage

This dataset is especially useful for systematic traders who need to avoid survivorship bias in options-based research.

Snapshot Methodology

• Snapshots are taken on the first trading day of each month
• Each snapshot reflects listed option expirations available at that time
• Historical records correspond to the first trading day of their respective month
• Records are point-in-time and do not retroactively change

Endpoint

GET /v1/optionable-tickers

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/optionable-tickers"
params = {"api_key": "alp_abc123"}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/optionable-tickers?api_key=alp_abc123"

Request Parameters

• api_key (optional): your API key. Enables full dataset access and reduces per-request limits. If omitted, a limited subset is returned.
• date (optional): snapshot date (YYYY-MM-DD). If omitted, all existing snapshots are returned.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date
• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted. If querying across all tickers without specifying a ticker, date ranges may be restricted depending on your access tier.

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "date": "2026-02-02",
      "ticker": "PFE",
      "avg_days_between": 7.0,
      "has_weeklies": 1
    }
  ]
}

Response Fields

Field Definitions

avg_days_between represents the average number of days between the next six consecutive option expiration dates after the first week window (expirations 1 through 6). Values close to 7 indicate dense weekly expiration structures; higher values indicate less frequent expiration spacing (e.g., biweekly or monthly listings).

has_weeklies is a binary indicator: 1 means multiple consecutive weekly expirations were listed at the snapshot date; 0 means weekly expiration continuity was not present.

Pagination

The Optionable Tickers endpoint uses cursor-based pagination for efficient retrieval of large result sets. Results are ordered deterministically:

ORDER BY date DESC, ticker DESC

When paginating, you must provide both cursor_date and cursor_ticker. These must match the next_cursor object from the previous response. If only one cursor field is provided, the request returns a 400 error.

Notes on Data Behavior

• Snapshots are taken on the first trading day of each month
• Records are never retroactively altered
• Each snapshot reflects only information known at that time
• Historical records remain fixed once published
• All dates are returned as YYYY-MM-DD strings

The Ticker Sector & Industry Classification dataset provides a mapping of equity tickers into Alphanume-defined sector and industry groups.

Each observation assigns a ticker to a consistent, internally defined classification system derived from underlying business activity. These classifications are designed for quantitative workflows and are not intended to replicate standardized taxonomies.

The dataset is structured to be stable, URL-safe, and directly queryable for use in filtering, grouping, and feature engineering pipelines.

Why it's useful

• Filter universes by sector or industry exposure
• Build sector-neutral or industry-relative strategies
• Group tickers for cross-sectional analysis
• Construct features based on economic exposure
• Standardize classification across research pipelines
• Join with other datasets for consistent segmentation

Endpoint

GET /v1/ticker-classification

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/ticker-classification"
params = {
    "api_key": "alp_abc123",
    "sector": "technology"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/ticker-classification?sector=technology&api_key=alp_abc123"

Request Parameters

• api_key (required): your Alphanume API key.
• ticker (optional): filter results by a specific ticker. Example: ?ticker=AAPL
• sector (optional): filter results by sector. Must be one of the accepted sector keywords (lowercase, underscore-separated). Example: ?sector=technology
• industry (optional): filter results by industry. Must be one of the accepted industry keywords. Example: ?industry=semiconductors

Available Sector Values

The following sector values are accepted for the sector parameter. All values must be lowercase and underscore-separated.

Available Industry Values

The following industry values are accepted for the industry parameter. All values must be lowercase and underscore-separated.

Parameter Behavior

• All parameters are optional
• If no parameters are provided, the full dataset is returned (subject to tier limits)
• Parameters can be combined

Examples:

?ticker=AAPL
?sector=finance
?industry=software
?sector=finance&industry=banking
?ticker=JPM&sector=finance

Invalid sector or industry values will return a 400 error.

Response Format

{
  "count": 2,
  "data": [
    {
      "ticker": "AAPL",
      "alphanume_sector": "technology",
      "alphanume_industry": "hardware_devices"
    },
    {
      "ticker": "MSFT",
      "alphanume_sector": "technology",
      "alphanume_industry": "software"
    }
  ]
}

Response Fields

Notes on Data Behavior

• Classifications are deterministic and consistent
• Values are not dynamically inferred at query time
• Results are ordered by ticker (ascending)
• No date dimension is applied
• The dataset represents the current mapping of tickers to classifications

The Historical Market Cap dataset provides point-in-time market capitalization and shares outstanding for equities, as they were known on each historical date.

It is designed for research and production workflows that require true point-in-time fundamentals (e.g., avoiding lookahead bias when modeling size, liquidity regimes, or dilution / float dynamics).

Why it's useful

• Build point-in-time size factors (market cap) without future leakage
• Normalize signals by shares outstanding / float regime
• Backtest strategies that depend on historical capitalization thresholds (e.g., “only trade > $X market cap at the time”)
• Monitor structural shifts from issuance / buybacks via share count changes

Endpoint

GET /v1/historical-market-cap

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/historical-market-cap"
params = {
    "ticker": "AAPL",
    "date": "2026-02-06",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/historical-market-cap?ticker=AAPL&date=2026-02-06&api_key=alp_abc123"

Request Parameters

• api_key (optional): your API key. Enables full dataset access and removes per-request limits. If omitted, a limited subset is returned.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, data across all tickers are returned.
• date (optional): trading date filter (YYYY-MM-DD). If omitted, a ticker must be provided.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "date": "2026-02-06",
      "ticker": "AAPL",
      "market_cap": 4109599296360,
      "shares_outstanding": 14776353000
    }
  ]
}

Pagination

The Historical Market Cap endpoint uses cursor-based pagination for efficient retrieval of large result sets. Results are ordered deterministically:

ORDER BY date DESC, ticker DESC

Each response includes:

• count: number of rows returned in this page
• has_more: whether additional data is available
• next_cursor: cursor object to retrieve the next page

When paginating, you must provide both cursor_date and cursor_ticker. These must match the next_cursor object from the previous response. If only one cursor field is provided, the request returns a 400 error.

import requests

base_url = "https://api.alphanume.com/v1/historical-market-cap"
headers = {"X-API-Key": "alp_abc123"}
params = {"ticker": "AAPL"}

all_rows = []
while True:
    r = requests.get(base_url, headers=headers, params=params).json()
    all_rows.extend(r["data"])
    if not r["has_more"]:
        break
    cursor = r["next_cursor"]
    params["cursor_date"] = cursor["date"]
    params["cursor_ticker"] = cursor["ticker"]

print(f"Retrieved {len(all_rows)} rows.")

The Wikipedia Views dataset provides daily Wikipedia page view counts for equities, along with rolling 30-day statistics (mean and z-score) measuring how unusual current attention is relative to the recent baseline.

It is designed for research and production workflows that incorporate retail attention as a feature, whether as a standalone signal, a regime filter, or an input to event-driven and cross-sectional models.

Why it's useful

• Build attention-based factors that capture shifts in investor interest before they show up in price or volume
• Detect anomaly days where ticker-level attention deviates sharply from its 30-day baseline (high z-score events)
• Filter or contextualize event-driven setups (earnings, news, filings) by the level of public attention surrounding them
• Backtest strategies conditioned on attention regimes (e.g., “only trade names with zscore_30d > 2”)

Endpoint

GET /v1/wikipedia-views

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/wikipedia-views"
params = {
    "ticker": "AAPL",
    "date": "2026-02-06",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/wikipedia-views?ticker=AAPL&date=2026-02-06&api_key=alp_abc123"

Request Parameters

• api_key (required): your API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, data across all tickers are returned.
• date (optional): observation date filter (YYYY-MM-DD). Cannot be combined with date range parameters.

If no filters are provided, the endpoint returns the full dataset ordered by date descending. Use cursor pagination to walk back through history.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Z-Score Filtering

The zscore_30d field can be filtered to isolate attention anomalies. All values are floats. Supported parameters:

• zscore_30d_gte
• zscore_30d_lte
• zscore_30d_gt
• zscore_30d_lt
• zscore_30d_eq

zscore_30d_eq cannot be combined with z-score range parameters. Any logically valid combination of the range parameters is accepted.

Common use cases:

• zscore_30d_gte=2: surface days with abnormally high attention
• zscore_30d_lte=-2: surface days with abnormally low attention
• zscore_30d_gte=2&date=2026-02-06: find every ticker with anomalous attention on a given date

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "ticker": "AAPL",
      "name": "Apple Inc.",
      "date": "2026-02-06",
      "views": 48213,
      "avg_30d": 21847.3,
      "zscore_30d": 4.11
    }
  ]
}

Pagination

The Wikipedia Views endpoint uses cursor-based pagination for efficient retrieval of large result sets. Results are ordered deterministically:

ORDER BY date DESC, ticker ASC

When paginating, you must provide both cursor_date and cursor_ticker. These must match the next_cursor object from the previous response. If only one cursor field is provided, the request returns a 400 error.

import requests

base_url = "https://api.alphanume.com/v1/wikipedia-views"
headers = {"X-API-Key": "alp_abc123"}
params = {"ticker": "AAPL"}

all_rows = []
while True:
    r = requests.get(base_url, headers=headers, params=params).json()
    all_rows.extend(r["data"])
    if not r["has_more"]:
        break
    cursor = r["next_cursor"]
    params["cursor_date"] = cursor["date"]
    params["cursor_ticker"] = cursor["ticker"]

print(f"Retrieved {len(all_rows)} rows.")

The Filing Intensity dataset provides daily SEC filing counts per equity, capturing how actively a company is interacting with the SEC on any given day. Filing activity is a leading indicator: corporate actions, capital raises, insider activity, and material events all leave fingerprints in the EDGAR filing stream before they're priced in.

It is designed for research and production workflows that incorporate corporate filing behavior as a feature, whether as a standalone signal, an event-detection trigger, or an input to event-driven and cross-sectional models.

Why it's useful

• Detect spikes in corporate activity that often precede material announcements, capital structure changes, or insider transactions
• Build event-driven signals around tickers entering periods of unusually heavy SEC engagement
• Filter or rank universes by recent filing intensity to surface names with active corporate developments
• Backtest strategies conditioned on filing-burst regimes (e.g., “only trade names with filing_count >= 5 on a given day”)

Endpoint

GET /v1/filing-intensity

Base URL

https://api.alphanume.com/v1

Authentication

All requests require an API key. Pass it as a query parameter (?api_key=your_key) or via header (X-API-Key: your_key).

Sample Request

import requests

url = "https://api.alphanume.com/v1/filing-intensity"
params = {
    "ticker": "AAPL",
    "date": "2026-02-06",
    "api_key": "alp_abc123"
}

r = requests.get(url, params=params)
print(r.json())

curl "https://api.alphanume.com/v1/filing-intensity?ticker=AAPL&date=2026-02-06&api_key=alp_abc123"

Request Parameters

• api_key (required): your API key.
• ticker (optional): equity ticker filter (case-insensitive, exact match). If omitted, data across all tickers are returned.
• date (optional): observation date filter (YYYY-MM-DD). Cannot be combined with date range parameters.

If no filters are provided, the endpoint returns the full dataset ordered by date descending. Use cursor pagination to walk back through history.

Date Filtering

All dates must be provided in YYYY-MM-DD format. Supported parameters:

• date_gte
• date_lte
• date_gt
• date_lt

Any logically valid combination is accepted.

Filing Count Filtering

The filing_count field can be filtered to isolate periods of elevated or quiet filing activity. All values are non-negative integers. Supported parameters:

• filing_count_gte
• filing_count_lte
• filing_count_gt
• filing_count_lt
• filing_count_eq

filing_count_eq cannot be combined with range parameters. Any logically valid combination of the range parameters is accepted.

Common use cases:

• filing_count_gte=5: surface days with elevated filing activity
• filing_count_eq=0: isolate quiet days for baselining
• filing_count_gte=3&date=2026-02-06: find every ticker with elevated filing activity on a given date

Response Fields

Example Response

{
  "count": 1,
  "has_more": false,
  "next_cursor": null,
  "data": [
    {
      "ticker": "AAPL",
      "name": "Apple Inc.",
      "date": "2026-02-06",
      "filing_count": 7
    }
  ]
}

Pagination

The Filing Intensity endpoint uses cursor-based pagination for efficient retrieval of large result sets. Results are ordered deterministically:

ORDER BY date DESC, ticker ASC

When paginating, you must provide both cursor_date and cursor_ticker. These must match the next_cursor object from the previous response. If only one cursor field is provided, the request returns a 400 error.

import requests

base_url = "https://api.alphanume.com/v1/filing-intensity"
headers = {"X-API-Key": "alp_abc123"}
params = {}

all_rows = []
while True:
    r = requests.get(base_url, headers=headers, params=params).json()
    all_rows.extend(r["data"])
    if not r["has_more"]:
        break
    cursor = r["next_cursor"]
    params["cursor_date"] = cursor["date"]
    params["cursor_ticker"] = cursor["ticker"]

print(f"Retrieved {len(all_rows)} rows.")

Update Frequency

The Filing Intensity dataset is refreshed nightly at 11:30 PM EST. Each update incorporates all SEC filings submitted during the current trading day, ensuring data is available ahead of the next session's open. Filings submitted after the cutoff will appear in the following night's update.