How do I retrieve and filter insider transactions with the insider screener API?

Use the transactions endpoint to retrieve insider trades across supported markets, then add query parameters to narrow the results by market, transaction type, date, issuer, insider or value.

The endpoint is:

https://www.insiderscreener.com/api/v1/data/transactions/

Send your API key in the X-API-Key header with every request.

Retrieve recent insider purchases

This request returns recent purchases reported in the US market:

curl --request GET \
  --url 'https://www.insiderscreener.com/api/v1/data/transactions/?market=US&nature=BUY&page_size=100' \
  --header 'X-API-Key: YOUR_API_KEY'

Use BUY for purchases, SELL for sales and OO for other operations. You can request more than one market by separating the country codes with commas, for example market=US,GB,FR.

Filter by date

Use transaction dates when you want to filter by the date on which a trade was executed:

transaction_date_from=2026-08-01
transaction_date_to=2026-08-31

Use notification dates when you want to filter by the date on which a transaction was disclosed:

notification_date_from=2026-08-01
notification_date_to=2026-08-31

Dates use the YYYY-MM-DD format.

For example, this request returns purchases executed in the US during August 2026, ordered by execution date from newest to oldest:

curl --request GET \
  --url 'https://www.insiderscreener.com/api/v1/data/transactions/?market=US&nature=BUY&transaction_date_from=2026-08-01&transaction_date_to=2026-08-31&ordering=-transaction_date&page_size=100' \
  --header 'X-API-Key: YOUR_API_KEY'

Filter by issuer or security

You can identify a company or security with any of these filters:

• ticker: the issuer's primary ticker
• isin: an exact ISIN
• identifier: an ISIN, LEI, RIC or ticker resolved by the API
• issuer_id: the numeric issuer ID
• issuer_slug: the issuer slug
• issuer_name: a partial, case-insensitive issuer-name match

For example:

?ticker=AAPL&nature=BUY

Ticker symbols can overlap between markets. Add market when you need to distinguish a particular listing or country.

Filter by insider

Use insider_name for a partial name search across the insider, PDMR and closely associated person fields:

?insider_name=Jane%20Smith

When you already know the person's identifier, use person_id. It accepts either a numeric value or a prefixed ID such as per_123.

Filter by transaction size or company profile

Useful transaction filters include:

• value_min and value_max: transaction value in USD
• quantity_min: minimum number of securities transacted
• currency: reported transaction currency
• at_market_price: true or false
• holdings_change: minimum percentage increase when positive, or maximum percentage decrease when negative
• position: partial position-title match
• position_type: one or more normalized position types, separated by commas

You can also filter issuers by market_cap_category, market_cap_min, market_cap_max, indices, economic_sector, business_sector or industry_group. Market-cap minimum and maximum values are expressed in USD millions.

The interactive API documentation lists every supported value and filter.

Use the API from Python

The following example retrieves US purchases above $100,000 reported during the last 30 days:

import os
from datetime import date, timedelta

import requests

url = "https://www.insiderscreener.com/api/v1/data/transactions/"
headers = {"X-API-Key": os.environ["INSIDER_SCREENER_API_KEY"]}
params = {
    "market": "US",
    "nature": "BUY",
    "notification_date_from": (date.today() - timedelta(days=30)).isoformat(),
    "value_min": 100000,
    "ordering": "-notification_date",
    "page_size": 100,
}

response = requests.get(url, headers=headers, params=params, timeout=30)
response.raise_for_status()
payload = response.json()

for item in payload["data"]:
    print(
        item["issuer"]["name"],
        item["reporting_person"]["name"],
        item["transaction"]["gross_value_usd"]["amount"],
    )

Understand the response

Each successful list response contains:

• data: the transaction records
• pagination: the page size, effective ordering and cursor links

Each transaction record groups related fields into source, issuer, reporting_person, security, transaction, analytics and raw objects. It also includes stable prefixed IDs and links to related API resources.

Values such as prices, quantities and transaction amounts are returned as strings where decimal precision must be preserved. Parse them with a decimal type rather than a binary floating-point type when exact calculations matter.

Follow cursor pagination

The transaction endpoint uses cursor pagination. If pagination.next contains a URL, request that URL unchanged to retrieve the next set of results:

next_url = payload["pagination"]["next"]

while next_url:
    response = requests.get(next_url, headers=headers, timeout=30)
    response.raise_for_status()
    payload = response.json()

    for item in payload["data"]:
        # Process or store the transaction.
        pass

    next_url = payload["pagination"]["next"]

Do not construct cursor values yourself. The API applies your plan's maximum page size even if you request a larger value.

By default, results are ordered by newest notification date. The supported ordering values are transaction_date, -transaction_date, notification_date and -notification_date. A leading minus sign means descending order.

Control credit usage

Use the narrowest market, date and issuer filters that fit your workflow, and avoid repeatedly requesting records you have already stored. Follow the returned cursor until it becomes null, then save the newest processed notification date for your next synchronization. Store each transaction's stable id so your integration can identify records it has already processed.

Credit costs and historical-data limits depend on the endpoint, market scope and API plan. Check API pricing for current allowances and API Access for your remaining credits and request history.

Troubleshoot unexpected results

• No results: remove filters one at a time, confirm the market code and widen the date range.
• 400 Bad Request: check date formats, filter values and the supported ordering options.
• Duplicate-looking records: use the transaction id as the stable record identifier and check the filing status and amendment fields.
• Missing optional values: some regulators do not report every field; handle null values in your integration.
• 401 Unauthorized: confirm that the key is active and sent in the X-API-Key header without a prefix.
• 403 Forbidden: your current plan does not include the requested resource.
• 429 Too Many Requests: slow down and retry after a delay, or check whether your credit allowance has been exhausted.

Need help choosing filters for a specific workflow? Contact API support.