TOOL NOTES

Store odds as decimal and convert at the edges

Decimal is the format the API serves and the only one your database should hold. American and fractional are display languages, translated at the edge.

Every price that leaves the Pinnacle odds API arrives as a decimal number. Your storage should keep exactly that number, and conversion should run only at the boundary, when a human needs American or fractional on a screen. The moment a price is stored in a display format, every calculation after it starts with a translation and ends with a rounding.

Decimal is the wire format

The API serves decimal odds, and decimal is the format every formula in this space assumes: implied probability is 1 divided by the price, fair prices come out of margin removal in decimal, and expected value multiplies the price by a probability. Storing the served value keeps your data one division away from every calculation.

American and fractional formats are presentational. They exist because some audiences read +150 faster than 2.50, not because they compute better.

The round-trip problem

The odds converter carries the warning in its precision notes: displayed decimal odds use four places and American at most two, and rounding a displayed price and converting it back can change the last digits, as its page states, checked 2026-10-03. Store -110 and you have stored a rounded display value; the decimal it came from, 1.90909 recurring, is already gone.

Fractional fares no better: the converter approximates fractions with a denominator capped at one million. A price that has been rounded for display is a price with a small, silent error welded in.

Convert once, at the boundary

The rule that keeps a system honest: convert when the price enters, never again. On ingest, the value goes into storage as the decimal the API sent. On display, a formatter turns it into whatever the audience reads. In between, every comparison, every diff and every margin calculation runs on the stored decimal.

Three traps disappear with this rule. String comparisons fail silently across formats: 1.91 and -110 are the same price and look nothing alike. Aggregations double-count when two formats of one price land in one table. And drift detection breaks when the comparison includes a rounding step. The normalization guide covers the identity side of the same discipline: keys for what the price is, separate from the value you store.

When you inherit a mixed table

If you already store American or fractional somewhere, convert forward once and freeze: add a decimal column, fill it by conversion, and make the old column read-only. The converter documents the full rule set for both directions, including the rejection of American values between -100 and +100, checked 2026-10-03.

One canonical format, two display languages, zero arithmetic on strings. Store what the wire sent; translate only for humans.