Free Insider Trading API
for SEC Form 4 Data

What a free insider trading API actually needs to do

A developer-ready API turns public corporate-insider ownership filings into usable JSON without discarding the filing context. Form 3 establishes an insider’s reported ownership when the reporting obligation begins, Form 4 reports changes in beneficial ownership, and Form 5 is an annual statement for transactions or holdings reportable there. A complete workflow may need all three forms and their amendments, even when the product’s main filter is recent Form 4 activity.

A filing is evidence of a reported ownership event, not a self-explanatory “bullish buy” or “bearish sell.” Transaction code, acquired/disposed flag, security type, direct or indirect ownership, derivative terms, footnotes, and post-transaction holdings must be read together. Grants, option exercises, tax withholding, gifts, transfers, and transactions under a trading plan can produce share changes that should not be grouped blindly with discretionary open-market purchases or sales.

What an SEC Form 4 API should return

A useful API preserves the source filing while normalizing issuer, reporting owner, relationship, non-derivative and derivative tables, transaction, ownership form, post-transaction holdings, footnotes, and amendment state. Always retain accession number, filing URL, original filing date, and provider ingestion time so each normalized event can be verified against the authoritative record.

How current is insider trading API data?

The SEC explains that Form 4 is generally filed within two business days of the transaction. API freshness begins only after publication. Track transaction date, deemed execution date when present, SEC filing time, amendment time, and provider ingestion time separately; “real-time insider data” can only describe low processing delay after disclosure, not instantaneous knowledge of the underlying transaction.

Three ways to obtain SEC insider transaction data

The best route depends on whether the application needs authoritative source documents, normalized records, or a callable capability that can switch among providers. These layers can complement each other: use a normalized API for product speed, but retain an EDGAR link and accession number for verification.

Worked classification: share count alone is not a buy or sell signal

Consider three records that all increase an officer's reported shares. A transaction with code P, an acquired indicator, a cash price, and non-derivative common stock is a candidate open-market purchase. Code M may represent an option exercise and should be paired with the derivative table, exercise price, underlying shares, and any same-day disposal. Code A may represent a grant or award rather than a discretionary purchase. The change in holdings is real in each case, but the economic event and its interpretation differ.

A sale record also needs context. Shares withheld for taxes, gifts, transfers among controlled entities, and a sale marked under a Rule 10b5-1 trading arrangement should remain distinguishable from an unplanned open-market disposition. Footnotes may explain weighted-average prices, multiple executions, ownership through a trust, or why a value is blank. If those details are flattened into a single “buy/sell” label, the API has made the data easier to display but less reliable to interpret.

Match the output to the product

How to choose a free insider trading API

Insider trading API Python implementation

The exact endpoint and authentication scheme depend on the selected provider. Keep the client configurable, validate HTTP status and schema, and preserve the source filing identifier.

Minimal REST request pattern

import os
import requests

url = os.environ["INSIDER_API_URL"]
headers = {"Authorization": f"Bearer {os.environ['INSIDER_API_KEY']}"}
params = {"ticker": "AAPL", "transaction_code": "P", "limit": 25}

response = requests.get(url, headers=headers, params=params, timeout=20)
response.raise_for_status()
records = response.json()

for item in records.get("data", records):
    print(item.get("ticker"), item.get("transactionDate"),
          item.get("shares"), item.get("accessionNumber"))

Production checks before automation

• Paginate until the provider signals completion; do not assume one response contains every owner, transaction, table, or footnote.
• Store raw XML or source response immutably, then key normalized rows by accession, owner, security table, transaction identity, and amendment version.
• Apply amendments as versioned corrections rather than blindly adding or deleting the original filing.
• Preserve transaction code, voluntary flag, acquired/disposed state, direct/indirect ownership, derivative terms, and footnote references before assigning a human-readable category.
• Treat null or zero price, weighted-average price, gifts, grants, exercises, tax withholding, and indirect transfers explicitly.
• Back off on 429 responses, cache stable source versions, and measure source-to-provider ingestion latency separately from transaction-to-filing delay.

Use QVeris to inspect API capabilities before calling

QVeris helps agents discover and inspect callable financial-data capabilities before execution. Use QVeris tool details to distinguish raw ownership filings, normalized Form 4 transactions, issuer activity, and reporting-owner history. Inspect form coverage, identifier and date inputs, transaction-code fields, derivative and footnote support, amendments, source links, pagination, limits, and provider terms before calling; capability routing does not replace filing interpretation.

FAQ

Authoritative source and further reading