Confirma el plan base y el complemento
Los datos de Pinnacle documentan el WebSocket en bruto como un complemento de cobro aparte para Snapshots REST, REST + SSE y REST de alto volumen. El plan Alertas de caída SSE y los planes de prueba no son planes base elegibles para ese complemento. El streaming en bruto no suministra automáticamente el producto de alertas SSE procesadas. Comprueba los derechos vigentes de la cuenta antes de abrir la conexión. La página de precios calcula las combinaciones elegibles a partir del calendario de precios publicado. Revisado contra la documentación actual, 26 de septiembre de 2026.
El endpoint documentado es una URL de feed wss:, con la clave en su cadena de consulta de conexión. Mantén esta conexión en un servidor de confianza y elimina la URL completa de los registros. Este sitio nunca te pide una clave ni abre una conexión en tu navegador.
Suscríbete, establece una línea base y luego consume
El servicio requiere un mensaje de suscripción poco después de abrirse el socket; la documentación especifica cinco segundos. Envía de inmediato los streams solicitados y los filtros admitidos. Usa los ID de deporte documentados: por ejemplo, 1 es fútbol, 2 tenis, 3 baloncesto y 4 hockey. Una etiqueta copiada de un fragmento de marketing no es un contrato de esquema. Revisado contra la documentación actual, 26 de septiembre de 2026.
Empieza con un solo deporte en vivo. Recopila los fragmentos de snapshot usando sus marcadores seq y final antes de exponer una línea base completa, y responde a cada ping de aplicación con el pong documentado. Añade un watchdog de inactividad, un plazo límite para el snapshot, un límite de intentos de conexión y un presupuesto total de ejecución, para que una conexión silenciosa o que falla repetidamente no pueda ejecutarse para siempre.
No muestres un feed como listo solo porque la conexión TCP esté abierta. Tu aplicación necesita tanto el transporte como una línea base utilizable. El extracto anterior deja sin definir a propósito el manejo de frames específico de tu aplicación.
Una reconexión invalida las suposiciones anteriores
Ante una desconexión, marca la línea base local como inválida. Cierra el socket antiguo, reconecta dentro de un presupuesto acotado, vuelve a suscribirte y espera a que se complete el nuevo snapshot. No sigas presentando el estado obsoleto como actual mientras eso ocurre. Si no puedes confirmar que el socket antiguo se cerró, deja de reconectar en lugar de abrir un segundo: el servicio permite una conexión WebSocket por cuenta, y una conexión nueva expulsa a la anterior.
Esto es recuperación mediante la reconstrucción de una línea base. No es una reproducción garantizada de los frames perdidos durante la interrupción. No encontramos base para prometer una reproducción duradera ni una entrega exactamente única. Registra los huecos en tu propio sistema y decide si el trabajo posterior debe pausarse.
Reenviar frames en bruto no es reconstruir un mercado
Los registros en vivo del feed usan rec.id; esto difiere del event_id de REST. Las actualizaciones de mercado pueden ser parciales e incluir sus propias claves y versiones. Un consumidor debe interpretar la semántica de actualización y eliminación, fusionar en el límite de mercado adecuado y evitar sustituir un evento entero por una actualización parcial. Algunas descripciones de canales de la documentación se contradicen; acláralas con el servicio antes de tratar el stream como un libro de trading. Revisado contra la documentación actual, 26 de septiembre de 2026.
Reenviar sobres en bruto validados tras la puerta de la línea base es solo la primera capa. Un motor completo de estado de mercado, la reconstrucción prepartido, el manejo de contrapresión y la medición del rendimiento en vivo siguen siendo tu trabajo. Fija deliberadamente el tamaño máximo de mensaje del cliente: la documentación recomienda 8 MB, y el WebSocket nativo de Node no tiene un techo configurable de tamaño de frame, así que allí acota los mensajes tras recibirlos.
Prueba los fallos a los que pretendes sobrevivir
Antes del uso en vivo, ejercita un snapshot incompleto, un fragmento duplicado, una conexión caída, un socket estancado, un mensaje inválido y una respuesta de expulsión de cuenta. Confirma que el apagado detiene los nuevos reintentos. Luego ejecuta una validación en vivo autorizada por el propietario contra la cuenta real. Si esas responsabilidades exceden tus necesidades, Snapshots REST o alertas SSE pueden ser un punto de partida más sencillo.