DOS FORMAS DE RECIBIR CAÍDAS

¿Stream SSE o endpoint REST de caídas?

La API de cuotas de Pinnacle informa de las caídas de precio de dos formas: enviadas por el stream SSE a medida que se detectan, o extraídas del endpoint REST de caídas cuando lo pides. Las dos llevan nombres de campo distintos, se adaptan a código distinto y vienen con planes distintos. Usa el stream para reaccionar y el endpoint para mirar atrás.

Las mismas caídas, dos formas

Una alerta SSE describe el movimiento con from_price y to_price, nombra el mercado en sect y el lado en outcome, y lleva el deporte tanto como sport como sport_id. Tiene un id, una marca de tiempo alerted y el precio justo en nvp. El porcentaje lo calculas tú.

El endpoint REST, GET /api/drops, devuelve los mismos movimientos como objetos con from, to, market, side y sport_name, y añade drop_pct, age_s e is_live. El código que lee una forma como si fuera la otra pierde los números en silencio, así que merece la pena escribir la correspondencia una vez:

SSE alert        REST drop
from_price   ->  from
to_price     ->  to
sect         ->  market
outcome      ->  side
sport        ->  sport_name
nvp          ->  nvp
(computed)   ->  drop_pct

Cuándo el stream es la herramienta adecuada

Todo lo que reacciona pertenece al stream: un relay hacia un canal de chat, un bot que vuelve a cotizar sus propios precios, un monitor que despierta un modelo cuando una línea se mueve. Una conexión abierta sustituye a un bucle de sondeo, la alerta llega a medida que el motor la detecta, y no se gasta presupuesto de solicitudes esperando. En vivo y prepartido tienen streams propios, así que un proceso que necesita ambos mantiene dos conexiones.

El stream viene con el plan de alertas SSE y con los dos planes combinados. No tiene filtro de deporte propio; filtra por sport a medida que llegan las alertas.

Cuándo el endpoint es la herramienta adecuada

Todo lo que mira atrás pertenece al endpoint: un panel de dashboard que lista los últimos cinco minutos de movimientos, un trabajo programado que corre al principio de cada hora, una comprobación al arrancar para ver qué pasó mientras un relay estaba caído. La consulta selecciona la fase con mode=live o mode=prematch, el tamaño con min_drop_pct, la ventana con max_age_sec y el número con limit. Cada llamada es una solicitud REST y consume la asignación REST del plan como cualquier otra.

Como el endpoint responde con una ventana reciente y acotada, no es un archivo. Un movimiento más antiguo que la ventana desaparece de él, y nada en la API lo reproduce. El panel en vivo de la página de inicio de pnclFEED dibuja exactamente esta llamada, así que puedes ver los nombres de campo del propio endpoint antes de escribir una línea.

Usar los dos juntos

Los dos se combinan bien en un solo proceso. Al arrancar, llama al endpoint con max_age_sec=300 y trata el resultado como las alertas que te perdiste; luego abre el stream y pasa a las alertas enviadas desde ahí. Tras una reconexión, haz lo mismo otra vez. Deduplica entre las dos fuentes por la clave de selección y no por el id de la alerta, ya que las filas del endpoint no tienen ids del stream; la página de deduplicación define esa clave.

Preguntas frecuentes

Comparar los planes

Los nombres de los campos siguen la documentación publicada por el proveedor, revisada el 26 de septiembre de 2026. Publicado el 29 de septiembre de 2026.