Identifying an instrument

Every v1.1 stock endpoint, retail and enterprise, names one instrument with the same two path segments:

/api/v11/stock/{namespace}/{identifier}/{domain}/{endpoint}/
/api/v11/enterprise/stock/{namespace}/{identifier}/{domain}/{endpoint}/

The namespace says where to look and the identifier says what to look for there. An exchange is the namespace a ticker lives in, so /stock/NYSE/AMC/… is AMC on the New York Stock Exchange. An identifier scheme is a namespace too, so /stock/isin/US00165C1045/… is the instrument holding that ISIN.

The rules on this page apply to every stock endpoint. The endpoint reference pages describe only what each endpoint returns.

A venue and a ticker

When the namespace is a venue, the identifier is a ticker on it. A venue can be written three ways:

Namespace	Example	Meaning
An ORTEX exchange symbol	`NYSE`, `NASDAQ`, `LSE`	That exchange. The exchange symbols are listed by the Exchanges reference endpoint.
A MIC (ISO 10383): operating, segment or published	`XNAS`, `XNGS`, `XLON`	The exchange or exchanges with that MIC. The segment or published MIC is the one a response reports as `instrument.mic`, the operating MIC the one it reports as `instrument.operatingMic`, so either pastes back into the path. A MIC shared by several exchanges (an operating MIC covering several market segments) reaches all of them.
An ISO 3166-1 alpha-2 country code	`US`, `CA`, `GB`	Every exchange in that country. Useful when you know where a stock trades but not on which exchange.

Venues and tickers are case-insensitive: /stock/nyse/amc/… is the same request as /stock/NYSE/AMC/….

When a value is both an exchange symbol and a MIC, the namespace covers every exchange it names. If the ticker trades on more than one of them, the primary listing wins, then the more important exchange.

Tickers are reused. When a company changes its ticker, or a ticker passes from one company to another, the ticker is resolved as of your anchor date: the response is about the listing that held the ticker on that date. The anchor date is your from_date or, if you sent none, your to_date. To be sure you get the listing you mean, move from_date, or use an ORTEX id, ISIN or FIGI, which never go stale.

An identifier scheme and a value

When the namespace is one of these five keywords, the identifier is a value in that scheme:

Namespace	Identifier	Resolves to
`tid`	an ORTEX trading-item id (`ortexTid`)	exactly that listing, even if it is no longer active
`sid`	an ORTEX security id (`ortexSid`)	that security's primary listing
`cid`	an ORTEX company id (`ortexCid`)	the company's primary security, then that security's primary listing
`isin`	an ISIN	the security that held the ISIN on your anchor date, then its primary listing
`figi`	a FIGI	an exchange-level FIGI is exactly that listing; a share-class FIGI names a security, then its primary listing. Composite FIGIs are not accepted.

/api/v11/stock/tid/6684014/short/short_interest/?from_date=2026-01-01
/api/v11/stock/isin/US00165C1045/short/short_interest/?from_date=2026-01-01

The keywords are case-insensitive. A keyword always means its scheme, never an exchange of the same spelling.

The ORTEX ids are the public ids every v1.1 response reports (ortexTid, ortexSid, ortexCid). They are never an internal database id or a vendor id.

Which listing an identifier resolves to

A security or company can trade on several exchanges. sid, cid, isin and a share-class FIGI resolve to one listing, the primary one, so a stock response is always about a single listing:

a listing trading on your anchor date beats one that was not;
then the listing the exchange data marks as primary;
then an active listing;
then the more important exchange.

A company's primary security is chosen the same way: one in existence on your anchor date, then the one marked primary, then an active one. A security with no listing is never chosen.

Every listing of a security

An identifier that names a security (an ISIN, sid, cid or a share-class FIGI) answers every stock endpoint for that security's main listing only. To get another listing, ask for the security's listings, then use the one you want as the stock path:

/api/v11/stock/isin/GB00BH4HKS39/reference/listings/

The listings endpoint is an ordinary stock endpoint, so any namespace works (/stock/LSE/VOD/reference/listings/, /stock/tid/{ortexTid}/reference/listings/, …). It returns the security's active listings that carry a ticker, primary first, then by exchange importance. Each row's ortexTid, or its exchangeSymbol + ticker, pastes straight back into any stock path: /stock/tid/{ortexTid}/… or /stock/{exchangeSymbol}/{ticker}/…. On a cid path, the company's primary security is used; a company's other share classes have their own ISINs and their own listings. No endpoint narrows to a listing through a query parameter.

The anchor date

Identifiers resolve as of the same anchor date as tickers: from_date, else to_date. ISINs move between securities, so an ISIN names the security that carried it on that date. If you ask for a date before the ISIN's first holder, it resolves to that first holder. If every holder of the ISIN had stopped carrying it before your anchor date, the response is 404 instrumentNotFound, as for a ticker no longer held on that date. ORTEX ids and FIGIs are never reassigned, so they resolve the same way on any date.

Endpoints without a date window (snapshots) have no anchor date. On those, sid, cid, isin and a share-class FIGI resolve only to active listings, as a ticker does. tid and an exchange-level FIGI name one listing exactly and reach it even when it is no longer active.

What comes back

Every stock response tells you what your path resolved to, so you can confirm the match:

The instrument block reports the one listing: its exchange_symbol and ticker (as of your anchor date), companyName, the ORTEX ids ortexTid, ortexSid and ortexCid, and the listing's isin, figi, mic and operatingMic. Its exchange_symbol + ticker, or its ortexTid, paste straight back into any stock path.
The request block echoes the two segments as you sent them, as namespace and identifier, whichever form you used:

"request": {
  "namespace": "isin",
  "identifier": "US00165C1045",
  "from_date": "2026-01-01"
}

See The Response Envelope for the rest of the response.

Errors

Situation	Response
The namespace is not an exchange symbol, MIC, country code or scheme keyword, and is not shaped like a MIC	`400 invalidExchangeSymbol` (`details[].field` is `namespace`)
The namespace has the shape of a MIC (four letters or digits) but no exchange we cover has that MIC	`404 instrumentNotFound` (`details[].field` is `namespace`, `details[].issue` is `unrecognized`)
The venue is valid but has no listing with that ticker	`404 instrumentNotFound`; the message names the exchanges where the ticker does trade, if any
The identifier cannot be a value in its scheme: a non-numeric ORTEX id, or an ISIN or FIGI with the wrong shape or check digit	`400 invalidIdentifier` (`details[].field` is `identifier`, and `details[].issue` is `mustBeInteger`, `malformed` or `checkDigitMismatch`). Nothing is looked up.
The identifier is well formed but matches nothing	`404 instrumentNotFound` (`details[].issue` is `unrecognized`)
The path still holds the placeholders, e.g. `/stock/{namespace}/{identifier}/…`	`404 samplePathNotReplaced`

A listing that resolves but has no data in your window is not an error: it is a 200 with an empty data array and a meta.emptyReason. See Response & Error Codes.

Identifiers go in the path only. No v1.1 endpoint accepts ticker, exchange, isin or another identifier as a query parameter; one sent is reported in the response's ignored block and has no effect.