CONFIGURACIÓN SSE
Conéctate al stream SSE de caídas de la API de Pinnacle.
Una solicitud HTTPS a la API de cuotas de Pinnacle que nunca termina. El servidor escribe en ella eventos de caída a medida que los precios de Pinnacle bajan, y tu cliente lee, filtra y reconecta. Esta página cubre la conexión, el formato de los frames y dónde debe vivir el estado de tus reglas.
Abrir el stream de la API de Pinnacle
El stream es HTTPS sin más. Envía un GET a /odds-drop para los mercados en vivo o a /odds-drop-prematch para los prepartido, con tu clave en la cabecera x-portal-apikey o como ?key=. Fija min_drop tú mismo en lugar de confiar en el valor por defecto: el ejemplo documentado usa 5, y baja hasta 1. Una respuesta 200 con content type text/event-stream significa que la conexión queda abierta y las alertas llegan a medida que se detectan las caídas.
GET /odds-drop?min_drop=5 HTTP/1.1
Host: <api host from the docs>
Accept: text/event-stream
x-portal-apikey: <your key>Cualquier cliente HTTP que lea una respuesta de forma incremental funciona: curl para una prueba rápida, la librería HTTP de tu lenguaje en producción. El EventSource del navegador puede conectarse con ?key=, pero eso pone la clave en una URL que cualquier visitante puede leer, así que ejecuta el lector en el servidor. Cada cuenta tiene una conexión por stream: una segunda conexión en vivo con la misma clave cierra la primera, mientras que una conexión en vivo y otra prepartido pueden funcionar en paralelo. En el stream prepartido, recheck=N retiene cada caída N segundos y solo la envía si el precio no ha rebotado.
Forma del evento
Cada mensaje es una línea data:. La primera es un objeto de control; después, cada lote de alertas es un array JSON. Este es el ejemplo documentado, recortado:
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, ...}]Parsea cada línea data: como JSON. Un objeto es un mensaje de control: connected cuando el stream se abre, o un error como plan_lacks_sse cuando el plan de la clave no incluye stream. Un array es un lote de alertas. Cada alerta identifica la línea con sport, league, sect, outcome y period, lleva el precio antes y después como from_price y to_price, añade nvp, el precio justo sin margen tras el movimiento, y marca la hora de la alerta en segundos Unix como alerted. El porcentaje lo calculas tú: (2.86 − 2.70) ÷ 2.86 = 5,6%.
Reconexiones y periodos de silencio
Las conexiones mueren: los proxies expiran por inactividad, las redes fallan, hay despliegues. Reconecta con una pausa que crezca tras cada fallo. Un cliente que reconecta en un bucle cerrado recibe un único frame de error rate_limited con una cabecera Retry-After: 60, así que respétala en lugar de martillear el endpoint.
Las alertas perdidas no se repiten: la documentación no promete punto de reanudación, así que trata todo lo que cayó durante el hueco como perdido. Cuando un hueco importe, rellénalo desde el endpoint REST de caídas, que conserva las caídas recientes hasta unas tres horas, con una marca de tiempo en cada una.
Los periodos de silencio son normales, sobre todo en prepartido. Para distinguir un mercado tranquilo de un feed roto, consulta el endpoint de health junto con el stream: informa de hace cuánto escribió por última vez el feed en vivo. Si esa antigüedad sigue creciendo mientras tu conexión no dice nada, ciérrala y reconecta.
Mantener el estado de la regla en el servidor
Los umbrales, los conjuntos de alertas vistas y las ventanas de deduplicación pertenecen al servidor, no a una pestaña del navegador que puede dormirse o cerrarse. El proceso lector es dueño de la conexión; lo que evalúa tus reglas debería estar a su lado.
Haz que el procesamiento sea idempotente. Construye la clave de deduplicación con id, sect, outcome, period y alerted en lugar de un solo campo, y descarta los duplicados antes de que la regla se ejecute. Persiste la hora de la última alerta procesada junto con el estado de la regla, y un reinicio se reanuda limpiamente en lugar de volver a alertar sobre movimientos que ya gestionaste.
Cuándo los frames en bruto superan a SSE
SSE es la opción correcta por defecto para alertas: el stream detecta las caídas y tu cliente solo gestiona eventos que ya cruzaron una línea. Elige WebSocket en bruto cuando tu aplicación necesite cada frame, porque reconstruyes tú mismo el estado completo del mercado en lugar de consumir eventos de caída terminados. Eso cubre el seguimiento de mercados que no se han movido lo suficiente para alertar, o la aplicación de una lógica de detección que el stream de caídas nunca fue diseñado para ejecutar. El complemento de WebSocket en bruto cuesta 99 USD cada 30 días en los planes REST y combinados. Si tu regla solo reacciona a caídas, quédate con SSE; todo lo de esta página sigue siendo válido.
Prueba tu regla primero
Antes de mantener una conexión abierta, comprueba la regla sobre el papel. La guía de alertas de caída cubre la fórmula porcentual y cómo se combinan umbrales, ventanas y filtros. Las opciones de acceso por streaming están en planes.
Cuando la regla se sostenga sobre el papel, conecta el stream y déjalo funcionar.
Si prefieres partir de código que ya funciona, el quickstart de Python en pnclFEED tiene un listener SSE que lee este stream tal como es.