Betfair Tennis Trading Bots: Live Scores, API Cost & Licences

Disclosure: Live Tennis API provided BotBlog with free Ultra access to evaluate the feed. Links to Live Tennis API in this article are affiliate links — we may earn a commission if you subscribe, at no extra cost to you. Use our link or enter code botblog at checkout for 10% off. Editorial verdict stays independent. Full disclosure.

Why this guide (and a personal note)

I’m Stephane — I run BotBlog, I’m a keen tennis player, and I’m a proper fan of the tour. That mix matters here. On court you feel how a single break point changes the match; on the exchange you see the same moment as a Match Odds spike. Betfair tennis trading only makes sense if you respect both: the sport’s score logic and the market’s liquidity.

This is not a tipster pitch. It is a real map of what you can build, what you should not, what licences and API costs look like in 2026 — and why I use a dedicated tennis WebSocket (Live Tennis API) instead of polling scrapers.

Related reads: beginner live tennis scores dashboard · BFBM tennis in-play · 15–40 tennis strategy · Betfair API key (Delayed vs Live) · bot certification · building a Betfair bot.

What you can do with live tennis data + an exchange

If you only do one project this month: get an Ultra key, subscribe the WebSocket to one live match, open Match Odds, and write a CSV of score_commit_time, point, best_back, best_lay. That file teaches more than any tipster channel.

What you cannot (or should not) do

Honest line from Live Tennis API’s founder (and we agree): if your test is “are we faster than bet365?”, you will be disappointed. If your test is “do score commits arrive before the exchange finishes repricing?”, you are asking the bot-builder question — and that is exactly why you subscribe to a push feed rather than poll.

Compliance, licences and who may use what

Keep personal projects and commercial products in different boxes.

Betfair — personal vs commercial

• Personal betting / DIY bot for your account — Developer Program → free Delayed key to learn → apply for Live App Key when you need real-time data and placeOrders. Details: Betfair API key guide.
• Selling software to other customers — Betfair vendor / certification path required. See bot certification.
• Age & jurisdiction — 18+ only; respect UKGC rules and Betfair API region limits.
• Data licence — exchange + third-party tennis data are for permitted use under each vendor’s terms — not for republishing tip boards.

Matchbook — personal API projects

I use Matchbook for market-side experiments (I do not currently hold a Betfair data subscription). Registered customers can start with the API; heavy usage may incur volume fees. Read their Fair Usage Policy and pricing.

Live Tennis API — the score layer you subscribe to

Live Tennis API is a separate data subscription. It does not replace Betfair/Matchbook terms. You still need a lawful exchange path to trade. For bots in this guide, plan on Ultra (WebSocket + win-probability).

Choose a plan & get your API key (10% off) →

Affiliate link — code botblog also gives 10% off at checkout. Disclosure. Cancel anytime on their site.

Betfair API cost (and where the tennis feed sits)

Confirm fees on official pages before you pay.

Official Betfair note (Jul 2026): Live App Key activation is listed at £499 one-off (Developer Program costs). Older posts may still say £299 — trust Betfair’s page on the day you apply.

Recommended build order

1. Betfair Delayed key and/or Matchbook — prove you can read tennis Match Odds.
2. Subscribe to Live Tennis API Ultra — stream score commits; log only at first.
3. Map break points / tie-breaks the way you would as a player (see 15–40).
4. Then either automate in BFBM or pay for Betfair Live and keep stakes tiny.

Where Live Tennis API fits (and why subscribe)

Live Tennis API is REST + WebSocket tennis data (ATP, WTA, Challenger, ITF) with live score state and, on Ultra, win-probability. Docs: API reference.

Think Futodds-for-tennis: live state in → your rules decide → exchange executes. Without a push feed, your “bot” is just a slow poller.

1) Event-driven scores vs polling

Polling every few seconds looks fine until a break converts. Ultra’s WebSocket sends a frame per score commit.

import json
import os
import websocket

KEY = os.environ["LIVETENNISAPI_KEY"]
URL = f"wss://api.livetennisapi.com/api/public/v1/ws?token={KEY}"

def on_open(ws):
    ws.send(json.dumps({"topics": ["live-scores"]}))  # or match:12345

def on_message(ws, message):
    msg = json.loads(message)
    if msg.get("type") == "score":
        s = msg["score"]
        print(msg["match_id"], s.get("sets"), s.get("games"), s.get("points"),
              "server", s.get("server"), "wp1", s.get("win_probability_p1"))

websocket.WebSocketApp(URL, on_open=on_open, on_message=on_message).run_forever()

Keep keys in .env — never in a public repo. Get a key when you subscribe.

2) Model probability vs market price

Ultra exposes win_probability_p1. Log the gap vs exchange implied probability — as a filter or journal, not a tip service.

def implied_prob(decimal_odds: float) -> float:
    return 1.0 / decimal_odds

# gap = model_p1 - implied_prob(best_back_p1)

Worked example — Live Tennis API × Matchbook (live snapshot)

On 21 Jul 2026 ~13:08 UTC I cross-checked both feeds from the same machine:

• Live Tennis API — GET /matches?status=live + per-match /score (Ultra win-probability)
• Matchbook Exchange API — open tennis events with prices (sport-id 9), authenticated operator session

Result: 44 live LT matches, 96 open Matchbook tennis events, 18 name-matched overlaps (fuzzy match on player names; event titles are often reversed).

Sample rows at that timestamp (P1 = Live Tennis API player 1; Matchbook backs aligned to that player):

How to read the gap: model − market. Near zero (Carle) means model and Matchbook agree. A large negative gap (Bueno −0.16) means the market implies a higher win chance for P1 than the model — worth logging, not auto-firing a tip. Halys shows a small positive gap while already a short price after winning the first set.

What this proves for bot builders:

• You can join score commits + win-probability to live Match Odds in one loop
• Name matching and runner orientation matter (Matchbook often lists B vs A when LT has A vs B)
• Not every live LT match has a liquid Matchbook market — 18/44 overlaps in this slate
• This is a journal / research pattern, not a signal product

Reproduce the idea: subscribe Ultra → stream scores → poll Matchbook moneyline backs → write CSV. I keep a local helper script for regenerating snapshots when updating this guide.

How often does each feed refresh? (methodology)

A single snapshot table is useful, but it is not a full latency study. Odds and scores move on different clocks. Here is how to compare them properly — and what we measured on the same slate.

Matchbook fair-usage caps (per account, from their API Fair Usage Policy): Events group 700 requests/minute, Account 300/min, Security 200/min. Exceeding limits can trigger a ~10 minute block. So “poll every market every 100ms” is not a plan — watch a shortlist of in-play Match Odds only.

Live Tennis rate limits (plan-dependent on their site): Basic ~60 req/min, Pro ~300, Ultra ~600 — plus the WebSocket so you are not burning REST quota on every point.

Timed probe (same match, both APIs)

Immediately after the snapshot above, I polled Sergey Fomin vs Yanki Erel for 45 seconds at 1 Hz (Live Tennis REST score + Matchbook event prices for the matched event id):

What that means in plain English:

• Matchbook odds tick more often than the score. The ladder moves on orders even when the point score is unchanged — so a “gap” can open or close without a new tennis point.
• Score commits are rarer but decisive. In this window we saw a game finish (30-40 → 0-0); Matchbook’s first-runner best back then stepped 1.50 → 1.41 within ~1–2 seconds on our 1 Hz poll (so the true exchange move could be faster than 1s — our sample interval is the floor).
• REST latency ≈ 80–110 ms for both APIs on this path is small vs a full second of poll lag. The design choice that matters is push scores (WebSocket) + disciplined Matchbook polling, not shaving 20 ms off HTTPS.
• This probe used REST for tennis scores so both feeds were on the same timer. In production, switch LT to WebSocket and timestamp each Matchbook poll against the last score-commit time.

# Proper compare loop (sketch)
# 1) WebSocket: on score frame → store (t_score, point, wp1)
# 2) Every 0.5–1.0s: GET Matchbook moneyline for that event → (t_odds, back, lay)
# 3) Log rows where t_odds >= t_score; measure delay = t_odds - t_score after breaks
# Do not treat a random mid-game gap as a signal without the score context.

Limits of this test: one match, 45 seconds, 1 Hz polls, first runner’s top of book only, no commission adjustment. Treat it as a method demo — re-run on ATP/WTA main-draw matches you actually trade before you trust any edge story.

3) Trigger states that move prices

• Break points — same moments as the 15–40 framework
• Tie-breaks (is_tiebreak) — pause or cut size
• Deciding sets — re-check green-up / stop-loss

Prefer ATP/WTA; liquid Challenger only when fillable. Skip ITF for v1 automation.

Practical stack choices

Verdict — subscribe if you are building event-driven tennis bots

Betfair tennis trading bots are buildable if you respect score states, licences and liquidity. The missing piece for most DIY traders is not another odds poll — it is a point-by-point push feed.

That is why I point readers to Live Tennis API: WebSocket score commits, Ultra win-probability, clean JSON, and ATP/WTA/Challenger coverage. It will not outrun bet365’s board and it will not replace Betfair’s Live key — but used properly it is the tennis equivalent of the live-stats layer football bots already take for granted.

Subscribe to Live Tennis API (10% off) →

Affiliate link — use code botblog at checkout for 10% off. Disclosure

Keep building with BFBM tennis and the API key guide.