Dois padrões de integração
| iFrame | API | |
|---|---|---|
| Front-end | Nosso, incorporado ao seu site | Seu |
| Carteira | Sua, via callbacks de seamless wallet (carteira integrada) | Sua, via callbacks de seamless wallet |
| Tempo até o lançamento | De dias a algumas semanas | Seis a doze semanas, dependendo do seu front-end |
| Controle sobre a UX | Apenas tematização | Total |
| Usuário típico | Cassino que acrescenta uma aba de sportsbook | Operador cujo sportsbook é o produto; provedores de plataforma |
Quanto cada padrão custa em tempo de engenharia
As seis a doze semanas acima são tempo corrido para um time de duas pessoas, alongado pelas partes que não rodam em paralelo: a autenticação antes de tudo, o catálogo antes do bilhete. A tabela traz o mesmo trabalho em dias-engenheiro, separado por frente de trabalho, para você ver quais partes o iFrame elimina. As faixas são a diferença entre um time que já entregou um front-end de apostas e um que nunca entregou.
| Frente de trabalho | iFrame | API |
|---|---|---|
| Callbacks de carteira e o livro-razão por trás deles | 5–10 dias | 5–10 dias |
| Autenticação, assinatura de requisições, chaves de idempotência | 2–4 dias | 2–4 dias |
| Catálogo: esportes, competições, partidas, mercados, seleções | Nosso | 10–20 dias |
| Atualizações de preço e status ao vivo pelo canal de push | Nosso | 5–10 dias |
| Bilhete de aposta, aceitação e a política de mudança de preço | Nosso | 10–15 dias |
| Tela de cash-out: cotação, parcial, expiração | Nosso | 4–8 dias |
| Liquidação, reliquidação e telas de histórico de apostas | Nosso | 4–8 dias |
| Limites, autoexclusão e regras da licença na sua interface | Apenas tematização | 3–6 dias |
| Rodada de certificação e as correções que ela gera | 3–5 dias | 5–10 dias |
Duas coisas saem dos totais. A carteira é o mesmo trabalho em qualquer dos dois padrões, e é a parte com maior chance de sair errada, então o iFrame não permite pular essa etapa. O que o iFrame elimina é o front-end de apostas: de 36 a 67 dias-engenheiro aqui. É esse o número a pesar contra ser dono da interface, não a diferença nas datas de lançamento.
O contrato de seamless wallet
Sua carteira guarda o saldo e nós guardamos a aposta. Nenhum dos lados consegue reconstruir o outro a partir dos próprios registros, e por isso toda chamada carrega um identificador de aposta e um identificador de transação. A tabela apresenta as quatro chamadas: quando enviamos cada uma, o que precisamos de volta e o que acontece quando nada volta.
| Chamada | Quando enviamos | O que precisamos de volta | Se der timeout |
|---|---|---|---|
| Saldo | No início da sessão e antes de uma aceitação em que seus limites possam ter mudado | Saldo disponível por moeda | A aposta não é aceita. Nenhum dinheiro se moveu, então nada precisa ser desfeito. |
| Reservar e debitar o valor apostado | Na aceitação, com a chave da requisição, o identificador da aposta e o valor apostado | Confirmação e o saldo resultante | Repetimos com a mesma chave, e sua carteira deve retornar o primeiro resultado em vez de debitar de novo. Se ficar sem resolução, a aposta não vale e a tentativa é registrada como não confirmada. |
| Creditar prêmios | Na liquidação de uma aposta ou perna vencedora e na execução do cash-out | Confirmação e o saldo resultante | Repetida com a mesma chave até ser confirmada. Um prêmio nunca é descartado: ele é aplicado ou reportado como pendente. |
| Anular e reliquidar | Em uma anulação, um evento cancelado ou uma correção oficial de resultado | Confirmação, com o delta aplicado | Mesma chave, mesma regra. Uma reliquidação que não pode ser aplicada fica retida e é reportada, nunca aplicada duas vezes. |
A chave da requisição é todo o contrato. Toda chamada carrega uma, e a regra do seu lado é que a mesma chave sempre produz a mesma resposta: a primeira resposta. Uma carteira que trata uma repetição como nova instrução vai debitar duas vezes na primeira vez que uma conexão cair, e conexões caem. É por isso que o sandbox envia uma duplicata de cada chamada, e por isso a chave de produção só sai quando as duplicatas voltam idênticas. O timeout e a janela de repetição são definidos no contrato, junto com os limites de taxa, porque dependem de onde sua carteira roda.
O que a API expõe
- Catálogo: esportes, competições, partidas, mercados e seleções com preços, status e estado de suspensão. Pré-jogo por REST com notificações de mudança; ao vivo por push (WebSocket) com deltas de preço e status, espelhando os feeds de origem, que no caso da Sportradar chegam por AMQP.
- Aceitação de apostas: simples, múltiplas, sistemas e pernas de bet builder (criador de apostas), com tratamento de mudança de preço (aceitar qualquer, aceitar se for maior, recusar), limites de valor apostado vindos do motor de risco e chaves de requisição idempotentes.
- Seamless wallet: chamamos sua carteira para reservar e debitar o valor apostado, creditar prêmios, anular e reliquidar; um saldo único para o jogador entre cassino e sportsbook.
- Cash-out: cotar e executar, total e parcial, ao vivo e pré-jogo.
- Liquidação: resultados e eventos de liquidação por aposta e por perna, com reliquidação em correção oficial e trilha de auditoria completa.
- Contexto de conta: limites do jogador, autoexclusão e restrições ditadas pela licença enviados em cada requisição, para que o motor de risco e as regras do regulador se apliquem aos seus jogadores como se aplicam aos nossos.
- Relatórios: volume apostado, GGR (receita bruta de jogo) e margem por esporte, mercado e coorte de jogadores; arquivos de reconciliação de liquidação.
Certificação: os cenários e o que deve acontecer
Estes são os casos que o sandbox roteiriza antes de uma chave de produção ser emitida. A coluna do meio é o comportamento contra o qual certificamos; a coluna da direita é o que faz, em vez disso, uma integração que não pensou no caso, e como a falha aparece na sua fila de suporte.
| Cenário | Comportamento esperado | O que faz uma integração não testada |
|---|---|---|
| O preço muda entre o bilhete e a aceitação | Aceitar, aceitar se for maior ou recusar, conforme a política enviada com a requisição. A aposta vale a um único preço. | Aceita pelo preço desatualizado e depois discute qual preço foi exibido. |
| O mercado é suspenso enquanto a requisição está em trânsito | Recusada com um motivo de suspensão. Nada é debitado. | Debita o valor apostado e depois anula, deixando um débito e um crédito para uma aposta que nunca existiu. |
| Uma aceitação duplicada chega com a mesma chave de requisição | Uma aposta, um débito, a resposta original devolvida de novo. | Duas apostas e dois débitos. |
| A carteira não responde ao débito | A aposta não vale; a tentativa é registrada como não confirmada. | Aceita a aposta contra um débito não confirmado e descobre a diferença na liquidação. |
| Cash-out parcial em uma múltipla com uma perna já liquidada | Cotado sobre as pernas ainda abertas; a perna liquidada não é reprecificada. | Precifica a aposta inteira e depois não consegue liquidar o que sobrou dela. |
| Um resultado oficial é corrigido depois do pagamento | Reliquidação aplicada como delta, mantendo tanto o original quanto a correção. | Sobrescreve a liquidação original, então o histórico deixa de explicar o saldo. |
| O jogador ultrapassa um limite de depósito ou de perda no meio da sessão | Aceitação recusada pelo limite, com o limite nomeado na resposta. | Aceita a aposta, porque o limite vive no seu sistema de contas e nunca foi enviado com a requisição. |
| O feed de origem cai com apostas em aberto | Os mercados são suspensos, a aceitação para nas partidas afetadas, as apostas em aberto continuam abertas e liquidam quando os resultados chegam. | Continua aceitando preços que pararam de se mover. |
Os feeds por trás dela
A API é agnóstica de feed. Por trás dela rodamos Sportradar, Genius Sports, LSports ou OddsMatrix, conforme seu contrato e seus mercados; no turnkey (chave na mão) o contrato de feed é seu e nós o integramos.
| Feed | Cobertura publicada |
|---|---|
| Sportradar | 900,000+ eventos por ano, 32 esportes |
| Genius Sports | 600,000+ partidas, 40+ esportes |
| LSports | 175,000+ eventos pré-jogo por mês, 100+ esportes, 2,500 mercados |
| OddsMatrix | 200,000+ eventos ao vivo por mês |
Mais sobre cada feed, inclusive qual recomendamos para cada tipo de sportsbook, na página sportsbook turnkey.
O que uma licença apenas de dados de odds não inclui
Vários provedores vendem odds como dados, e alguns dizem com clareza nas próprias páginas que são infraestrutura de odds, não um sportsbook. A tabela lista o que fica entre um preço e uma aposta liquidada, e de onde vem cada parte em cada um dos dois modelos.
| O que é necessário | Licença de dados de odds | Esta API |
|---|---|---|
| Preços, partidas e status de mercado | Incluído | Incluído |
| Aceitação de apostas | Você constrói | Incluída |
| Limites de risco e exposição por jogador, mercado e evento | Você constrói | Os limites de valor apostado vêm do motor de risco junto com a requisição |
| O contrato de carteira | Você constrói | Quatro chamadas, idempotentes, certificadas antes do go-live |
| Precificação do cash-out | Você constrói | Cotar e executar, total e parcial |
| Liquidação de apostas e pernas | Você constrói | Incluída, por aposta e por perna |
| Reliquidação em correção oficial | Você constrói | Incluída, com a trilha de auditoria |
| Limites do jogador e autoexclusão aplicados na aceitação | Você constrói | O contexto de conta viaja com cada requisição |
| Arquivos de reconciliação e relatórios ao regulador | Você constrói | Incluídos |
Uma licença de odds é a compra certa para um site de mídia, um produto de palpites ou um modelo, nenhum dos quais recebe dinheiro de um jogador. É a compra errada para um operador, e é a linha mais barata da proposta, e é assim que o erro é cometido.
Sandbox e go-live
Sandbox com replays gravados de mercados ao vivo, para que seu front-end possa ser testado contra movimento real de preço, e não contra dados de teste estáticos. O checklist de certificação citado na abertura roda contra esse sandbox antes de as chaves de produção serem emitidas, então os casos-limite são pegos antes do lançamento, e não na primeira semana de tráfego real. Limites de taxa e SLAs são definidos em contrato; nós os informamos quando soubermos a concorrência de pico esperada, porque uma API de checkout e um feed ao vivo de jogo em andamento têm tolerâncias diferentes.
Perguntas frequentes
Podemos pegar só as odds e rodar nossa própria aceitação de apostas?
Isso é uma licença de dados, não uma API de sportsbook — um feed apenas de odds, que vários dos nossos provedores de origem também vendem diretamente, sem aceitação de apostas, gestão de risco ou liquidação. A nossa é o oposto: aceitação, risco e liquidação são o produto, e as odds são aquilo contra o que as aplicamos.
Podemos começar pelo iFrame e migrar para a API depois?
Sim, e nessa ordem custa menos. O trabalho de carteira é aproveitado sem alteração, porque os dois padrões usam as mesmas quatro chamadas. O que você constrói depois é o front-end de apostas: os 36 a 67 dias-engenheiro da tabela acima. A conta, os jogadores e o histórico de apostas ficam onde estão; só muda a interface na frente deles.
Quem define os limites, nós ou vocês?
Os dois, mas em um só sentido. O motor de risco devolve limites de valor apostado por mercado, seleção e jogador junto com o catálogo, e você pode reduzi-los. Você não pode elevá-los acima dos limites de exposição do sportsbook, porque a responsabilidade fica com quem precificou o mercado. Suas próprias regras — limites de depósito e de perda, autoexclusão, restrições da licença — viajam com cada requisição e são aplicadas na aceitação, não verificadas depois.
Vocês suportam fantasy ou apostas em pool?
Apostas em pool sim, no mesmo catálogo. Fantasy não.
E contratos no estilo de mercados de previsão?
Produto diferente, licença diferente na maioria dos lugares; veja a plataforma de mercados de previsão.