DUAS FORMAS DE RECEBER QUEDAS
Stream SSE ou endpoint REST de quedas?
A API de odds da Pinnacle reporta quedas de preço de duas formas: enviadas pelo stream SSE conforme são detectadas, ou puxadas do endpoint REST de quedas quando você pede. As duas carregam nomes de campo diferentes, servem a códigos diferentes e vêm com planos diferentes. Use o stream para reagir e o endpoint para olhar para trás.
As mesmas quedas, dois formatos
Um alerta SSE descreve o movimento com from_price e to_price, nomeia o mercado em sect e o lado em outcome, e carrega o esporte tanto como sport quanto como sport_id. Ele tem um id, um timestamp alerted e o preço justo em nvp. A porcentagem é você quem calcula.
O endpoint REST, GET /api/drops, devolve os mesmos movimentos como objetos com from, to, market, side e sport_name, e acrescenta drop_pct, age_s e is_live. Código que lê um formato como se fosse o outro perde os números em silêncio, então vale a pena escrever o mapeamento uma vez:
SSE alert REST drop
from_price -> from
to_price -> to
sect -> market
outcome -> side
sport -> sport_name
nvp -> nvp
(computed) -> drop_pctQuando o stream é a ferramenta certa
Tudo que reage pertence ao stream: um relay para um canal de chat, um bot que reprecifica as próprias cotações, um monitor que acorda um modelo quando uma linha se move. Uma conexão aberta substitui um loop de polling, o alerta chega conforme o motor o detecta, e nenhum orçamento de requisições é gasto esperando. Ao vivo e pré-jogo têm streams próprios, então um processo que precisa dos dois mantém duas conexões.
O stream vem com o plano de alertas SSE e com os dois planos combinados. Ele não tem filtro de esporte próprio; filtre por sport conforme os alertas chegam.
Quando o endpoint é a ferramenta certa
Tudo que olha para trás pertence ao endpoint: um painel de dashboard que lista os últimos cinco minutos de movimentos, um job agendado que roda no início de cada hora, uma verificação na inicialização para ver o que aconteceu enquanto um relay estava fora. A query seleciona a fase com mode=live ou mode=prematch, o tamanho com min_drop_pct, a janela com max_age_sec e a contagem com limit. Cada chamada é uma requisição REST e consome a cota REST do plano como qualquer outra.
Como o endpoint responde com uma janela recente e limitada, ele não é um arquivo. Um movimento mais antigo que a janela some dele, e nada na API o reproduz de novo. O painel ao vivo da página inicial do pnclFEED desenha exatamente essa chamada, então você pode ver os nomes de campo do próprio endpoint antes de escrever uma linha.
Usando os dois juntos
Os dois combinam bem em um único processo. Na inicialização, chame o endpoint com max_age_sec=300 e trate o resultado como os alertas que você perdeu; depois abra o stream e passe a usar os alertas enviados a partir dali. Depois de uma reconexão, faça o mesmo de novo. Deduplique entre as duas fontes pela chave de seleção e não pelo id do alerta, já que as linhas do endpoint não têm ids do stream; a página de deduplicação define essa chave.
Perguntas comuns
O stream e o endpoint reportam os mesmos movimentos?
Eles vêm da mesma detecção, então um movimento que alerta no stream aparece na janela do endpoint desde que esteja dentro da idade pedida e acima da porcentagem pedida. O endpoint é limitado, então um movimento antigo sai dele.
Posso consultar o endpoint em vez de manter um stream aberto?
Pode, ao custo de requisições REST e latência. Consultar a cada dez segundos são 8.640 requisições por dia, o que exige um plano REST pago, e um movimento ainda espera até dez segundos. O stream não custa requisições e entrega na detecção.
Qual deles carrega o preço justo?
Os dois. O campo é nvp em ambos, o preço no-vig da seleção alertada depois de remover a margem. Ele pode ser nulo, então trate-o como desconhecido e não como zero.
Os nomes dos campos seguem a documentação publicada pelo fornecedor, conferida em 26 de setembro de 2026. Publicado em .