Contents
How the decimal odds multiplier works
The decimal number represents total return rather than profit alone. At 2.50, each unit of stake corresponds to 2.5 units returned in total. At 1.50, each unit corresponds to 1.5 units returned. The profit portion is whatever remains after the original stake has been removed.
Stake: 10 Decimal odds: 2.50 Total return = stake x decimal odds Total return = 10 x 2.50 Total return = 25 Profit = total return - stake Profit = 25 - 10 Profit = 15
This makes total-return calculations a single multiplication. The distinction between return and profit still matters in the UI, however. If a component is labelled “return”, displaying only 15 units in the example above would omit the original 10-unit stake and therefore show the wrong figure.
Why 1.00 is the decimal odds boundary
A decimal price of 1.00 represents a total return equal to the original stake, so the profit is zero. Under the normal decimal-odds convention, a valid betting price does not fall below 1.00, because a multiplier below one would represent a total return smaller than the amount staked.
For developers, this creates a useful validation rule. A price such as 1.50 is perfectly normal and represents a return of 1.5 times the stake. A price of 0.85, by contrast, should not be accepted as a conventional decimal betting price without first checking whether the source uses a different field convention.
This is also why a price does not need to be above 2.00 to be valid. 2.00 is simply even money in decimal format. Prices between 1.00 and 2.00 represent shorter prices where the profit is smaller than the original stake.
How decimal prices appear in our Odds API
Our Odd entity includes value, dp3, american and probability alongside identifiers such as fixture_id, market_id, bookmaker_id and label. Current documentation shows a Home selection with value: "1.48" and dp3: "1.480" on the same odds record.
For an application consuming our data, the important implementation rule is consistency. If calculations, comparisons or historical records use value, keep using value throughout that workflow. If the application standardises on dp3, use dp3 for both sides of the comparison. Do not mix one field for an opening snapshot and another for a later snapshot simply because both look like decimal prices.
The current documented example does not prove that dp3 always contains more underlying price information than value. In the example, 1.48 and 1.480 represent the same number. The safer interpretation is therefore that dp3 provides a fixed three-decimal representation, while value provides the standard decimal field returned on the odd object. The application can choose the representation appropriate for its own data model without assuming one necessarily contains hidden precision the other has lost.
Decimal odds and implied probability
Decimal odds can be converted directly into implied probability using:
implied probability = 1 / decimal odds 2.00: 1 / 2.00 = 0.50 = 50% 1.50: 1 / 1.50 = 0.6667 = 66.67% 2.50: 1 / 2.50 = 0.40 = 40%
Our odds objects already include a probability representation alongside the bookmaker price, so an application consuming our Odds API can use the returned percentage rather than recalculating it purely for display. The same percentage should still be treated as market-implied probability, not as the same thing as the probabilities generated by our Football Predictions API. Our Predictions API provides model-generated probabilities for football outcomes through dedicated prediction endpoints and fixture includes.
Keeping those two concepts separate in the data model prevents a bookmaker-derived percentage and a Sportmonks prediction from being stored under one ambiguous field name.
Converting decimal odds to American odds
When decimal prices need to be converted into American odds, the formula depends on which side of 2.00 the price sits.
Decimal odds >= 2.00 american = (decimal - 1) x 100 2.50: american = (2.50 - 1) x 100 american = +150 Decimal odds < 2.00 american = -100 / (decimal - 1) 1.50: american = -100 / 0.50 american = -200
The split exists because American odds use different positive and negative conventions around even money. When consuming our odds response, however, this conversion is generally unnecessary for display because the odd object already includes an american field alongside the decimal price.
That is a useful pattern for multi-format interfaces: keep the selection identity stable through fixture_id, market_id, bookmaker_id and label, then choose the returned price representation needed by the frontend rather than repeatedly converting formats yourself.
Common decimal odds implementation mistakes
One common problem is confusing total return with profit. Decimal odds already include the stake in the multiplier, so stake × odds gives the total return. Subtract the stake only when the UI specifically needs the profit amount.
Another issue is rejecting perfectly valid prices simply because they are below 2.00. Decimal odds such as 1.40, 1.65 or 1.90 are valid conventional prices. The meaningful lower boundary is 1.00, not 2.00.
A third mistake is mixing value and dp3 inside the same calculation or historical series. Even when the visible numbers are equivalent, a stable data pipeline should choose one field representation for that workflow and stick to it.
Finally, avoid converting between formats repeatedly if the API already returns the representation you need. Each extra conversion creates another place for rounding differences to appear without adding new information.
Building a decimal-odds interface with Sportmonks
A betting, odds-comparison or trading product can keep decimal prices as its internal or displayed representation while using the same fixture, market and bookmaker structure throughout the integration. Our Football Predictions API can then sit alongside the odds feed when the product also needs model-generated probabilities for fixture outcomes.
This separation is useful for builders because bookmaker prices and prediction probabilities remain related through the fixture without being treated as the same dataset. The frontend can show decimal odds, implied probability and model probability together while still preserving where each value came from.
Related reading
Integrating Odds Data: Using Sportmonks’ Odds API for Smarter Betting Apps covers how bookmaker, market and selection data fit into an odds-driven product. The article is currently live on our site.
How-to use the Sportmonks’ Football Predictions API explains how our model-generated probabilities can be requested and used alongside football and odds data.
The new way of AI football predictions provides another live walkthrough of working with our Predictions endpoints and fixture-level probability data.
Faqs
