Betting Bots and APIs: Automation Without Getting Locked Out

What the rule actually splits

Automation is one line among several inside the wider set of professional betting methods covered on this site, and it gets its own page because the rules here are more specific than "sharp bettors use software". Forum shorthand treats "bot" as one thing: software placing bets. Betfair's terms are more precise. Clause 12.1.4 lists, among the activities it treats as suspicious, a bet placed "otherwise than through the Account holder placing each Bet manually", which read alone would catch every script ever written. It is not read alone: the same clause carries its own exception, stated for the avoidance of doubt, that bets placed "via the Application Programming Interface (API)" are not included. Put the two fragments together and the split is exact: a script clicking through the ordinary website is what the clause is aimed at, and a script talking to the API is the exception the clause names to itself.

Side note: "bot" is doing a lot of work in that sentence, and the word never actually appears in the clause. Betfair's lawyers wrote "otherwise than through the Account holder placing each Bet manually" instead, which is a longer way of saying the same thing but a much harder sentence to misquote. Anyway, back to what it means for you.

So the rule is not "bots are banned" and not "bots are fine". It is narrower: an unofficial script working the website like a very fast pair of hands sits inside a clause about suspicious activity, while the same logic wired to the official API sits inside the exception. Somebody trading the ladder by hand and a script doing the same thing through the API are treated differently by the same document, and the difference is the door, not the strategy behind it.

What to test before a Live key gets funded

Everyone who builds a bot wants to skip to placing bets. The honest order runs the other way: prove the logic against data deliberately slower than real time, at the smallest stake the venue allows, before a paid key or a serious bankroll is anywhere near it.

That range, one second at best and up to three minutes at worst, is not a rounding error to shrug off. A price a script last saw as reasonable can have moved well past it by the time the script acts, and there is no sandbox to soften that: Betfair's own documentation states there is no test bed that lets anyone test without using real funds. Every bet a Delayed key places is a live bet with a real result, which is why the smallest stake the venue allows is the only sane way to run this stage.

A hypothetical, with every figure invented for the arithmetic only. Say a script watches a price sitting at 2.10, decides to back it, and the API hands back a snapshot 180 seconds old at that exact moment. A goal, a red card or a late scratch can happen in three minutes, so the price the script thinks it is backing and the price actually on offer when the order lands can be two different numbers. No clever logic upstream fixes a decision built on stale information; the lag itself, not the strategy on top of it, is the first thing worth testing.

The venue is only half the picture; the other half is the feed a bot actually reacts to, and a script built on thin history will misfire whatever key it runs on. Check the arithmetic by hand on a calculator before trusting a script's own numbers, and remember that exchange commission still comes off any winning bet; what it does to a bot's net numbers is worth reading before a strategy is judged a success on paper.

The limits a script needs to be designed around

None of this is about whether automation is allowed. It is about the ceiling the API itself puts on how a script behaves, set out in plain numbers rather than left to guesswork. Four of them matter most when a script is still on the drawing board, and, together with the delayed key's own lag window above, they are figures Betfair can revise; check the current terms before designing production code around any of them.

• A 200-point cap on market data requests. The cost is added up across the markets and the type of data asked for; going over the total returns an error rather than the data.
• A 3-concurrent-request ceiling on order and position calls. Checking current orders, profit and loss, or cleared orders more than three times at once, while earlier calls are still running, is refused rather than queued.
• A 1,000-instruction-per-second ceiling on placing, cancelling, updating or replacing orders. That covers the whole account across every open connection, not one script in isolation.
• A 20-minute lockout after too many failed logins. Every further login attempt is automatically refused for that period, whatever caused the earlier failures.

A second hypothetical, and the one that actually catches people. A script whose login handling has a bug fails to refresh its session in time and retries in a tight loop instead of backing off. Twenty minutes is roughly a football half; trip the lockout at kick off and the script misses more of the match than it ever caught. The fix is duller than the story: hold the session, and treat a failed login as a reason to stop, not to retry immediately.