CONFIGURAÇÃO SSE
Conecte-se ao stream SSE de quedas da API da Pinnacle.
Uma requisição HTTPS à API de odds da Pinnacle que nunca termina. O servidor escreve eventos de queda nela conforme os preços da Pinnacle caem, e seu cliente lê, filtra e reconecta. Esta página cobre a conexão, o formato dos frames e onde o estado das suas regras deve ficar.
Abrindo o stream da API da Pinnacle
O stream é HTTPS puro. Envie um GET para /odds-drop para mercados ao vivo ou /odds-drop-prematch para os pré-jogo, com sua chave no header x-portal-apikey ou como ?key=. Defina min_drop você mesmo em vez de confiar no padrão: o exemplo documentado usa 5, e ele vai até 1. Uma resposta 200 com content type text/event-stream significa que a conexão agora fica aberta e os alertas chegam conforme as quedas são detectadas.
GET /odds-drop?min_drop=5 HTTP/1.1
Host: <api host from the docs>
Accept: text/event-stream
x-portal-apikey: <your key>Qualquer cliente HTTP que leia uma resposta de forma incremental funciona: curl para um teste rápido, a biblioteca HTTP da sua linguagem em produção. O EventSource do navegador consegue conectar com ?key=, mas isso coloca a chave em uma URL que qualquer visitante pode ler, então rode o leitor no servidor. Cada conta tem uma conexão por stream: uma segunda conexão ao vivo com a mesma chave fecha a primeira, enquanto uma conexão ao vivo e uma pré-jogo podem rodar lado a lado. No stream pré-jogo, recheck=N segura cada queda por N segundos e só a envia se o preço não tiver voltado.
Formato do evento
Cada mensagem é uma linha data:. A primeira é um objeto de controle; depois dela, cada lote de alertas é um array JSON. Este é o exemplo documentado, resumido:
data: {"type": "connected", "id": "d648beb8-..."}
data: [{"home": "Sunshine Coast Phoenix", "away": "Cairns Dolphins", "league": "Australia - NBL1 Women", "sport": "Basketball", "sect": "Moneyline", "outcome": "Home", "period": 4, "from_price": 2.86, "to_price": 2.7, "nvp": 3.04, "id": 1629729400, "alerted": 1777625196, ...}]Faça o parsing de cada linha data: como JSON. Um objeto é uma mensagem de controle: connected quando o stream abre, ou um erro como plan_lacks_sse quando o plano da chave não tem stream. Um array é um lote de alertas. Cada alerta identifica a linha com sport, league, sect, outcome e period, carrega o preço antes e depois como from_price e to_price, adiciona nvp, o preço justo sem margem após o movimento, e registra o horário do alerta em segundos Unix como alerted. A porcentagem é você quem calcula: (2.86 − 2.70) ÷ 2.86 = 5,6%.
Reconexões e períodos de silêncio
Conexões morrem: proxies expiram por inatividade, redes oscilam, deploys acontecem. Reconecte com uma pausa que cresce a cada falha. Um cliente que reconecta em loop apertado recebe um único frame de erro rate_limited com um header Retry-After: 60, então respeite-o em vez de martelar o endpoint.
Alertas perdidos não são reenviados: a documentação não promete ponto de retomada, então trate tudo que caiu durante a lacuna como perdido. Quando uma lacuna importar, preencha-a a partir do endpoint REST de quedas, que guarda quedas recentes por até cerca de três horas, com um timestamp em cada uma.
Períodos de silêncio são normais, especialmente no pré-jogo. Para distinguir um mercado parado de um feed quebrado, consulte o endpoint de health junto com o stream: ele informa há quanto tempo o feed ao vivo escreveu pela última vez. Se essa idade continuar crescendo enquanto sua conexão não diz nada, feche-a e reconecte.
Mantendo o estado da regra no servidor
Limites, conjuntos de alertas já vistos e janelas de deduplicação pertencem ao servidor, não a uma aba de navegador que pode dormir ou fechar. O processo leitor é dono da conexão; o que avalia suas regras deve ficar ao lado dele.
Torne o processamento idempotente. Monte a chave de deduplicação com id, sect, outcome, period e alerted em vez de um único campo, e descarte duplicatas antes de a regra rodar. Persista o horário do último alerta processado junto com o estado da regra, e um reinício retoma de forma limpa em vez de alertar de novo sobre movimentos que você já tratou.
Quando frames brutos superam o SSE
O SSE é o padrão certo para alertas: o stream detecta as quedas, e seu cliente só trata eventos que já cruzaram uma linha. Escolha WebSocket bruto quando sua aplicação precisar de cada frame, porque você reconstrói o estado completo do mercado por conta própria em vez de consumir eventos de queda prontos. Isso cobre acompanhar mercados que não se moveram o bastante para alertar, ou aplicar uma lógica de detecção que o stream de quedas nunca foi feito para rodar. O complemento de WebSocket bruto custa US$ 99 a cada 30 dias nos planos REST e combinados. Se a sua regra só reage a quedas, fique no SSE; tudo nesta página continua valendo.
Teste sua regra primeiro
Antes de manter uma conexão aberta, confira a regra no papel. O guia de alertas de queda cobre a fórmula percentual e como limites, janelas e filtros se combinam. As opções de acesso por streaming estão listadas em planos.
Quando a regra se sustentar no papel, conecte o stream e deixe-o rodar.
Se preferir partir de código que já funciona, o quickstart de Python no pnclFEED tem um listener SSE que lê este stream como ele é.