API TraderAPI QuantAPI Developer
ORTEX Market Intelligence content — pulses, weekly digests, trader notes, earnings previews, convergence reports and market commentary — as one paginated feed, newest first.
Every row carries the same shape whatever its type, so a client learns one format and filters down to what it wants.
Available Data Points:
- ID: Stable identifier for the content row. Pass it back as 'id' to retrieve just that row.
- Content Type: What kind of content this is — a pulse, a digest, a trader note, and so on.
- Ticker: The primary instrument the content is about, where it has one.
- Exchange: The venue of the primary instrument, so you can build the full instrument reference.
- Ortex Tradable Item ID: Unique id for the primary instrument's listing. Null when the content names no instrument.
- Ortex Security ID: Unique id for the primary instrument's security — the key for joining this feed to any other ORTEX dataset. Null when the content names no instrument.
- Ortex Company ID: Unique id for the company the content is about. Null for cross-company content such as weekly digests and market commentary.
- ISIN: The current ISIN of the primary instrument's security. Null when the content names no instrument or the security has no active ISIN.
- Published At: When the content became visible. The feed is ordered by this, newest first.
- Topics: The subject areas the content covers, derived from its contents.
The default row is deliberately small
By default each row carries only 'id', 'contentType', 'ticker', 'exchange', 'ortexTid', 'ortexSid', 'ortexCid', 'isin', 'publishedAt' and 'topics'. The headline, body, provenance, pulse type, theme and identifiers each cost a query or a Markdown render per row, and most callers listing content are building an index rather than reading the articles. Ask for them with 'include' — for example 'include=headline,body' — and request only what you will use. 'body' is always the complete article, whatever its length — there is no separate detail call to make.
Pulling continuously
For an ongoing feed, store the largest 'publishedAt' you have received and pass it back as 'since' on the next request: only content published after that instant is returned. Content becomes visible at exactly its 'publishedAt' and is never published with an earlier timestamp, so a client that always feeds back its high-water mark misses nothing and never re-downloads what it has. Content generated in one batch can share a 'publishedAt' to the microsecond, so advance the mark only once every page of a pull has been stored — a pull abandoned mid-way must be repeated from the previous mark, or the rows sharing the last timestamp you kept are never returned again. Combine with 'content_type' to run one cursor per type.
Selecting one instrument
This feed does not filter by instrument. One instrument's content is /api/v11/stock/{namespace}/{identifier}/market_intelligence/content/, which takes the listing in the path like every other per-instrument endpoint and matches content on both its primary instrument and instruments mentioned in the body.
Retrieving a single row
Pass 'id' to return one row. This replaces the separate detail route in the previous API version: the response is the same envelope with a single entry in 'data', and an identifier matching nothing is an empty result rather than an error.
Content types grow over time
'contentType' is an open vocabulary — new types are added as ORTEX publishes new kinds of analysis. Treat an unfamiliar value as a row you can still read rather than an error, and do not hard-code an exhaustive list. Filtering on a type that does not exist returns an empty result rather than failing.
JSON only
Rows carry nested 'identifiers', 'provenance' and 'topics', so there is no tabular form to render: this feed returns JSON only, and 'format=csv' is not offered.
Try it out! You can test the API with the trial key TEST. Simply include it in your request headers; either here, or add the header "Ortex-Api-Key": "TEST" to your http request.
Trial key restrictions: Trial keys may be limited to a specific date range and set of regions. Requests outside the allowed regions or entirely outside the allowed date range are rejected; a date window that partially overlaps the allowed range is trimmed to it, reported in meta.restriction.
Get full access! Get a key at app.ortex.com/apis
