API Enterprise

Monthly revenue disclosures, as a feed: every reading in the Monthly Revenue dataset published in a date window, for every covered company in a region. Each row is one reading of one series for one entity a company is reported under (named in entityRef), with its ORTEX company id beside it.

Built for enterprise consumers who keep their own copy: uncharged, windowed on the publication date so an incremental pull is complete, and joinable onto the rest of ORTEX on ortexCid.

Available Data Points:

• Company: The name of the company issuing the security.
• Ortex Company ID: Unique id for a company.
• Period Date: The period the value describes — what the number is about (the valid clock).
• Published At: When the value first became knowable — when the publisher released it (the knowledge clock). Filter on this for anything where look-ahead bias would matter.
• Value: The numeric value, where the series has one.
• Value Text: The textual value, for categorical series such as a trial's status or phase.
• Unit: Unit of the value, e.g. vehicles, percent, USD.
• Value Type: number, percent, currency, count or text.
• Frequency: How often the publisher releases the series.
• Market: The market the reading describes — an ISO-3166 alpha-2 code (DE), a sub-national one (US-CA), a supranational aggregate (EA, EU) or GLOBAL.
• Series Slug: Which series the reading belongs to. Unique within a publisher, not globally.
• Series Name: Human-readable name of the series.
• Source Slug: Publisher/feed identifier, e.g. kba_registrations.
• Source Name: Human-readable name of the publisher or feed.
• Publisher: Who publishes the underlying data.
• Entity Ref: The publisher's own identifier for what the reading is about — a manufacturer name, a securitisation trust, a reactor unit, a country code. Kept so any value can be traced back to the row it was parsed from.

Coverage

Taiwan-listed issuers, published between the 8th and 14th of each month for the prior month. Monthly, in New Taiwan dollars for the level series and percent for the growth ones.

What to look for

Use monthly_revenue_yoy_pct rather than the level for anything comparative: these businesses are strongly seasonal and month-on-month moves are mostly calendar.

cumulative_revenue_ytd is a running total, not a monthly figure — differencing it and then comparing to monthly_revenue double-counts.

For read-through, the supplier's month leads the customer's quarter, not the other way round. Treating a supplier print as confirmation of a customer's already-reported quarter discards the entire lead.

The window selects on publication, not the period

Every reading has two dates. periodDate is what the number is about; publishedAt is when it first became knowable. from_date and to_date select on the second: the response is every reading published on those days (inclusive, in UTC), oldest publication first. from_date is required; to_date defaults to today; the window may span at most one year, and a longer one returns 400 invalidDateRange.

That is the shape for keeping a copy of the dataset. Pull the previous day's window each morning and nothing is missed - including a publisher restating a period months old, which reappears with its new publishedAt and value. Upsert on ortexCid, sourceSlug, seriesSlug, entityRef and periodDate. A backfill walks the history a year at a time, and replaying it in publishedAt order never uses a reading before it was public.

The company name and region are resolved as they stood on to_date.

Filtering: one market or all of them

Called with no filters, the endpoint returns every series in the dataset, for every market ORTEX covers it in. Each row names its own market, seriesSlug and sourceSlug, so a single request is enough to chart the whole dataset.

Narrow it with any combination of market (one market), series (one measure) and source (one publisher). Filter values that are each valid but select nothing together return 400 invalidSelection rather than a misleading empty result.

Raw readings here; comparable ones next door

This endpoint serves the publisher's numbers. Raw values are frequently not comparable — receivables of $10.9bn against $4.9bn say nothing without each book's size, and a 5.3% charge-off rate means something different on a subprime book than a prime one. The Alt Data signals endpoint serves the same series as percentiles and z-scores against a stated comparison set, which is the form a screen or a backtest wants.

Why a company you expect may be missing

Three reasons, and none of them is a bug:

• The dataset is a window, not a census: Several of these publishers release a rolling window rather than a complete history.
• The filer is not the listed company: Registers name a marque, a charter or a trust. ORTEX maps those to the listed parent where the link is defensible and leaves them unmapped where it is not — a wrong mapping silently attributes another company's data to your ticker.
• The population is genuinely narrow: Not every listed company appears in every register, and no amount of mapping changes that.

How much history there is

Several of these publishers overwrite their own pages and keep no archive. Where that is so, the series begins on the day ORTEX started capturing it and lengthens from there — nobody, including the publisher, can supply the days before that. Everything ORTEX has ever fetched is archived on capture, so the series only ever grows.

Company and region

Each row is about a company, so it carries the company's name (as it stood on the date the response is about) and ortexCid, the ORTEX company id - the key to join onto every other ORTEX dataset. Listing and security identifiers are deliberately absent: the reading describes the company, not one of its listings.

region selects the companies: a region name, an ISO-2 country code, or ALL (defaults to US). A company is placed by the country of the exchange of the listing ORTEX files each reading against, as it stood on the date the response is about - not by where it trades today, and not by its domicile. For a company listed in several countries the region follows that listing, so a reading ORTEX files against the company's listing in another region appears under that region instead.

Only readings ORTEX has attributed to a listed company are returned. A publisher entity ORTEX could not map to a listed parent has no exchange to place in a region, and is left out rather than guessed; the per-instrument endpoint documents the same mapping rules.

The state of the dataset on one date

To ask what the latest known reading was for every company on a given day, use the sibling snapshot endpoint without published/, which takes a single date.

Date-restricted keys

A key whose access is limited to a date range is held to it on the knowledge clock these endpoints select on: a snapshot date outside the range is refused, and a publication window is clipped to it (reported in meta.restriction). A reading published inside the range can describe a period before it, so periodDate values earlier than the range are expected.

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! Contact [email protected]