Building a Betfair Trading Dashboard with the API

This page contains affiliate links — if you open an account through them we may earn a commission at no cost to you. It never changes our verdict.

This is a sub of our Betfair API developers' complete guide, and it's the natural project to build once you can reliably pull data from the API. A dashboard isn't a trading bot — it doesn't place bets — which makes it a perfect first serious API project: lower stakes, genuinely useful, and it forces you to learn the data model. If you can't yet pull prices, start with the Python tutorial or the Node.js guide, then come back to turn that data into something you can see.

Why build a dashboard at all

The honest case for a dashboard is that most traders fly blind on their own performance. They have a vague sense of whether they're up or down, no clear picture of which markets or strategies make money, and no live view of their exposure. The Betfair site and trading software show you the market in front of you, but they don't synthesise your activity into a picture you can learn from. A dashboard does three jobs: it shows you the present (open positions, live prices, current exposure) so you trade with full awareness; it shows you the past (P&L over time, win rate by market) so you can tell what's actually working; and it shows you patterns you'd never spot in a list of bets. The point isn't pretty charts — it's turning the data you're already generating into decisions, like cutting a market type that quietly loses money or noticing your edge only exists at certain times.

What data to pull from the API

A useful dashboard draws on a handful of API data sources. Market data — listMarketCatalogue and listMarketBook give you markets, runners, prices and matched volumes for the live-monitoring views. Your orders and bets — listCurrentOrders shows open and recently matched orders for the positions/exposure view, and listClearedOrders gives your settled bet history, which is the raw material for all your P&L analytics. Account data — getAccountFunds for your balance and exposure, and getAccountStatement for the money-in/money-out record. The key realisation is that listClearedOrders is your goldmine: every settled bet with its market, selection, odds, stake and profit is there, and that's what lets a dashboard tell you the truths a spreadsheet of guesses can't.

The metrics that actually help

It's easy to drown a dashboard in numbers; the ones that change behaviour are fewer than you'd think. Cumulative P&L over time — the single most important chart, because it shows your real trajectory and whether recent results are normal variance or a genuine decline. P&L by market type or sport — this routinely surprises people, revealing that one category they enjoy is quietly losing while another carries them. Win rate and average win vs average loss — together these tell you whether you're a high-strike-rate small-edge trader or a low-strike-rate big-win one, which should shape your staking. Current exposure — live liability across open positions, so you never accidentally over-commit. Commission paid — easy to ignore, but on the Exchange it's a real and visible cost worth tracking against the commission structure. Build these five well before adding anything fancier.

Choosing a tech stack

You have a lot of freedom here, and the right choice is whatever you'll actually finish. The common, sensible pattern is a backend in Python or Node that talks to the Betfair API, stores the data, and serves it; and a front end that renders charts. For Python, libraries like Plotly Dash or Streamlit let you build an interactive dashboard with very little front-end code — ideal if you're not a web developer. For Node, a small Express backend plus a JavaScript charting library (Chart.js, Plotly, or similar) in a simple web page works cleanly and plays to JavaScript's strengths if you came through the Node guide. If you want it really simple, even a script that pulls listClearedOrders and writes an HTML file with embedded charts is a legitimate dashboard. Don't agonise over the stack; pick the one closest to what you already know and get a single real chart on screen before expanding.

Storing data: why you need history

The mistake that limits most home-built dashboards is not storing anything — pulling data fresh from the API each time and displaying it. That's fine for live views, but it's useless for history, because the API's cleared-orders window and the live market only show you a slice. To chart P&L over months, or to see how a market's liquidity built before the off, you need to persist data yourself: periodically pull listClearedOrders and append new settled bets to a local store, and (if you want market history) snapshot prices and volumes over time. A simple SQLite or even CSV store is plenty to start — you don't need a database server. Once you're saving history, your dashboard stops being a live readout and becomes an analytical tool that gets more valuable every week as the data accumulates. This single decision — persist your own history — is what separates a toy from something you'll still use in a year.

Charts that earn their place

Match the chart to the question. A cumulative P&L line over time answers “am I actually winning, and is now normal?” A bar chart of P&L by market type or sport answers “where does my money come from and leak to?” A histogram of individual trade results shows the shape of your edge — lots of small wins and occasional big losses, or vice versa. A live table of open positions with current exposure answers “what am I on the hook for right now?” And a simple equity curve with a drawdown shaded underneath makes risk viscerally clear in a way a number never does. Resist the temptation to add charts because you can; every view should answer a question you'd otherwise guess at. A cluttered dashboard you ignore is worse than three charts you check daily.

A sensible build order

Build it in stages so you have something useful early. Stage one: get a script pulling listClearedOrders and printing your total P&L — prove the data flow works. Stage two: persist that history to SQLite or CSV so you stop losing it. Stage three: add the one chart that matters most — cumulative P&L over time — in whatever charting tool your stack offers. Stage four: add P&L by sport/market and the commission total, the two views most likely to change your behaviour. Stage five, optional: add live views — open positions and current exposure — pulling listCurrentOrders and getAccountFunds on a refresh. Only after all that should you consider live market-price monitoring or anything real-time, which is more complex and arguably the job of your trading software anyway. Each stage is independently useful, so you're never far from something that helps.

Dashboard mistakes to avoid

Three traps recur. Not persisting history — the limiting mistake, covered above; without your own stored data the dashboard can't show trends. Vanity metrics — charts that look impressive but don't answer a real question; if a view never changes a decision, cut it. Building live before historical — real-time price feeds are seductive and complex, but the analytical views (P&L by category, commission, equity curve) deliver far more value for far less effort, so build those first. A fourth, quieter mistake: building it and not looking at it — a dashboard only helps if checking it becomes a habit, ideally a short weekly review. Keep it simple enough that the weekly look takes two minutes, and you'll actually do it.

Live versus static dashboards

It's worth being clear about two different things people mean by “dashboard,” because they need different effort. A static analytical dashboard refreshes periodically — say, nightly — from your stored cleared-orders history, and answers questions about your performance. It's cheap to build, low-risk, and delivers most of the value, because the questions that matter (is my edge real, where do I make and lose money, what's commission costing me) are all historical. A live dashboard polls the API continuously to show current prices, open positions and exposure in real time, and is more like an extension of your trading screen. It's genuinely useful for seeing exposure at a glance, but it's more complex, hits rate limits if you're careless, and overlaps with what your trading software already does. My advice for almost everyone: build the static analytical version first and live with it for a month before deciding whether you actually need real-time views. The static version is where the behaviour-changing insights live, and it's a fraction of the work. Adding live monitoring is a reasonable later upgrade, not a starting point — and if you do go real-time, feed it from the Stream API rather than hammering the polling endpoints.

Wiring the dashboard into a review routine

A dashboard that nobody opens is just a coding exercise, so the final — and most important — piece is the habit around it. The traders who improve treat their dashboard as the centrepiece of a short, regular review: once a week, open it, look at the cumulative P&L line and ask whether the recent slope is normal or a warning, check the P&L-by-category chart for any market type that's quietly leaking, and glance at commission as a share of your gross. Five minutes, honestly done, will catch problems weeks before a vague gut feeling would. Tie it to a written trading journal if you keep one, so the numbers from the dashboard sit alongside your notes on why you traded what you did — the combination of hard data and recorded reasoning is far more powerful than either alone. The goal is a feedback loop: trade, record, review, adjust. The dashboard supplies the “review” with objective data instead of self-serving memory, which is precisely the part of the loop traders are worst at doing honestly on their own. If you only ever build one thing on the Betfair API, make it this, and make the weekly review non-negotiable. Build the tool, then build the ten-minute weekly ritual that makes it matter.

The verdict

A dashboard is the highest-value, lowest-risk project you can build on the Betfair API, because it makes your own performance visible without ever placing a bet. Pull your cleared-orders history, persist it, and chart the few things that change behaviour — cumulative P&L, P&L by category, win/loss shape, exposure, and commission. Pick the simplest stack you'll finish, build in useful stages, and turn checking it into a short weekly habit. For most traders the payoff isn't a clever new edge; it's the uncomfortable clarity of seeing which activities make money and which quietly lose it. Build the data skills first via the API pillar, the Python tutorial or Node guide, feed it real-time data with the Stream API, and deepen the analysis with Betfair data analysis.

FAQ

Related reading

Build the API skills in the developers' pillar, the Python tutorial, and the Node.js guide. Add real-time data with the Stream API, deepen the analytics with Betfair data analysis and Python data analysis, and keep an eye on costs via the commission guide. To turn insight into automation later, see building Betfair bots.