Get started
The Bet Placement API provides betting functionality for the S2S platform, enabling you to place bets.
Core Betting Operations¶
Place Bets¶
Primary endpoint for placing single and multiple bets:
- Place bet (v2) - Place bet for processing with configurable delay options via
betPlacementOptions
Obsolete Endpoints¶
Obsolete
The following endpoints are obsolete and will be removed in a future release. Migrate to POST /v1/sport/v2/bet.
- ~~Place bet~~ - (obsolete — use v2 without
betPlacementOptions) - ~~Place bet (without line delays)~~ - (obsolete — use v2 with
betPlacementOptions.ignoreLineDelay: true)
Betting Limits & Validation¶
- Get max bet amount - Get max bet amount
Migration Guide¶
From POST /v1/sport/v1/bet (common clients)¶
Change the URL to /v1/sport/v2/bet. No request body changes needed — the default behavior is identical.
From POST /v1/sport/mts/v1/bet (MTS clients)¶
The MTS endpoint applied only player/segment delay (line delay was ignored). To replicate this behavior:
- Change the endpoint URL to
/v1/sport/v2/bet - Add
betPlacementOptionsto the request body:
The rest of the request body remains unchanged.
betPlacementOptions Reference¶
Optional object in the request body of POST /v1/sport/v2/bet that provides client-controlled placement options. All fields are optional. If the entire object is omitted, default behavior applies (same as the old POST /v1/sport/v1/bet).
Client responsibility
The client is fully responsible for the values provided in betPlacementOptions. Disabling delays or supplying incorrect createTime may result in accepting bets with stale odds. Use these options only when your platform manages its own risk controls.
Schema¶
| Field | Type | Default | Description |
|---|---|---|---|
ignoreLineDelay | boolean | false | When true, the event/line delay (configured by trading per-event) is subtracted from the applied delay. Other validations (player limits, recovery delay) still apply. |
disableRecoveryDelay | boolean | false | When true, recovery delay (consecutive-bet delay) is set to zero and the player does not leave a delay footprint for subsequent bets. |
createTime | string (DateTime, nullable) | null (server uses UTC now) | Client-supplied bet creation time in UTC ISO 8601 format (e.g. "2026-06-17T14:30:00.123Z"). Used to calculate how much delay has already elapsed: alreadyDelayed = ServerUtcNow − createTime. |
Behavior details¶
ignoreLineDelay¶
- The line/event delay is a per-event value set by the trading team (typically 3–8 seconds for Live events).
- When
ignoreLineDelay: true, this per-event delay is subtracted from the total required delay. If the remaining delay is ≤0, no delay is applied. - Player-segment delay and recovery delay are not affected by this flag.
- Use case: S2S clients that already apply their own line delay on their side before sending the bet request.
disableRecoveryDelay¶
- Recovery delay is an additional delay applied when the player has recently placed a bet (consecutive-bet protection).
- When
disableRecoveryDelay: true, the required delay is set to zero and the player does not enter the "recently bet" cache. This means subsequent bets from the same player also won't be penalized by this bet. - Use case: S2S clients that manage their own consecutive-bet throttling.
createTime¶
- When provided, the server calculates
alreadyDelayed = UtcNow − createTimeand subtracts it from the required delay. This accounts for network latency between the client and the server. - When omitted, the server uses its own
DateTime.UtcNowat the moment of processing. - Format: ISO 8601 with UTC timezone, e.g.
"2026-06-17T14:30:00.123Z". - Use case: Clients with significant network latency to the platform who want to ensure the delay calculation reflects the actual time the player clicked "place bet".
Example request with all options¶
{
"items": [
{
"eventId": "13312064",
"odds": 1.64,
"sourceOutcomes": [
{
"selection": "[2,[],[0],1,3,[]]",
"odds": 1.64,
"dataVersion": 31
}
]
}
],
"amount": 20,
"betType": "Ordinar",
"oddsChangePolicy": "None",
"marketChangePolicy": "None",
"systemSize": 0,
"isOverask": false,
"transactionId": "918de8e1-d637-4413-8a80-9d103a7ca351",
"useExternalBetId": false,
"betPlacementOptions": {
"ignoreLineDelay": true,
"disableRecoveryDelay": true,
"createTime": "2026-06-17T14:30:00.123Z"
}
}
Integration Resources¶
Best Practices¶
Bet Placement¶
- Always validate bet amounts using the max bet amount endpoint before placing bets
- Handle error responses appropriately for failed bet placements
- Use
betPlacementOptionsonly when your platform manages its own risk controls
Error Handling¶
- Implement proper retry logic for network failures
- Use transactionId when making a place bet request to prevent duplicate requests from the client
- Check bet status after placement to ensure successful processing
- Handle insufficient balance and betting limit errors gracefully
Performance¶
- Use batch operations when placing multiple bets