Why is a stock split stored as a string?

/splits/{ticker} returns the plainest response in this whole course — two fields — and it still manages to contain a parsing trap and a direction trap. Both are worth five minutes now rather than an afternoon later.

The record

Parameters: from, to, fmt (json or csv, default json).

split is a string, formatted {new shares}/{old shares}. Not a float, not two fields — a string you have to split on / and cast. "2.000000/1.000000" means two new shares for every one old share.

It is a string for a good reason: ratios are not always clean. "3.000000/2.000000" is a real shape, and storing it as the float 1.5 loses the fact that it was expressed as 3-for-2. Keeping the pair lets you reconstruct exactly what was announced.

The direction trap

Compute the factor as new ÷ old.

• "4.000000/1.000000" → factor 4. A forward split. You end up with more shares, each worth proportionally less.
• "1.000000/10.000000" → factor 0.1. A reverse split. Ten shares become one.

Now the part that catches people: the upcoming-splits calendar encodes the same idea in the opposite field order. /calendar/splits returns old_shares and new_shares as separate integers, and a real record from it reads old_shares: 3, new_shares: 1 — a 1-for-3 reverse split. Meanwhile /splits/{ticker} would express the identical event as the string "1.000000/3.000000". Same event, two endpoints, mirrored layouts. If you build one parser and reuse it on both, half your reverse splits will come out as 3x forward splits.

Multiplying them out

The factors compound, and where you start matters. From June 2000 onward: 2 × 2 × 7 × 4 = 112. Include 1987 and the whole history compounds to 224.

So one share bought before June 2000 — but after 1987 — is 112 shares today, and a price of $112 in 1999 appears as $1.00 in a split-adjusted series. A share bought in 1986 is 224. State the window with the factor, always; a compounding number without a start date is not an answer. Nothing was lost or gained — the same claim on the same company is simply divided into 112 pieces. This is exactly the arithmetic behind the adjusted close from the Price and Trading Data course, and the next lesson closes that loop properly.

What splits are not

Not every odd ratio is a split. Spinoffs frequently arrive in split data as strange fractions, because the mechanical effect on the share price resembles one: a company hands shareholders stock in a separated business, and the parent's price drops by the value that left. A ratio like "1.000000/1.000000" — no change at all — or a lumpy non-round number is a signal to go and read the announcement rather than to trust your parser.

There is no field in this response that tells you which is which. That is a genuine limitation, and the honest workflow is: treat unusual ratios as a flag for manual review, and cross-check against news or a filing before you let one rewrite a decade of history.

Try it now

1. The split table at the top of this lesson is /splits/AAPL.US in full. Multiply all the factors together. You get 224, not 112 — the difference is the 1987 split, and noticing it is the exercise. Now multiply only the rows from June 2000 onward, divide the raw 1999 close below by that, and compare to the adjusted close for the same day. Say what the remaining gap is made of.

2. Write a parser that takes the split string and returns a float factor. Test it on "1.000000/10.000000" and make sure it returns 0.1, not 10.
3. Here is /calendar/splits for one settled day, 14 September 2026. Find the record where old_shares exceeds new_shares, and say out loud what happens to a holder of 300 shares in it, and in the other record. Then write each one as the "new/old" string /splits/{ticker} would use. That sentence and those two strings are the whole difference between the two conventions.