How do I find an issuer using a ticker, ISIN, LEI or RIC?

Use the identifier-resolution endpoint to map the identifiers in your system to canonical insider screener issuers. It accepts tickers, ISINs, LEIs, RICs and issuer slugs, and you can mix identifier types in the same request.

The endpoint is:

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

Identifier resolution is available on all API plans. It uses no credits, but normal request-rate limits still apply.

Resolve one identifier

Send a POST request with an identifiers array and your API key in the X-API-Key header:

curl --request POST \
  --url 'https://www.insiderscreener.com/api/v1/data/identify/' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --data '{"identifiers":["US0378331005"]}'

When the identifier resolves successfully, the result includes the canonical issuer ID, name, slug, country, ticker and LEI:

{
  "count": 1,
  "results": [
    {
      "input": "US0378331005",
      "resolved": true,
      "status": "resolved",
      "ambiguity_reason": null,
      "candidates": [],
      "coverage": {
        "available": true,
        "has_transactions": true,
        "has_screener_analytics": true
      },
      "issuer": {
        "id": "iss_123",
        "name": "Apple Inc",
        "slug": "apple-inc",
        "country": "US",
        "ticker": "AAPL",
        "lei": null
      }
    }
  ]
}

The values above illustrate the response structure. IDs, coverage and optional fields depend on the matched issuer.

Resolve several identifier types at once

You can submit a watchlist containing different identifier types in one request:

curl --request POST \
  --url 'https://www.insiderscreener.com/api/v1/data/identify/' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --data '{
    "identifiers": [
      "US0378331005",
      "AAPL",
      "AAPL.O",
      "5493006MHB84DD0ZWV18",
      "alstom-sa"
    ]
  }'

The response contains one result for each distinct input. Your API key has a maximum number of identifiers per request; API Research supports up to 10,000. If a watchlist is larger than your limit, split it into batches.

Use the endpoint from Python

import os

import requests

url = "https://www.insiderscreener.com/api/v1/data/identify/"
headers = {"X-API-Key": os.environ["INSIDER_SCREENER_API_KEY"]}
body = {
    "identifiers": [
        "US0378331005",
        "AAPL",
        "AAPL.O",
    ]
}

response = requests.post(url, headers=headers, json=body, timeout=30)
response.raise_for_status()

for result in response.json()["results"]:
    if result["resolved"]:
        issuer = result["issuer"]
        print(result["input"], issuer["id"], issuer["slug"])
    else:
        print(result["input"], result["status"])

Store the API key in an environment variable or secret manager rather than including it directly in source code.

Understand resolution statuses

Each result has a resolved boolean and a machine-readable status:

• resolved: one canonical insider screener issuer matched the input.
• ambiguous: more than one issuer could match; inspect ambiguity_reason and candidates.
• not_available: the identifier represents a security that is not available in insider screener coverage.
• not_found: no matching issuer was found.
• lookup_unavailable: an identifier lookup could not be completed; retry later.

Do not treat every unresolved identifier as permanently unsupported. Handle each status separately, store the result and retry temporary lookup failures.

Handle ambiguous tickers

A ticker alone may identify more than one issuer because ticker symbols can be reused across markets. When this happens, the result has status: "ambiguous" and includes candidates with fields such as country, exchange, MIC, ticker, RIC and LEI.

The identifier endpoint does not accept a separate market parameter. Compare the candidates with your source data, then retry with a more specific identifier such as an ISIN, LEI or RIC. Avoid automatically selecting the first candidate.

For example, an ambiguous result can contain:

{
  "input": "ADM",
  "resolved": false,
  "status": "ambiguous",
  "ambiguity_reason": "multiple_local_ticker_matches",
  "issuer": null,
  "candidates": [
    {
      "id": "iss_123",
      "name": "Example issuer",
      "country": "US",
      "ticker": "ADM",
      "mic": "XNYS",
      "match_reason": "exact_local_ticker",
      "confidence": 1.0
    }
  ]
}

Candidate values in this example are illustrative.

Check data coverage

The coverage object tells you whether the matched issuer is available and whether insider screener currently has transactions or screener analytics for it:

• available: the issuer is part of the available issuer universe.
• has_transactions: at least one public transaction is available.
• has_screener_analytics: issuer analytics are available.

A resolved issuer can still have false for one of the data-specific fields. Check these flags before starting a workflow that depends on transaction history or analytics.

Retrieve the matched issuer

After resolution, use the returned issuer.slug to request the canonical issuer record:

curl --request GET \
  --url 'https://www.insiderscreener.com/api/v1/data/issuers/apple-inc/' \
  --header 'X-API-Key: YOUR_API_KEY'

To retrieve that issuer's insider transactions, use:

curl --request GET \
  --url 'https://www.insiderscreener.com/api/v1/data/issuers/apple-inc/transactions/?page_size=100' \
  --header 'X-API-Key: YOUR_API_KEY'

You can also filter the main transaction list with a single identifier:

https://www.insiderscreener.com/api/v1/data/transactions/?identifier=US0378331005

For transaction history across several identifiers, send a POST request to /api/v1/data/transactions/by-identifiers/. That endpoint accepts an identifiers array plus optional lookback_days and nature fields.

Recommended integration workflow

1. Send your identifiers to /api/v1/data/identify/ in batches.
2. Store the original input alongside the returned issuer ID and slug.
3. Review ambiguous candidates instead of choosing one automatically.
4. Check the coverage flags before requesting downstream data.
5. Use canonical issuer slugs or IDs in later requests where supported.
6. Re-run resolution when your watchlist changes or after a temporary lookup failure.

The interactive API documentation contains the complete request and response schemas. For help, contact API support.