Para que serve a API OpenF1 e como tirar o máximo proveito dela?

A API OpenF1 é usada para oferecer dados históricos e em tempo real da Fórmula 1 Código aberto, facilitando a criação de painéis, alertas automatizados, estratégias de estudo ou dispositivos conectados que reagem a eventos na pista. Sua proposta serve como uma ponte entre telemetria e aplicações: pode ser consultada via HTTP, filtrada por parâmetros e também permite streaming de dados.

Se você está se perguntando como ele difere de outras soluções, o segredo é sua abordagem aberta e prática: dados históricos gratuitos sem autenticação, acesso a pagamentos em tempo real (sob demanda) e múltiplos métodos de consumo (REST, MQTT e WebSockets). A fonte de dados é de livetiming.formula1.com, e embora o OpenF1 seja um projeto não oficial, ele reúne informações muito valiosas, como tempos de volta, dados do carro, comunicações de rádio, controle de corrida, meteorologia, turnos, posições e muito mais.

O que é OpenF1 e o que ele oferece a você?

OpenF1 é uma API livre e de código aberto que expõe dados da F1 para que qualquer pessoa possa explorar a competição de uma perspectiva técnica e reproduzível. O objetivo é facilitar a criação de Painéis interativos, análise de carreira aprofundada ou até mesmo gadgets que acendem quando seu motorista favorito ultrapassa ou ativa o DRS. É uma alternativa inspirada no ecossistema de FastF1, com a vantagem de oferecer dados ao vivo durante as sessões (para contas com acesso), além de séries históricas.

Duas nuances operacionais devem ser levadas em consideração: alguns pontos finais podem não transmita ao vivo durante a sessão e publicados logo depois (por exemplo, car_data, intervalos ou localização), e o acesso ao vivo requer uma conta paga. De qualquer forma, o histórico é gratuito e acessível em JSON ou CSV sem autenticação, ideal para iniciar a prototipagem sem atrito.

Casos de uso comuns

Com o OpenF1 você pode construir do zero um painel de cronometragem que exibe voltas, setores, lacunas e intervalos, aprimorado com rádio de equipe e eventos de controle de corrida. Adicione gráficos de velocidade máxima, RPM ou marchas e você terá uma visão básica de telemetria para comparar turnos e pilotos.

Em ambientes analíticos, você cruzará tempos de volta, compostos e idade dos pneus para investigar cortes, rebaixamentos e janelas de desligamento. Você também pode automatizar alertas por bandeiras, VSC/SC ou mudanças de posição, bem como registrar as condições da pista e do vento que afetam o ritmo.

Se você gosta de dispositivos conectados, o streaming via MQTT/WebSockets permitirá que você ligue LEDs, notificam em celulares ou desencadear efeitos quando há uma ultrapassagem ou quando aparece uma bandeira amarela. A abordagem "API-first" se encaixa igualmente bem em microsserviços como em Aplicativos frente que consomem dados agregados.

Estrutura da API REST: Endpoints e o que eles oferecem

A API REST é organizada por recursos de tópicos. Cada endpoint suporta filtros por parâmetros (incluindo operadores como >, <, >=, <=) e retorna dados em JSON ou CSV (adicionando csv=true). Abaixo, uma visão geral abrangente do que cada caminho de chave abrange.

Dados do carro

O endpoint car_data expõe variáveis ​​do carro em ~3,7 Hz (velocidade, RPM, marchas…). Pode não estar disponível em sessões ao vivo e publicado logo depois. URL base: GET https://api.openf1.org/v1/car_data.

• freio: pedal do freio (100 pressionado, 0 não).
• dados: UTC instantâneo em ISO 8601.
• número_do_motorista: número único do piloto.
• drs: Status do DRS (mapeamentos conhecidos: 0/1 desativado, 8 detectados elegíveis, 10/12/14 ativados; outros valores duvidosos).
• chave_de_reunião: ID da reunião (você pode usar mais recente).
• n_gear: marcha 1–8 (0 neutro).
• rpm: revoluções por minuto.
• chave_sessão: ID da sessão (suporta mais recente).
• velocidade: km/h.
• regulador de pressão: % acelerador.

Há um mapeamento útil dos estados do DRS: 0/1 = desligado, 8 = detectado e elegível, 10/12/14 = ligadoAlguns valores intermediários aparecem como desconhecidos.

Drivers

Retorna informações do piloto por sessão com nomes para TV, equipe e códigos. OBTER /v1/drivers.

• nome_da_transmissão: nome em gráficos de TV.
• Código do país: código do país.
• número_do_motorista: dorsal única.
• primeiro_nome, último_nome, nome_completo: nomes de pilotos.
• URL da foto da cabeça: foto do rosto.
• chave_de_reunião, chave_de_sessão: IDs.
• nome_sigla: sigla de três letras.
• cor_da_equipe: cor hexadecimal da equipe.
• nome_da_equipe: nome da equipe.

Intervalos

Intervalos entre carros e lacuna para o líder, atualizados a cada 4 s somente na corrida (o ao vivo pode ser divulgado após a sessão). OBTER /v1/intervalos.

• dados: carimbo de data/hora.
• número_do_motorista: dorsal.
• lacuna_para_líder: segundos para o líder, “+1 LAP” se ultrapassado ou nulo se for líder.
• intervalo: tempo até o carro anterior, “+1 LAP” se aplicável ou nulo se estiver na liderança.
• chave_de_reunião, chave_de_sessão: IDs.

Laps

Informações detalhadas por volta (setores, velocidades, pit-out, armadilha de velocidade). OBTER /v1/laps.

• data_início: início aproximado do retorno.
• número_do_motorista: dorsal.
• duração_setor_1/2/3: vezes por setor.
• velocidade_i1, velocidade_i2: velocidades em intermediários.
• é_o_pit_out_lap: verdadeiro se for volta de saída dos boxes.
• duração da volta: tempo total.
• número_de_volta: número da volta.
• segmentos_setor_1/2/3: mini-setores (valores 2048 = amarelo, 2049 = verde, 2051 = roxo, 2064 = pitlane; outros valores possíveis).
• velocidade_st: velocidade na armadilha.
• chave_de_reunião, chave_de_sessão: IDs.

Os segmentos não estão disponíveis em corrida e pode haver incompatibilidades de cores na TV por razões desconhecidas.

Localização:

Coordenadas aproximadas do carro na pista em ~3,7 Hz (não inclui posição lateral na pista, somente progresso). O Live pode ser postado após a sessão. OBTER /v1/localização.

• dados: Hora UTC.
• número_do_motorista: dorsal.
• chave_de_reunião, chave_de_sessão: IDs.
• x, y, z: Coordenadas cartesianas.

Reuniões

Agrupe um fim de semana (médico ou teste) com suas sessões. OBTER /v1/reuniões.

• chave_do_circuito, nome_abreviado_do_circuito: circuito.
• código_do_país, chave_do_país, nome_do_país: país.
• data_início: começar.
• gmt_offset: diferença de horário vs GMT.
• local: cidade/localização.
• chave_de_reunião: ID da reunião.
• nome_da_reunião, nome_oficial_da_reunião: nomes.
• ano: ano.

Ultrapassagens (beta)

Ultrapassagens e mudanças de posição (inclui penalidades na pista, nos boxes e após a corrida). Somente em corridas e pode estar incompleto. OBTER /v1/overtakes.

• dados: instantâneo.
• chave_de_reunião, chave_de_sessão: IDs.
• número_de_motoristas_ultrapassados: dorsal excedido.
• número_de_motorista_ultrapassado: dorsal anterior.
• posição: posição após completar a ultrapassagem.

Cova

Passagens pelo pit lane com duração total da entrada até a saída. OBTER /v1/pit.

• dados, número_do_motorista, número_de_volta: contexto.
• chave_de_reunião, chave_de_sessão: IDs.
• duração do pit: segundos no pitlane.

Posição

Posições dos pilotos ao longo da sessão, incluindo mudanças. OBTER /v1/posição.

• dados, número_do_motorista.
• chave_de_reunião, chave_de_sessão.
• posição: 1 em diante.

Controle de corrida

Eventos oficiais: bandeiras, DRS, Safety Car, VSC, mensagens e diversas categorias. OBTER /v1/race_control.

• categoria: CarEvent, Drs, Flag, SafetyCar, etc.
• dados, número_do_motorista, número_de_volta.
• bandeira: tipos (VERDE, AMARELO, AMARELO DUPLO, XADREZ…).
• mensagem: descrição do evento.
• escopo: Pista, Piloto, Setor…
• setor: mini-setor envolvido (se aplicável).
• chave_de_reunião, chave_de_sessão.

Sessões

Lista e detalhes das sessões (Treino, Qualificação, Sprint, Corrida…). OBTER /v1/sessões.

• chave_do_circuito, nome_abreviado_do_circuito.
• código_do_país, chave_do_país, nome_do_país.
• data_início, data_fim, gmt_offset, local.
• chave_de_reunião, chave_de_sessão.
• nome_da_sessão: Treino 1, Qualificação, Corrida…
• tipo_de_sessão: Treino, qualificação, corrida…
• ano.

Resultado da sessão (beta)

Classificação após cada sessão: melhores voltas ou tempo total da corrida. OBTER /v1/resultado_da_sessão.

• dnf, dns, dsq: não termina, não começa, desclassificado.
• número_do_motorista, chave_de_reunião, chave_sessão.
• duração: melhor volta (treino livre/classificação) ou tempo total (corrida). Na qualificação, matriz [Q1, Q2, Q3].
• lacuna_para_líder: diferença vs líder; em quali, matriz [Q1, Q2, Q3].
• número_de_voltas: voltas completadas.
• posição: posição final.

Grade de largada (beta)

Grid de largada para a próxima corrida. OBTER /v1/grade_inicial.

• número_do_motorista, chave_de_reunião, chave_sessão.
• duração da volta: tempo de volta de qualificação.
• posição: coloque na grelha.

Períodos

Períodos de condução contínua por composto e idade do pneu. OBTER /v1/stints.

• composto: MACIO, MÉDIO, DURO…
• número_do_motorista, chave_de_reunião, chave_sessão.
• início da volta, fim da volta: intervalo de voltas.
• número_de_tempo: ordinal do período.
• idade_do_pneu_na_partida: idade do pneu no início (em voltas).

Rádio da equipe

Seleção de mensagens de rádio entre pilotos e equipes (não 100% das comunicações). OBTER /v1/team_radio.

• dados, número_do_motorista.
• chave_de_reunião, chave_sessão.
• url_de_gravação: link para áudio.

Clima

Clima do circuito com atualização a cada minuto. OBTER /v1/clima.

• temperatura do ar (°C), temperatura_da_trilha (°C).
• umidade (%), pressão (mbar), chuva.
• direção_do_vento (0–359°), velocidade do vento (EM).
• dados, chave_de_reunião, chave_sessão.

Filtros, tempo e formatos: aproveite ao máximo suas consultas

Uma das vantagens do OpenF1 é sua filtragem por parâmetros na própria URL, incluindo operadores relacionais. Isso permite consultas expressivas, como filtragem por duração da volta, escolha de um intervalo de datas ou limitação por número da corrida e sessão.

Além de filtrar por campos, você pode usar intervalos de tempo com date_start e date_end (suporta vários formatos compatíveis com dateutil.parser, como “2021-09-10”, “2021-09-10T14:30:20+00:00”, “10 de setembro de 2021”, etc.).

Se preferir planilhas, adicione csv=verdadeiro para a consulta e download em CSV. É ideal para Excel ou para ETL rápido antes de carregar dados em um warehouse analítico.

Exemplos (parafraseados do material de origem para sua referência): Sainz saiu dos boxes por pelo menos 120 segundos em uma sessão específica: /v1/laps?session_key=9222&driver_number=55&is_pit_out_lap=true&lap_duration>=120. Todas as sessões de Setembro de 2023: /v1/sessions?date_start>=2023-09-01&date_end<=2023-09-30. E se você quiser em CSV: /v1/sessions?year=2023&csv=true.

Acesso em tempo real: autenticação e cabeçalhos OAuth2

Para dados ao vivo, você precisa de uma conta aprovada e um fluxo de OAuth2 simples: envie nome de usuário e senha para /token, você recebe um token de acesso com expiração de 1 hora e você inclui como O portador no cabeçalho de autorização de suas solicitações.

Detalhes operacionais que você deve saber: A API é frequentemente atualizada com um atraso de ~3 segundos em relação ao vivo (pode variar de acordo frio começa), e as consultas REST têm um Tempo limite de 10 sSe uma consulta demorar muito, divida-a em partes e combine os resultados localmente.

Lembre-se de que o token expira em 1 hora; sua aplicação deve renovar o token de forma transparente. Para suporte e feedback geral, o canal recomendado é Discussões no Github; Os bugs são relatados por meio da criação de problemas no repositório.

Streaming eficiente com MQTT e WebSockets

Para aplicações sensíveis ao tempo, a recomendação é priorizar MQTT ou WebSockets (MQTT sobre WSS) porque eles enviam dados assim que estão disponíveis, evitando pesquisas contínuas.

Conexões típicas: MQTT TLS ativado mqtt.openf1.org:8883 e WebSockets seguros em wss://mqtt.openf1.org:8084/mqtt. A autenticação usa o token de acesso como senha; o nome de usuário pode ser qualquer sequência não vazia (ou seu e-mail).

Os tópicos refletem pontos de extremidade REST (por exemplo: v1/sessions, v1/laps, v1/location…), com a opção de curingas, se o seu cliente os suportar. O payload é JSON e adiciona campos úteis: _id (inteiro crescente para classificar por tempo) e _chave (identificador de documento para versões sucessivas do mesmo objeto, por exemplo, rodadas que são atualizadas com fatias).

Exemplo de mensagem de localização (formato ilustrativo): inclui meeting_key, session_key e driver_number, bem como coordenadas e 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
}

Segurança e boas práticas

A prioridade é proteger credenciais e tokensA troca de nome de usuário/senha para token deve ficar no seu backend: nunca incorpore credenciais diretas no código do cliente inspecionável.

Para aplicativos da web, transmita o token por HTTPS e evite expô-lo em armazenamento local se houver risco de XSS; avaliar cookies HttpOnly + Seguro quando aplicável. Em arquiteturas com streaming do navegador, considere se é mais seguro manter o Conexão MQTT/WebSocket em seus eventos de backend e encaminhamento para clientes.

Em ambientes de backend, ele armazena o token com segurança e lida com seu renovação com antecedência. Não publique tokens em repositórios públicos nem os cole em exemplos de código compartilhados.

Ecossistema, contribuições e roteiro

O OpenF1 tem como objetivo democratizar os dados da F1 tornando-os acessíveis. Eles convidam você a propor ideias em Discussões do GitHub e colaborar por meio de RPs. O serviço é gratuito (sem autenticação ou limites de taxa para dados históricos), mas solicita uso responsável e, se você achar útil, apoie sua sustentabilidade com doações.

O roteiro menciona a incorporação classificações e calendários, adicione temporadas de 2018–2022, transcrições por IA para rádio, tempos de parada mais precisos e métricas de ultrapassagem e pneus. Há também uma isenção de responsabilidade: eles não garantem disponibilidade ou precisão contínua absoluto e não somos responsáveis ​​por quaisquer perdas decorrentes do uso.

Crédito para FastF1 e seu autor por inspirar partes do sistema (incluindo o gravador SignalR) e lembrete legal: OpenF1 não é afiliado às empresas de F1; marcas registradas e direitos são da Formula One Licensing BV

Comparação e alternativas: Live Pulse e outros serviços

No ecossistema existem serviços como o “F1 Live Pulse” (via plataformas do tipo RapidAPI) que visam oferecer Dados em tempo real, mensagens oficiais, corridas de pneus, rádio de equipe, clima e classificações com previsões. Eles costumam organizar pontos de extremidade para pilotos, tempos, pit stops, rádio, controle de corrida, clima e classificação, com foco em aplicativos e painéis avançados.

APIs comerciais como “api-formula-1.p.rapidapi.com” também estão disponíveis. Um guia prático em espanhol mostrou como consumir rankings com XMLHttpRequest e então migrá-los para buscar devido a um problema de CORS, adicionando os cabeçalhos “x-rapidapi-key” e “x-rapidapi-host”. Este é um bom lembrete de que, ao trabalhar com APIs no navegador, CORS e chaves requer cuidado; um backend que faça proxy da solicitação geralmente é preferível.

Se você optar pelo OpenF1, terá a vantagem de histórico aberto, filtros expressivos, CSV nativo e um modo ao vivo com OAuth2, além de streaming via MQTT/WebSockets. Dependendo do seu caso, você pode combiná-lo com outras fontes, sempre respeitando licenças e termos de cada serviço.

Começando localmente com Python e MongoDB

Alguns recursos recomendam a configuração de um ambiente local para processamento e salvamento de dados. Uma abordagem típica é instalar Servidor da Comunidade MongoDB v7, certifique-se de ter Python ≥ 3.10 y pip ≥ 23e instale o pacote OpenF1 Python.

Após a instalação, configure a variável de ambiente CADEIA_DE_CONEXÃO_MONGO apontando para sua instância local/remota e inicializando o projeto para consumir e armazenar dados. Esse padrão facilita a análise e a reprodução painéis próprios conectado ao seu banco de dados.