Buyers usually check whether an odds feed works, not whether they could leave it. In this expert column, Rhyan Morice, Director of Customer Acquisition at Odds API, sets out how to prove that saved comparisons and price alerts survive a move to a second feed, and why that test belongs in the supplier comparison.
- An export only proves records can come out. The test is whether a second feed maps them to the same fixture, market, period, line and selection.
- Close is not equivalent: first-half over 2.5 and over 2.75 both fail against a full-match over 2.5 alert, however similar the price.
- A "winner, full time" market with unspecified rules stays unresolved until the supplier says whether extra time counts.
- Make the sample export, mapping report and a working comparison and alert part of supplier acceptance, and price the exit alongside the subscription.
Before signing an odds-feed contract, I'd want to see one saved comparison and one price alert working against a second feed. Both should still point to the same fixture, market and selection, with the customer's settings intact.
An export proves that you can get records out. It does not prove that another supplier can make sense of them. You could import every row successfully and end up with an over 2.5 goals alert watching the first half.
That is worth finding out while suppliers are competing for the contract. A sample export and trial data from another feed let the buying team attempt the move. The result should show how much work it takes and which records cannot be mapped safely.
You can then compare the quoted price with a clearer idea of what it would cost to leave.
What needs to survive
Start with something your product already saves. A comparison tool might store a fixture reference, selected markets and a price alert. An operator using the feed for trading will need a broader exercise covering settlement and corrections.
The saved record depends on more than its display name. It needs to identify the event, the period being played and the outcome being priced. A line such as 2.5 is part of that meaning, rather than a detail the importer can replace with the nearest available number.
The price source matters too. The bookmaker quoting the odds and the supplier delivering them are separate things. Moving between feeds while watching the same bookmaker can preserve an alert. Quietly moving the alert to a different bookmaker changes what the customer asked for.
Keep the original supplier IDs alongside your own references. A replacement feed will have its own identifiers, so the team needs to record how the two relate. Overwriting the old reference makes a later mistake harder to trace.
Historical quotes also need to retain their source and timestamp. A new supplier cannot become the source of an old price just because its ID now appears in the record.
Use a fixture with clear rules
Take a synthetic football fixture: Northbridge Athletic at home to Eastport Rovers in the fictional Harbour Cup, scheduled for 7 November 2026 at 15:00 UTC. The teams, competition, IDs and schemas here are invented.
Schema A stores one flat record per selection. Schema B groups outcomes inside markets within an event, with lines stored as market parameters. A calls the fixture fx1042; B calls it event7719.
Confirm the competition, participant identities, home and away roles and scheduled time before saving the relationship between those IDs. Similar team names can refer to reserve or youth sides. If two target events are plausible, leave the record unresolved until the team can establish which is correct.
Both schema dictionaries define regular time as 90 minutes plus added time, excluding extra time and penalties. They also define Northbridge as the home side. For the Asian handicap example, both apply the signed line to the selected team and split a minus 0.25 stake equally between zero and minus 0.5.
The table assumes corresponding settlement rules agree, including cancellation and abandonment treatment.
| Saved record in A | Candidate in B | Decision |
|---|---|---|
| Event fx1042: Northbridge v Eastport | Event event7719: same competition, teams, roles and kick-off | Match |
| Northbridge to win; three-way; regular time | Home competitor to win; three outcomes; 90 minutes plus added time | Match |
| Over 2.5 goals; regular time | Total goals; over; line 2.5; same period | Match |
| Over 2.5 goals; regular time | Over 2.5 goals; first half | Reject |
| Over 2.5 goals; regular time | Over 2.75 goals; regular time | Reject |
| Northbridge -0.25; two-way Asian handicap; regular time | Home competitor -0.25; same period and settlement rules | Match |
| Northbridge to win; three-way; regular time | Home competitor; winner; full time; rules unspecified | Unresolved |
Synthetic fixture and invented schemas. Accept a mapping only where the event, period, selection and settlement rules agree.
The last row needs an answer from the supplier. "Winner" and "full time" do not establish whether extra time counts or whether a draw is an outcome.
Suppose this synthetic single-leg cup tie finishes 1–1 after 90 minutes. Northbridge scores the only extra-time goal and qualifies with a 2–1 win. A regular-time bet on Northbridge to win loses; a bet on Northbridge to qualify wins. Mapping one to the other would change the customer's bet, even though both name the same team.
The rejected totals are clearer. First-half over 2.5 and whole-match over 2.5 count different goals. Over 2.75 has different settlement behaviour from over 2.5. Neither becomes equivalent because its price looks close.
Converting price formats comes after matching the selection. Fractional and decimal odds can describe the same quote, subject to rounding. That conversion cannot correct a period mismatch, a changed line or a price attributed to the wrong bookmaker.
These failed mappings give the buyer specific questions to resolve. The team can see exactly where the proposed integration needs better documentation or a decision about coverage.
See what the customer would get
For the synthetic fixture, save an alert for full-match over 2.5 goals, from an identified bookmaker, at decimal odds of at least 2.00.
With a fresh, available price of 2.02 for the equivalent selection in B, the alert should work as before. If B supplies only the first-half market or the 2.75 line, the product should show that it has no verified replacement and explain why. It must not quietly attach the alert to another selection.
The alert's rules for availability and price age are part of the record being moved. An alert configured to notify only on current, available prices must continue to exclude suspended markets and stale quotes. Its maximum price age needs to be agreed before the trial, so the result can be judged against a fixed requirement.
The saved comparison should also work in the replacement environment, with each event and selection traceable to a source record. A screen displaying familiar team names is not enough to establish that its references survived.
Postponement and a changed kick-off time test whether saved records follow the documented event relationships or create duplicate fixtures. Repeating the import, then interrupting and restarting it, exposes duplicated alerts and lost records.
A useful report accounts for every attempted record. It separates confirmed matches from unresolved mappings and unsupported markets, with a reason for each. Removing awkward rows before calculating a success rate hides work the buyer will still have to pay for.
Those categories carry different costs. An unsupported market is a coverage gap: the replacement does not provide what the record needs. An unresolved mapping needs more evidence before it can be accepted. The buyer needs to know which problem remains and who can resolve it.
Price the exit before you buy
One synthetic fixture shows how to run the exercise. A buying decision needs a representative sample of the sports and markets the business uses, including records that require manual review.
Engineering time and manual decisions belong in the cost of switching. If hundreds of saved market names need interpreting, someone has to do that work. The acceptance report should identify who will handle it and what customers will see while their comparisons or alerts remain unavailable.
An engineer outside the original integration team should be able to work from the sample export and documentation. If they need the person who built the first integration to explain every field, the handover still depends on knowledge missing from the supplied material.
Event merges, ID changes and corrections also need a documented path. The team needs to know how those changes are communicated and how existing references will follow them. Retaining the definitions used to approve each mapping, with their version or retrieval date, helps explain historical records after a schema changes.
The contract should address export format, delivery time, fees and access during notice. It also needs to establish what data can be retained and used after termination. A working trial endpoint does not settle those terms.
Timing belongs in that agreement. The replacement supplier needs enough access and documentation to review the export before the handover. If that work can only start after the old service ends, the buyer should plan for the resulting gap.
I would make the sample export, mapping decisions and working comparison and alert part of supplier acceptance. Each unresolved case should have an owner and a clear decision about whether it must be fixed before signing.
Include the engineering time and unresolved records in your supplier comparison. A cheaper subscription may come with a more expensive exit.
Disclosure. The author has a commercial interest in an odds-data business and a betting comparison product. This is an expert column; the views are the author's own. Find odds and data suppliers on the data and trading category page.
