Prueba tu pipeline de cuotas de Pinnacle offline antes del lanzamiento

Un pipeline de sondeo de la API de cuotas de Pinnacle puede probarse casi por completo offline. Captura un pequeño conjunto de respuestas reales mientras estás con la clave gratuita, luego reproduce esos archivos por tu parser, tu lógica de cursor y tu capa de almacenamiento. Solo la frescura y el ritmo temporal aún necesitan la API en vivo. Todo lo demás puede fallar con seguridad en tu máquina primero.

Graba un conjunto de fixtures una vez

Necesitas tres grabaciones: una lectura completa del tablero, la lectura delta que la sigue y una respuesta de error. La API REST responde a una lectura completa con un array de eventos y un cursor last; devuelve ese cursor como since y la siguiente llamada retorna solo lo que cambió. El contraste documentado es nítido: 1.522 eventos para un tablero completo de fútbol prepartido contra 7 eventos cambiados en el delta posterior, como señala la guía de integración, verificado el 2026-09-29.

Guarda cada cuerpo de respuesta en un archivo con su código de estado, sus cabeceras y el cursor que pasaste. La cuota de la clave gratuita, 100 solicitudes al día, cubre esto y deja el día casi intacto. Mantén los archivos en tu repositorio junto a las pruebas y actualízalos cuando cambies los deportes que cubres.

Reproduce por tu parser

Apunta el parser a los archivos en lugar de la red. Debe producir el mismo estado de mercado desde la lectura completa grabada cada vez, y aplicar el delta grabado debe cambiar exactamente los eventos que cambiaron. Aquí es donde salen la mayoría de los errores de parseo: períodos ausentes, ligas renombradas, un mercado que aparece en un período y no en otro.

Si mantienes una tabla de cambios de precio, reproducir el delta dos veces no debe duplicar las filas. La regla del diseño de almacenamiento, insertar solo cuando el precio de una selección difiere de la última fila que guardas, es exactamente el tipo de invariante que una prueba de reproducción refuerza.

Ensaya los fallos a propósito

Offline es el único lugar donde la API falla bajo orden. Sirve a tu cliente tres respuestas preparadas: un 429 con cabecera Retry-After, un 500 y un 200 con JSON truncado. El comportamiento esperado viene de la guía de límites de tasa: honra el Retry-After exactamente, retrocede con jitter cuando no haya cabecera, limita los intentos para que un ciclo malo falle en lugar de bloquear el siguiente, y trata un 200 con un sobre inválido como un error y no como un tablero vacío.

Registra lo que tu cliente hace en cada caso. Un cliente que martillea a través de un 429 preparado martilleará a través de uno real en día de partido, cuando el margen más importa.

Prueba el camino de reinicio

Mata el proceso a mitad de ciclo, reinícialo y comprueba que el sondeo retoma desde el cursor almacenado en lugar de releer un tablero completo. La guía de integración reserva los snapshots completos para el primer arranque y la recuperación de desastres; tu prueba debe demostrar que el estado estacionario realmente funciona así.

Si mantienes un mapa de últimos precios en memoria para deduplicación, reconstrúyelo desde la tabla al arrancar y confirma que el primer sondeo tras el reinicio no escribe cambios fantasma.

Lo que aún necesita la API en vivo

Los fixtures no pueden probar la frescura. Los tableros prepartido se actualizan al ritmo de la fuente, unos 30 segundos según la guía de capacidad, verificado el 2026-09-29, así que sondear más rápido no compra nada, y solo una ejecución en vivo muestra la cadencia real de los cambios. Termina el ensayo con una pequeña ronda en vivo con la clave gratuita: un tablero, unos pocos sondeos con un minuto de separación, y luego compara los tamaños de delta observados con tus grabaciones.

Graba una vez, reproduce muchas, falla a propósito. La cuota que no gastas probando es la cuota que tu primera semana en vivo se guarda para sí.