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:
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
- The table above is
/calendar/ipos?from=2026-08-01&to=2026-08-28&fmt=jsonread from its first rows; here are its last three. Check everycodein 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.
- Group the rows in both tables by
deal_type. The ratio ofExpectedtoPricedtells you how much of the pipeline actually completes on schedule. - Compute proceeds (
shares × offer_price) for the rows shown, first naively and then excluding rows whereoffer_priceis 0. Compare the totals, and say what that makes of the field in this window.