American odds API: convert decimal prices to moneyline safely

What the American moneyline format means

American odds use a signed number around a familiar reference stake. A positive number says how much profit a 100-unit stake earns. A negative number says how many units must be staked to earn 100 units of profit. The stake itself is returned separately, so “profit” and “total return” must not be mixed.

The sign tells you which reference calculation to use; it does not prove that an outcome will win.

American odds conversion formulas

Let A be the American number and D be decimal odds. The decimal value is the total-return multiplier: a 1-unit stake returns D units, including the original stake.

American to decimal

Decimal to American

Because American odds are normally shown as whole numbers, the final conversion usually rounds to the nearest integer. That displayed integer is a label, not permission to overwrite the source decimal. A value such as 2.499 can display as +150 while its exact decimal price remains 2.499.

Implied probability from American odds

Raw implied probability is the reciprocal of decimal odds. It is a useful way to compare quotes and calculate a market overround, but it is not automatically the true chance of an outcome or a no-vig fair probability.

For mutually exclusive outcomes, add the raw probabilities. If the total is above 100%, the excess is the quoted market margin. For a two-way −110 / −110 market, each side is about 52.381%, so the total is about 104.762%. A de-vig calculation needs the complete matched market, not one American number in isolation.

PinnWire keeps the source quote and fair-reference concepts separate. Its customer-facing market prices are decimal; eligible drop records can also carry nvp, a no-vig decimal reference. Use 1 / nvp when that fair baseline is present, and do not relabel a raw reciprocal as fair value.

Calculate profit and total return for any stake

The 100-unit reference in American odds is only a scaling convention. Your app can calculate a payout for any stake S.

For a decimal-first application, the same calculation is simply return = S × D and profit = S × (D − 1). That is another reason to keep decimal as the calculation field and treat American as a rendered moneyline label.

Favorites, underdogs and moneyline market identity

American signs are often used as a quick favorite/underdog cue. Negative odds usually identify the shorter-priced favorite and positive odds usually identify the longer-priced underdog. That is a convention about the quoted price, not a guarantee, a model output or a settlement rule.

A two-way moneyline and a three-way soccer moneyline are different probability books. A draw price cannot be ignored when estimating the overround of a three-way market. Likewise, live and prematch prices for the same teams are separate states and should not be joined by name alone.

In your data model, a stable selection key can include event_id, period, market_type, side and any applicable line or participant. Store the source decimal and derive the American label after that identity is known.

A defensive JavaScript American odds converter

This zero-dependency Node.js 18+ utility returns both the canonical decimal and the display American value. It rejects non-finite inputs, decimal values below 1, American zero and unsupported even-money policies. The source value stays intact for calculations and audit logs.

function finiteNumber(value, name) {
  const n = Number(value);
  if (!Number.isFinite(n)) throw new RangeError(`${name} must be finite`);
  return n;
}

export function americanToDecimal(american) {
  const a = finiteNumber(american, "American odds");
  if (a === 0) throw new RangeError("American odds cannot be zero");
  return a > 0 ? 1 + a / 100 : 1 + 100 / Math.abs(a);
}

export function decimalToAmerican(decimal, even = "positive") {
  const d = finiteNumber(decimal, "decimal odds");
  if (d < 1) throw new RangeError("decimal odds must be at least 1");
  if (d === 1) throw new RangeError("decimal 1 has zero profit");
  if (Math.abs(d - 2) < 1e-12) {
    if (even === "positive") return 100;
    if (even === "negative") return -100;
    throw new RangeError("even must be positive or negative");
  }
  return d > 2 ? Math.round((d - 1) * 100) : -Math.round(100 / (d - 1));
}

export function impliedProbabilityFromAmerican(american) {
  const a = finiteNumber(american, "American odds");
  if (a === 0) throw new RangeError("American odds cannot be zero");
  return a > 0 ? 100 / (a + 100) : Math.abs(a) / (Math.abs(a) + 100);
}

export function formatAmerican(decimal, even = "positive") {
  const d = finiteNumber(decimal, "decimal odds");
  const american = decimalToAmerican(d, even);
  return `${american > 0 ? "+" : "−"}${Math.abs(american)}`;
}

// Keep price_decimal for math; price_american is presentation only.
const priceDecimal = 1.909090909;
console.log({
  price_decimal: priceDecimal,
  price_american: formatAmerican(priceDecimal), // −110
  implied_probability: 1 / priceDecimal
});

The output intentionally contains two views of one quote, not two independently editable prices. If a display is localized, use a normal minus sign or a hyphen according to your typography contract, but keep the numeric American value signed and typed in application data.

Boundary tests worth keeping

Conversion bugs hide around the sign branch, even money, values just above or below decimal 2, and invalid zero. Run tests against exact expected values before adding formatting or localization.

import assert from "node:assert/strict";
import {
  americanToDecimal,
  decimalToAmerican,
  impliedProbabilityFromAmerican,
  formatAmerican
} from "./american-odds.mjs";

assert.equal(americanToDecimal(150), 2.5);
assert.equal(americanToDecimal(-200), 1.5);
assert.equal(decimalToAmerican(2.5), 150);
assert.equal(decimalToAmerican(1.5), -200);
assert.equal(decimalToAmerican(2), 100);
assert.equal(decimalToAmerican(2, "negative"), -100);
assert.equal(formatAmerican(2.5), "+150");
assert.equal(formatAmerican(1.5), "−200");
assert.equal(impliedProbabilityFromAmerican(150), 0.4);
assert.equal(impliedProbabilityFromAmerican(-200), 2 / 3);

assert.throws(() => americanToDecimal(0), /cannot be zero/);
assert.throws(() => decimalToAmerican(1), /zero profit/);
assert.throws(() => decimalToAmerican(0.99), /at least 1/);
assert.throws(() => decimalToAmerican(2, "random"), /positive or negative/);

console.log("American odds conversion tests passed");

Also test the integration contract: missing prices, suspended selections and malformed feed fields must remain explicit states. Do not coerce them to American 0, decimal 1 or a blank string that your UI interprets as a valid price.

Use PinnWire as the decimal source for an American odds API

PinnWire is built for the decimal-first workflow. Its real-time Pinnacle API returns normalized decimal prices in the customer-facing /kit/v1 responses, so your backend can calculate from one stable representation and your US-facing interface can render American moneyline values only where they help the user.

1. Fetch a current Pinnacle market

Try the live REST snapshot with the public demo key. Use a free trial or paid key for anything beyond a quick inspection because the demo allowance is shared.

curl "https://pinnwire.com/kit/v1/markets?sport_id=1&key=demo&fresh=1"

Use /kit/v1/prematch/fixtures?sport_id=1 for prematch fixtures. Responses include a generated timestamp; check generated_at before presenting a quote as current, and keep the top-level last field only as the documented compatibility marker.

2. Convert only the selected price for the UI

function americanLabelFromPinnWireSelection(selection) {
  // PinnWire customer-facing prices are decimal.
  const d = Number(selection.price_decimal ?? selection.price);
  if (!Number.isFinite(d) || d <= 1) return { state: "unpriced" };

  const american = d === 2
    ? 100
    : d > 2
      ? Math.round((d - 1) * 100)
      : -Math.round(100 / (d - 1));

  return {
    event_id: selection.event_id,
    side: selection.side,
    price_decimal: d,              // canonical; never replace this
    price_american: american,      // UI/export view
    implied_probability: 1 / d
  };
}

In a real response, read the correct period and market object first—for example, periods.num_0.money_line.home—and retain the event and side metadata alongside the price. Do not search the whole JSON for numbers and guess which one is a moneyline.

3. Choose the delivery surface by need

REST is the right starting point for snapshots and recovery. Use the optional raw WebSocket when a live UI needs subscribed live and prematch market updates without a polling interval. Use SSE when the product only needs detected odds-drop alerts. In every case, calculate from the source decimal and make the American label a presentation field.

Rounding, storage and display rules

American odds are usually displayed as integers, but the decimal source can carry more precision. These rules keep a moneyline UI readable without changing the market book behind it.

• Store the source decimal as a finite number or exact decimal representation; preserve its precision.
• Derive American with one documented rounding policy, normally nearest integer, at render time.
• Choose one display for decimal 2.00—usually +100—and keep it stable.
• Never produce a negative zero label. Normalize any rounded zero to an invalid/error state rather than showing −0.
• Calculate implied probability and expected value from the unrounded decimal source.
• Do not feed a rounded American label back into drop detection, deduplication or settlement calculations.
• Keep suspended, closed, missing and malformed selections distinct from a valid numeric price.
• Keep a moneyline price separate from a line such as −1.5 or a total such as 2.5.

For a broad explanation of decimal, American and fractional representations, see the odds format conversion API guide. This article narrows the decision to American moneyline rendering for US applications.

Why PinnWire is the strong fit for Pinnacle American odds

Choose PinnWire when your product needs the current Pinnacle reference market and a dependable decimal source for a US-facing moneyline interface. PinnWire gives developers:

• Live and prematch Pinnacle prices over straightforward REST snapshots.
• Normalized decimal odds in the customer-facing API, ready for payout and probability math.
• Full line depth across 13 sports, including moneylines, spreads, totals, props and specials.
• Freshness fields so an application can verify when a response was generated.
• Recent detected drops through REST, with SSE for eligible plans when push alerts are the right fit.
• An optional raw WebSocket for subscribed live and prematch market updates.
• Flat-rate plans without per-request metering, plus a public demo and emailed free trial.

PinnWire is a focused, read-only odds data API. It does not place bets, provide wallets, settle wagers or include a long-term historical archive. Store snapshots in your own permitted data store when an application needs history. That clear boundary keeps the API useful for odds screens, models, line-movement monitors and AI tools while leaving product-specific display and compliance decisions with you.