Use these copy-ready prompts to go from UI mockups to a working odds-api.net widget that shows upcoming games, bookmaker prices, live updates, best odds, and fair odds value signals.
Live oddsMCPFair odds
Prompt 1
Create the UI mockups before writing code.
I want to build a live odds widget for a betting website using odds-api.net.
Before writing code, create three UI mockups for an NBA moneyline odds widget.
Goal:
Design a compact widget that can sit inside a betting website and show upcoming games, teams, start times, bookmaker odds, and the best available price.
Requirements:
- Show upcoming NBA games.
- Focus on moneyline odds only for this first version.
- Use decimal odds.
- Use Australian sportsbooks/bookmakers in the mock data.
- Make the best available odds easy to identify.
- Keep the widget compact enough to embed on a betting website.
- Include clear states for:
- loading
- live/updating
- no games available
- stale or disconnected data
- Do not add unrelated betting tips, predictions, or extra analytics yet.
- Create three different visual options.
- Keep the UI clean, readable, and practical.
After creating the mockups:
1. Recommend the strongest option.
2. Explain why it is the best fit for a live odds widget.
3. List the exact fields the coding agent should build from the chosen mockup.
Prompt 2
Turn the selected mockup into a working odds widget with mock data.
Use the selected UI mockup/reference image to build a working live odds widget.
For this stage, use mock odds-api.net data only.
Goal:
Create the frontend and service structure for a live odds widget that can later switch from mock data to real odds-api.net data.
Requirements:
- Match the selected mockup closely.
- Only fill in the fields shown in the design.
- Use decimal odds.
- Use Australian sportsbooks/bookmakers in the sample data.
- Show upcoming NBA moneyline markets.
- Include:
- event ID
- home team
- away team
- start time
- bookmaker
- selection/team
- decimal odds
- best available odds per selection
- last updated timestamp
- Use the odds-api.net MCP or existing project integration pattern if available.
- Use mock data first so no API credits are used during layout and interaction testing.
- Structure the code so the data source can be swapped to real odds-api.net calls later.
- Add a simple live update simulation so odds can change on screen.
- Add a visible status for connected, updating, stale, and disconnected states.
- Do not place bets.
- Do not scrape sportsbooks.
- Do not add arbitrage calculations.
- Keep the code simple and easy to extend.
Before writing code:
1. Inspect the project structure.
2. Identify where the widget should live.
3. List the files you plan to create or modify.
4. Then implement the widget.
After implementing:
- Run relevant tests or linting if available.
- If no tests exist, add a small test for the odds grouping/best-price display logic.
- Show me how to run the widget locally.
Prompt 3
Switch to real data, add fair odds highlighting, and validate it works.
We have a working live odds widget using mock odds-api.net data.
Now switch it to real odds-api.net data and add fair odds value highlighting.
Goal:
Use real upcoming events and odds from odds-api.net, stream or refresh live updates, and highlight prices where the best available odds are greater than the fair odds value.
Requirements:
- Do not rewrite the widget unless absolutely necessary.
- Replace mock data with real odds-api.net requests.
- API keys must come from environment variables. Do not hardcode secrets.
- Use the odds-api.net MCP, package, SDK, or cleanest existing integration pattern in the project.
- Pull upcoming NBA events first.
- Pull moneyline odds from available bookmakers.
- Use decimal odds only.
- Include the fair odds field if available from odds-api.net.
- For each selection:
- identify the best available bookmaker price
- compare best available odds against fair odds
- highlight the price when best available odds are greater than fair odds
- Make the value highlight clear but not misleading.
- Label it as a potential value opportunity, not a guaranteed profitable bet.
- Keep showing last updated timestamps.
- Add stale data handling:
- show when odds have not updated recently
- show when the stream disconnects
- reconnect or fall back to polling if the existing project pattern supports it
- Validate the request flow:
- upcoming events request
- odds snapshot request
- streaming or refresh request
- Add logging for request count, events loaded, odds entries loaded, stream updates, stale data, and errors.
- Add basic error handling for missing API keys, empty events, empty odds, malformed responses, rate limits, and stream failures.
- Do not place bets.
- Do not add arbitrage detection yet.
- Do not add a full betting strategy.
After implementing:
1. Run tests or linting.
2. Confirm the widget renders real events.
3. Confirm odds update live or refresh correctly.
4. Spot-check at least one displayed price against the source data.
5. Explain any limitations or places where the widget can still break.