Para qué sirve la API OpenF1 y cómo aprovecharla al máximo

La API OpenF1 sirve para ofrecer datos de Fórmula 1 en tiempo real e históricos de forma abierta, facilitando a desarrolladores y analistas construir paneles, automatizar alertas, estudiar estrategias o crear dispositivos conectados que reaccionan a eventos en pista. Su propuesta encaja como un puente entre la telemetría y las aplicaciones: se consulta por HTTP, se filtra por parámetros y también permite recibir datos por streaming.

Si te preguntas en qué se diferencia de otras soluciones, la clave está en su enfoque abierto y práctico: históricos gratuitos sin autenticación, acceso de pago para tiempo real (previa solicitud) y múltiples métodos de consumo (REST, MQTT y WebSockets). La fuente de datos proviene de livetiming.formula1.com, y aunque OpenF1 es un proyecto no oficial, aglutina información muy valiosa como tiempos de vuelta, car data, comunicaciones de radio, control de carrera, meteorología, stints, posiciones y mucho más.

Qué es OpenF1 y qué te aporta

OpenF1 es una API gratuita y de código abierto que expone datos de F1 para que cualquiera pueda explorar la competición desde una óptica técnica y reproducible. El objetivo es facilitar la creación de dashboards interactivos, análisis profundos de carreras o incluso gadgets que se encienden cuando tu piloto favorito adelanta o activa el DRS. Es una alternativa inspirada en el ecosistema de FastF1, con la ventaja de ofrecer datos en directo durante las sesiones (para cuentas con acceso) además de series históricas.

Conviene tener en cuenta dos matices operativos: algunos endpoints pueden no emitir en vivo durante la sesión y publicarse poco después (por ejemplo, car_data, intervals o location), y para el acceso live hay que solicitar una cuenta de pago. En cualquier caso, el histórico es libre y accesible en JSON o CSV sin autenticación, ideal para empezar a prototipar sin fricción.

Casos de uso habituales

Con OpenF1 puedes construir desde cero un panel de tiempos que muestre vueltas, sectores, gaps e intervals, enriquecido con radio de equipo y eventos de control de carrera. Añade gráficos de velocidad punta, RPM o marchas y tendrás una visión de telemetría básica para comparar stints y pilotos.

En entornos de análisis, cruzarás tiempos de vuelta, compuestos y edad de neumático para investigar undercuts, degradas y ventanas de parada. También puedes automatizar alertas por banderas, VSC/SC o cambios de posición, así como registrar condiciones de pista y viento que condicionen el ritmo.

Si te van los dispositivos conectados, el streaming por MQTT/WebSockets permitirá encender leds, notificar en móviles o disparar efectos cuando hay un overtake o aparece bandera amarilla. El enfoque “API-first” encaja igual de bien en microservicios como en apps front que consumen datos agregados.

Estructura de la API REST: endpoints y qué ofrecen

La API REST está organizada por recursos temáticos. Cada endpoint admite filtros por parámetros (incluyendo operadores como >, <, >=, <=) y devuelve datos en JSON o CSV (añadiendo csv=true). A continuación tienes un repaso exhaustivo de lo que cubre cada ruta clave.

Car data

El endpoint car_data expone variables del coche a ~3,7 Hz (velocidad, RPM, marchas…). En sesiones en vivo puede no estar disponible y publicarse poco después. URL base: GET https://api.openf1.org/v1/car_data.

• brake: pedal de freno (100 pulsado, 0 no).
• date: instante UTC en ISO 8601.
• driver_number: dorsal único del piloto.
• drs: estado del DRS (mapeos conocidos: 0/1 off, 8 detectado elegible, 10/12/14 on; otros valores dudosos).
• meeting_key: ID del meeting (puedes usar latest).
• n_gear: marcha 1–8 (0 neutro).
• rpm: revoluciones por minuto.
• session_key: ID de sesión (admite latest).
• speed: km/h.
• throttle: % de acelerador.

Hay un mapeo útil de estados de DRS: 0/1 = off, 8 = detectado y elegible, 10/12/14 = on. Algunos valores intermedios aparecen como desconocidos.

Drivers

Devuelve información del piloto por sesión con nombres para TV, equipo y códigos. GET /v1/drivers.

• broadcast_name: nombre en grafismos de TV.
• country_code: código de país.
• driver_number: dorsal único.
• first_name, last_name, full_name: nombres del piloto.
• headshot_url: foto de la cara.
• meeting_key, session_key: IDs.
• name_acronym: acrónimo de tres letras.
• team_colour: color hex del equipo.
• team_name: nombre del equipo.

Intervals

Intervalos entre coches y gap al líder, con actualización ~cada 4 s solo en carrera (en vivo puede liberarse tras la sesión). GET /v1/intervals.

• date: marca temporal.
• driver_number: dorsal.
• gap_to_leader: segundos al líder, “+1 LAP” si doblado o null si líder.
• interval: tiempo al coche precedente, “+1 LAP” si aplica o null si líder.
• meeting_key, session_key: IDs.

Laps

Información detallada por vuelta (sectores, velocidades, pit-out, speed trap). GET /v1/laps.

• date_start: inicio aproximado de la vuelta.
• driver_number: dorsal.
• duration_sector_1/2/3: tiempos por sector.
• i1_speed, i2_speed: velocidades en intermedios.
• is_pit_out_lap: true si es vuelta de salida del pit.
• lap_duration: tiempo total.
• lap_number: número de vuelta.
• segments_sector_1/2/3: mini-sectores (valores 2048 = amarillo, 2049 = verde, 2051 = morado, 2064 = pitlane; otros valores posibles).
• st_speed: velocidad en trampa.
• meeting_key, session_key: IDs.

Los segmentos no están disponibles en carreras y puede haber desajustes respecto a los colores de TV por razones desconocidas.

Location

Coordenadas aproximadas del coche en el trazado a ~3,7 Hz (no incluye posición lateral en pista, solo progreso). En vivo puede publicarse tras la sesión. GET /v1/location.

• date: tiempo UTC.
• driver_number: dorsal.
• meeting_key, session_key: IDs.
• x, y, z: coordenadas cartesianas.

Meetings

Agrupa un fin de semana (GP o test) con sus sesiones. GET /v1/meetings.

• circuit_key, circuit_short_name: circuito.
• country_code, country_key, country_name: país.
• date_start: inicio.
• gmt_offset: diferencia horaria vs GMT.
• location: ciudad/ubicación.
• meeting_key: ID del meeting.
• meeting_name, meeting_official_name: nombres.
• year: año.

Overtakes (beta)

Adelantamientos y cambios de posición (incluye on-track, pit y sanciones postcarrera). Solo en carreras y puede estar incompleto. GET /v1/overtakes.

• date: instante.
• meeting_key, session_key: IDs.
• overtaken_driver_number: dorsal superado.
• overtaking_driver_number: dorsal que adelanta.
• position: posición tras completar el adelantamiento.

Pit

Pasos por pitlane con duración total desde entrada a salida. GET /v1/pit.

• date, driver_number, lap_number: contexto.
• meeting_key, session_key: IDs.
• pit_duration: segundos en pitlane.

Position

Posiciones del piloto a lo largo de la sesión, incluyendo cambios. GET /v1/position.

• date, driver_number.
• meeting_key, session_key.
• position: 1 en adelante.

Race control

Eventos oficiales: banderas, DRS, Safety Car, VSC, mensajes y categorías varias. GET /v1/race_control.

• category: CarEvent, Drs, Flag, SafetyCar, etc.
• date, driver_number, lap_number.
• flag: tipos (GREEN, YELLOW, DOUBLE YELLOW, CHEQUERED…).
• message: descripción del evento.
• scope: Track, Driver, Sector…
• sector: mini-sector involucrado (si aplica).
• meeting_key, session_key.

Sessions

Listado y detalle de sesiones (Practice, Qualifying, Sprint, Race…). GET /v1/sessions.

• circuit_key, circuit_short_name.
• country_code, country_key, country_name.
• date_start, date_end, gmt_offset, location.
• meeting_key, session_key.
• session_name: Practice 1, Qualifying, Race…
• session_type: Practice, Qualifying, Race…
• year.

Session result (beta)

Clasificación tras cada sesión: mejores vueltas o tiempo total de carrera. GET /v1/session_result.

• dnf, dns, dsq: no termina, no inicia, descalificado.
• driver_number, meeting_key, session_key.
• duration: mejor vuelta (libres/qualy) o tiempo total (carrera). En quali, array [Q1, Q2, Q3].
• gap_to_leader: diferencia vs líder; en quali, array [Q1, Q2, Q3].
• number_of_laps: vueltas completadas.
• position: puesto final.

Starting grid (beta)

Parrilla de salida de la carrera siguiente. GET /v1/starting_grid.

• driver_number, meeting_key, session_key.
• lap_duration: tiempo de vuelta de qualy.
• position: puesto en parrilla.

Stints

Tramos de conducción continuada por compuesto y edad de neumático. GET /v1/stints.

• compound: SOFT, MEDIUM, HARD…
• driver_number, meeting_key, session_key.
• lap_start, lap_end: rango de vueltas.
• stint_number: ordinal del stint.
• tyre_age_at_start: edad del neumático al inicio (en vueltas).

Team radio

Selección de mensajes de radio entre pilotos y equipos (no es el 100% de las comunicaciones). GET /v1/team_radio.

• date, driver_number.
• meeting_key, session_key.
• recording_url: enlace al audio.

Weather

Meteorología sobre el circuito con actualización cada minuto. GET /v1/weather.

• air_temperature (°C), track_temperature (°C).
• humidity (%), pressure (mbar), rainfall.
• wind_direction (0–359°), wind_speed (m/s).
• date, meeting_key, session_key.

Filtros, tiempo y formatos: saca jugo a las consultas

Una de las ventajas de OpenF1 es su filtrado por parámetros en la propia URL, incluyendo operadores relacionales. Esto permite consultas expresivas como filtrar por duración de vuelta, elegir un rango de fechas o limitar por dorsal y sesión.

Además del filtrado por campos, puedes usar rangos temporales con date_start y date_end (admite múltiples formatos compatibles con dateutil.parser, como “2021-09-10”, “2021-09-10T14:30:20+00:00”, “Sep 10, 2021”, etc.).

Si prefieres hojas de cálculo, añade csv=true a la query y descarga en CSV. Es ideal para Excel o para ETL rápidos antes de cargar datos en un almacén analítico.

Ejemplos (parafraseados del material original para que los tengas a mano): pit-out de Sainz de al menos 120 s en una sesión concreta: /v1/laps?session_key=9222&driver_number=55&is_pit_out_lap=true&lap_duration>=120. Todas las sesiones de septiembre de 2023: /v1/sessions?date_start>=2023-09-01&date_end<=2023-09-30. Y si lo quieres en CSV: /v1/sessions?year=2023&csv=true.

Acceso en tiempo real: autenticación OAuth2 y cabeceras

Para datos live necesitas cuenta aprobada y un flujo de OAuth2 sencillo: envías usuario y contraseña a /token, recibes un access_token con caducidad de 1 hora y lo incluyes como Bearer en la cabecera Authorization de tus peticiones.

Detalles operativos que debes saber: la API suele actualizarse con un retraso de ~3 segundos respecto al directo (puede variar por cold starts), y las consultas REST tienen un timeout de 10 s. Si una query tarda, divídela en trozos y combina resultados localmente.

Recuerda que el token expira en 1 hora; tu aplicación debe renovar el token de forma transparente. Para soporte general y feedback, el canal recomendado son las Github Discussions; los bugs se reportan creando issues en el repositorio.

Streaming eficiente con MQTT y WebSockets

Para aplicaciones sensibles al tiempo, la recomendación es priorizar MQTT o WebSockets (MQTT sobre WSS) porque envían los datos en cuanto están disponibles, evitando el sondeo continuo.

Conexiones típicas: MQTT TLS en mqtt.openf1.org:8883 y WebSockets seguros en wss://mqtt.openf1.org:8084/mqtt. La autenticación usa el access token como contraseña; el nombre de usuario puede ser cualquier cadena no vacía (o tu correo).

Los topics reflejan los endpoints REST (ej.: v1/sessions, v1/laps, v1/location…), con posibilidad de comodines si tu cliente lo soporta. El payload es JSON y añade campos útiles: _id (entero creciente para ordenar por tiempo) y _key (identificador del documento para versiones sucesivas del mismo objeto, por ejemplo vueltas que se actualizan con sectores).

Ejemplo de mensaje de localización (formato ilustrativo): incluye meeting_key, session_key y driver_number, además de coordenadas y los metacampos de streaming.

{
  "meeting_key": 1257,
  "session_key": 10007,
  "driver_number": 31,
  "date": "2025-04-11T11:21:16.603025+00:00",
  "x": 0,
  "y": 0,
  "z": 0,
  "_key": "1744370476603_31",
  "_id": 1747235800206
}

Seguridad y buenas prácticas

La prioridad es proteger credenciales y tokens. El intercambio de usuario/contraseña por token debe vivir en tu backend: nunca incrustes credenciales directas en código cliente que pueda inspeccionarse.

Para apps web, transmite el token por HTTPS y evita exponerlo en localStorage si hay riesgo de XSS; valora cookies HttpOnly + Secure cuando aplique. En arquitecturas con streaming desde el navegador, sopesa si es más seguro mantener la conexión MQTT/WebSocket en tu backend y reenviar eventos a los clientes.

En entornos backend, almacena el token de forma segura y maneja su renovación con anticipación. No publiques tokens en repos públicos ni los pegues en ejemplos de código compartido.

Ecosistema, contribuciones y hoja de ruta

OpenF1 aspira a democratizar los datos de F1 haciéndolos accesibles. Invitan a proponer ideas en Github Discussions y a colaborar mediante PRs. El servicio es de uso libre (sin autenticación ni rate limits para históricos), pero se pide uso responsable y, si te resulta útil, apoyar su sostenibilidad con donaciones.

El roadmap menciona incorporar clasificaciones y calendarios, añadir temporadas 2018–2022, transcripciones por IA para radio, tiempos de parada más precisos y métricas de adelantamientos y neumáticos. También hay un descargo de responsabilidad: no garantizan disponibilidad continua ni exactitud absoluta, y no se responsabilizan de pérdidas derivadas del uso.

Crédito a FastF1 y su autor por inspirar partes del sistema (incluido el grabador SignalR), y recordatorio legal: OpenF1 no está afiliado a las compañías de F1; marcas y derechos son de Formula One Licensing B.V.

Comparativa y alternativas: Live Pulse y otros servicios

En el ecosistema hay servicios como “F1 Live Pulse” (vía plataformas tipo RapidAPI) orientados a ofrecer datos en tiempo real, mensajes oficiales, tandas de neumáticos, radio del equipo, meteorología y clasificaciones con predicciones. Suelen organizar endpoints para pilotos, tiempos, pit stops, radio, control de carrera, clima y standings, con foco en alimentar apps y paneles enriquecidos.

También circulan APIs comerciales como “api-formula-1.p.rapidapi.com”. En una guía práctica en español se mostraba cómo consumir rankings con XMLHttpRequest y después migrarlos a fetch por un problema de CORS, añadiendo los encabezados “x-rapidapi-key” y “x-rapidapi-host”. Es un buen recordatorio de que, al trabajar con APIs desde el navegador, CORS y claves requieren cuidarse; a menudo es preferible un backend que proxyea la petición.

Si optas por OpenF1, tienes la ventaja del histórico abierto, filtros expresivos, CSV nativo y un modo live con OAuth2, además de streaming por MQTT/WebSockets. Según tu caso, puedes combinarlo con otras fuentes, siempre respetando licencias y términos de cada servicio.

Puesta en marcha local con Python y MongoDB

Algunos recursos recomiendan montar un entorno local para procesar y guardar datos. Un camino típico es instalar MongoDB Community Server v7, asegurarte de tener Python ≥ 3.10 y pip ≥ 23, e instalar el paquete Python de OpenF1.

Tras la instalación, configura la variable de entorno MONGO_CONNECTION_STRING apuntando a tu instancia local/remota, y arranca el proyecto para consumir datos y almacenarlos. Este patrón facilita análisis reproducibles y dashboards propios conectados a tu base de datos.