Contents Lesson 11 of 17

5 min read · practitioner

How do you track a company that does not have a ticker yet?

Most endpoints in this course are keyed on a symbol, and the exceptions — /bulk-fundamentals/{EXCHANGE}, /calendar/splits — are keyed on an exchange or a date window. An IPO calendar has a problem none of them has: the thing it describes may not have a symbol yet. How it solves that tells you a lot about how to consume it.

The endpoint

/calendar/ipos takes from, to (YYYY-MM-DD) and fmt. Same defaults as the earnings calendar: from is today, to is seven days out, and fmt defaults to csv.

There is no symbols parameter, and there could not usefully be one. The endpoint is effectively bulk across exchanges — you take a date window and receive everything scheduled in it.

The record

Two real rows from the documented response:

code: "603629.SHG"   name: "Jiangsu Lettall Electn Co Ltd"
exchange: "Shanghai" currency: "CNY"
start_date: "2018-12-11"  filing_date: "2017-06-15"
amended_date: "2018-12-03"
price_from: 0  price_to: 0  offer_price: 0
shares: 25000000   deal_type: "Expected"

code: "N/A"          name: "Gsp Resource Corp"
exchange: "TSXV"     currency: "CAD"
start_date: "2018-12-03"  filing_date: "2018-08-13"
price_from: 0.1523   price_to: 0.1523   offer_price: 0.2
shares: 2500000      deal_type: "Priced"

Those two rows come from the published documentation. Here is a real month of the calendar, fetched live, so you can check the shape against something nobody wrote by hand:

Live API response: ipo calendar august 2026

code can be the literal string "N/A". When the listing code is not yet known, the field carries that placeholder rather than a null or an empty string. Because it is a value and not a null, it compares equal to itself — so grouping or self-joining on code collapses every unknown IPO into one bucket, and joining to any other table that also uses "N/A" produces a cross product. Filter code != "N/A" before joining, and key on name plus exchange until a real code exists.

deal_type is the lifecycle field, and it is the one that carries the most information: Filed, Expected, Amended, Priced. A row does not appear once and stay put — it progresses. The Shanghai row above filed in June 2017, was amended in December 2018, and is still Expected. That is eighteen months of a company being visible in the data before it trades.

The zero that means "unknown"

Look again at the first row: price_from: 0, price_to: 0, offer_price: 0, with 25,000,000 shares. Multiply and you get proceeds of $0, which is obviously not what happened. Zero here means the price was not known at the time the record was written.

The second row is complete: 2,500,000 shares at an offer_price of 0.2 gives C$500,000 raised. Also note that offer_price (0.2) sits above the indicated range (price_from and price_to both 0.1523) — the final price is a separate fact from the range, and it does not have to fall inside it.

So the same discipline as everywhere else in this course: zero is a value, and here it is being used as a missing marker. Before you compute proceeds, filter to rows where offer_price > 0.

What this is genuinely for

Knowing what is about to list, on which exchange, in which currency, at what stage of the process. That is a coverage and operations question: which symbols will need to exist in your universe next month, and which ones you should stop expecting.

It is not a screen for anything. The record contains a date, a size and a status; nothing in it speaks to whether an offering is well or badly priced, and this course makes no suggestion either way. Note too that a calendar of future listings is a natural place for survivorship thinking to go wrong — the deals that quietly never priced are as much a part of the record as the ones that did.

Try it now

  1. The table above is /calendar/ipos?from=2026-08-01&to=2026-08-28&fmt=json read from its first rows; here are its last three. Check every code in both tables for the "N/A" placeholder. Across all 134 rows of that window the count was 0 on 28 September 2026, and the same held for every other month of 2026 we measured. So the join problem is real in the documentation and absent from this year's data: say what check your code should still keep, and why.
Live API response: mda1 ipo calendar august 2026 tail
  1. Group the rows in both tables by deal_type. The ratio of Expected to Priced tells you how much of the pipeline actually completes on schedule.
  2. Compute proceeds (shares × offer_price) for the rows shown, first naively and then excluding rows where offer_price is 0. Compare the totals, and say what that makes of the field in this window.