Vad är OpenF1 API till för och hur får man ut det mesta av det?

OpenF1 API används för att erbjuda Formel 1-data i realtid och historiska data öppen källkod, vilket gör det enkelt för utvecklare och analytiker att bygga dashboards, automatisera varningar, studera strategier eller skapa uppkopplade enheter som reagerar på händelser på banan. Dess förslag fungerar som en brygga mellan telemetri och applikationer: den kan efterfrågas via HTTP, filtreras efter parametrar och möjliggör även strömmande data.

Om du undrar hur den skiljer sig från andra lösningar, är nyckeln dess öppna och praktiska tillvägagångssätt: gratis historisk data utan autentisering, betalningsåtkomst i realtid (på begäran) och flera konsumtionsmetoder (REST, MQTT och WebSockets). Datakällan är från livetiming.formula1.com, och även om OpenF1 är ett inofficiellt projekt, samlar det mycket värdefull information såsom varvtider, bildata, radiokommunikation, tävlingsledning, meteorologi, stint, positioner och mycket mer.

Vad är OpenF1 och vad erbjuder det dig?

OpenF1 är ett API fri och öppen källkod vilket exponerar F1-data så att vem som helst kan utforska tävlingen ur ett tekniskt och reproducerbart perspektiv. Målet är att underlätta skapandet av Interaktiva dashboards, djupgående karriäranalys eller till och med prylar som lyser upp när din favoritförare kör om eller aktiverar DRS. Det är ett alternativ inspirerat av ekosystemet av FastF1, med fördelen att erbjuda livedata under sessioner (för konton med åtkomst) utöver historiska serier.

Två operativa nyanser bör beaktas: vissa slutpunkter kan sänd inte live under sessionen och publiceras kort därefter (t.ex. bildata, intervaller eller plats), och liveåtkomst kräver ett betalt konto. Historiken är i vilket fall som helst gratis och tillgänglig på JSON eller CSV utan autentisering, idealisk för att starta friktionsfri prototypframtagning.

Vanliga användningsfall

Med OpenF1 kan du bygga en tidspanel från grunden som visar varv, sektorer, mellanrum och intervaller, förbättrad med teamradio och tävlingsstyrda evenemang. Lägg till grafer för topphastighet, varvtal eller växel, så får du en grundläggande telemetrivy för att jämföra stints och förare.

I analysmiljöer kommer du att möta varvtider, gummiblandningar och däckålder för att undersöka underskridningar, nedgraderingar och avstängningsfönster. Du kan också automatisera aviseringar genom att flaggor, VSC/SC eller positionsförändringar, samt registrering av ban- och vindförhållanden som påverkar tempot.

Om du gillar uppkopplade enheter kan streaming via MQTT/WebSockets göra det möjligt att aktivera Lysdioder, aviseringar på mobiltelefoner eller utlösa effekter när det sker en omkörning eller en gul flagga visas. "API-först"-metoden passar lika bra i mikrotjänster som i appar främre som förbrukar aggregerad data.

REST API-struktur: Slutpunkter och vad de erbjuder

REST API:et är organiserat efter ämnesresurser. Varje slutpunkt stöder filtrerar efter parametrar (inklusive operatorer som >, <, >=, <=) och returnerar data i JSON eller CSV (genom att lägga till csv=true). Nedan följer en omfattande översikt över vad varje nyckelsökväg täcker.

Bildata

Slutpunkten car_data exponerar bilvariabler vid ~3,7 Hz (hastighet, varvtal, växlar...). Kanske inte tillgängligt i livesessioner och publicerades kort därefter. Bas-URL: GET https://api.openf1.org/v1/car_data.

• broms: bromspedal (100 nedtryckt, 0 inte).
• datumUTC-ögonblick i ISO 8601.
• förarnummerunikt pilotnummer.
• drsDRS-status (kända mappningar: 0/1 av, 8 detekterade lämpliga, 10/12/14 på; andra värden osäkra).
• mötesnyckelMötes-ID (du kan använda senaste).
• n_växel: växel 1–8 (0 neutral).
• rpmvarv per minut.
• session_keySessions-ID (stöder senaste).
• fartkm/h.
• gaspådrag: % gaspådrag.

Det finns en användbar kartläggning av DRS-tillstånd: 0/1 = av, 8 = upptäckt och kvalificerad, 10/12/14 = denVissa mellanvärden visas som okända.

Drivrutiner

Returnerar pilotinformation per session med namn för TV, team och koder. HÄMTA /v1/drivrutiner.

• sändningsnamn: namn i TV-grafik.
• landskodlandskod.
• förarnummer: enkel rygg.
• förnamn, efternamn, fullständigt namn: pilotnamn.
• headshot_url: ansiktsfoto.
• mötesnyckel, sessionsnyckelID:n.
• namn_akronym: akronym med tre bokstäver.
• team_color: lagets hexagonfärg.
• lagnamn: lagnamn.

intervaller

Intervaller mellan bilar och avstånd till ledaren, uppdateras ~var 4:e sekund bara i loppet (live kan släppas efter sessionen). HÄMTA /v1/intervaller.

• datumtidsstämpel.
• förarnummer: dorsal.
• gap_to_leadersekunder till ledaren, ”+1 VARV” om varvat eller null om ledaren.
• intervall: tid till föregående bil, ”+1 VARV” om tillämpligt eller null om ledande.
• mötesnyckel, sessionsnyckelID:n.

Laps

Detaljerad information per varv (sektorer, hastigheter, utgrävning, fartfälla). HÄMTA /v1/varv.

• startdatumungefärlig start för återkomsten.
• förarnummer: dorsal.
• varaktighet_sektor_1/2/3gånger per sektor.
• i1_hastighet, i2_hastighet: hastigheter i mellanklassen.
• är_depån_ut_varvet: sant om det är ett varv vid depåutgång.
• varvtid: total tid.
• varvnummer: varvnummer.
• segment_sektor_1/2/3minisektorer (värden 2048 = gul, 2049 = grön, 2051 = lila, 2064 = depå; andra värden möjliga).
• st_speed: hastighet i fälla.
• mötesnyckel, sessionsnyckelID:n.

Segment är inte tillgängliga i racing och det kan förekomma färgavvikelser på TV:n av okända skäl.

Plats

Ungefärliga koordinater för bilen på banan vid ~3,7 Hz (inkluderar inte sidoläge på banan(endast framsteg). Livesändningar kan publiceras efter sessionen. HÄMTA /v1/plats.

• datumUTC-tid.
• förarnummer: dorsal.
• mötesnyckel, sessionsnyckelID:n.
• x, y, zKartesiska koordinater.

Möten

Gruppera en helg (GP eller test) med dess sessioner. HÄMTA /v1/möten.

• kretsnyckel, kretskortnamn: krets.
• landskod, landsnyckel, landsnamn: land.
• startdatum: börja.
• gmt_offsettidsskillnad kontra GMT.
• läge: stad/plats.
• mötesnyckelMötes-ID.
• mötesnamn, mötets officiella namn: namn.
• år: år.

Omkörningar (beta)

Omkörningar och positionsbyten (inklusive straff på banan, i depån och efter loppet). Endast i tävlingar och kan vara ofullständig. HÄMTA /v1/omkörningar.

• datum: omedelbar.
• mötesnyckel, sessionsnyckelID:n.
• omkörd_förarnummer: dorsal överskriden.
• omkörningsförarnummer: framåt dorsal.
• placeraposition efter avslutad omkörning.

Pit

Depåpass med total varaktighet från infart till utgång. HÄMTA /v1/pit.

• datum, förarnummer, varvnummer: sammanhang.
• mötesnyckel, sessionsnyckelID:n.
• pit_durationsekunder i depån.

Placera

Förarpositioner under hela passet, inklusive byten. HÄMTA /v1/position.

• datum, förarnummer.
• mötesnyckel, sessionsnyckel.
• placera: 1 och framåt.

Race kontroll

Officiella evenemang: flaggor, DRS, säkerhetsbil, VSC, meddelanden och olika kategorier. HÄMTA /v1/race_control.

• kategoriBilhändelse, Drs, Flagga, SafetyCar, etc.
• datum, förarnummer, varvnummer.
• flagga: typer (GRÖN, GUL, DUBBELGUL, RUTIGA…).
• meddelande: beskrivning av händelsen.
• omfattning: Bana, Förare, Sektor…
• sektor: minisektor involverad (om tillämpligt).
• mötesnyckel, sessionsnyckel.

sessioner

Lista och detaljer över pass (träning, kval, sprint, lopp…). HÄMTA /v1/sessioner.

• kretsnyckel, kretskortnamn.
• landskod, landsnyckel, landsnamn.
• startdatum, slutdatum, gmt_offset, läge.
• mötesnyckel, sessionsnyckel.
• sessionsnamnTräning 1, Kvalificering, Lopp…
• sessionstypTräning, Kval, Lopp…
• år.

Sessionsresultat (beta)

Klassificering efter varje pass: bästa varv eller total tävlingstid. HÄMTA /v1/sessionsresultat.

• dnf, dns, dsq: avslutar inte, startar inte, diskvalificerad.
• förarnummer, mötesnyckel, session_key.
• varaktighet: bästa varvtid (fri träning/kval) eller totaltid (lopp). I kvalet, array [Q1, Q2, Q3].
• gap_to_leader: skillnad vs ledare; i kvali, array [Q1, Q2, Q3].
• antal_varv: varv avklarade.
• placeraslutlig position.

Startruta (beta)

Startuppställning för nästa lopp. HÄMTA /v1/startrutnät.

• förarnummer, mötesnyckel, session_key.
• varvtid: kvalificeringsvarvtid.
• placera: lägg på grillen.

Stints

Kontinuerliga körperioder beroende på däckblandning och ålder. HÄMTA /v1/stints.

• förening: MJUK, MEDEL, HÅRD…
• förarnummer, mötesnyckel, session_key.
• varvstart, varvslut: intervall av varv.
• stintnummer: ordinal för stint.
• däckålder_vid_start: däckets ålder vid start (i varv).

Lagradio

Urval av radiomeddelanden mellan förare och team (inte 100 % av kommunikationen). HÄMTA /v1/team_radio.

• datum, förarnummer.
• mötesnyckel, session_key.
• inspelningsadress: länk till ljud.

Väder

Väder på banan med uppdatering varje minut. HÄMTA /v1/väder.

• lufttemperatur (°C), spårtemperatur (°C).
• luftfuktighet (%) tryck (mbar), regn.
• vindriktning (0–359°), vindhastighet (m/s).
• datum, mötesnyckel, session_key.

Filter, tid och format: få ut det mesta av dina sökfrågor

En av fördelarna med OpenF1 är dess filtrering efter parametrar i själva URL:en, inklusive relationella operatorer. Detta möjliggör uttrycksfulla frågor som att filtrera efter varvtid, välja ett datumintervall eller begränsa efter tävlingsnummer och session.

Förutom att filtrera efter fält kan du använda tidsintervall med date_start och date_end (stöder flera format som är kompatibla med dateutil.parser, såsom ”2021-09-10”, ”2021-09-10T14:30:20+00:00”, ”10 sep. 2021” etc.).

Om du föredrar kalkylblad, lägg till csv=sant till frågan och ladda ner i CSV-format. Den är idealisk för Excel eller Snabb ETL innan data laddas in i ett analyslager.

Exempel (parafraserade från källmaterialet för din referens): Sainz pit-out på minst 120 sekunder i en specifik session: /v1/laps?session_key=9222&driver_number=55&is_pit_out_lap=true&lap_duration>=120Alla sessioner av September 2023: /v1/sessions?date_start>=2023-09-01&date_end<=2023-09-30Och om du vill ha det i CSV: /v1/sessions?year=2023&csv=true.

Realtidsåtkomst: OAuth2-autentisering och rubriker

För livedata behöver du ett godkänt konto och ett flöde av OAuth2 enkelt: skicka användarnamn och lösenord till /token, får du en åtkomst_token med ett utgångsdatum på 1 timme och du inkluderar det som Bärare i auktoriseringsrubriken för dina förfrågningar.

Operativa detaljer du bör känna till: API:et uppdateras ofta med en fördröjning på ~3 sekunder med avseende på live (kan variera beroende på kallstarter), och REST-frågor har en 10 sekunders timeoutOm en fråga tar lång tid, dela upp den i delar och kombinera resultaten lokalt.

Kom ihåg att poletten går ut om 1 timme; din applikation måste förnya token transparent. För allmän support och feedback är den rekommenderade kanalen Github-diskussioner; Buggar rapporteras genom att skapa problem i arkivet.

Effektiv streaming med MQTT och WebSockets

För tidskänsliga tillämpningar är rekommendationen att prioritera MQTT eller WebSockets (MQTT över WSS) eftersom de skickar data så snart den är tillgänglig, vilket undviker kontinuerlig polling.

Typiska anslutningar: MQTT TLS på mqtt.openf1.org:8883 och säkra WebSockets i wss://mqtt.openf1.org:8084/mqttAutentisering använder åtkomsttoken som lösenord; användarnamnet kan vara vilken sträng som helst som inte är tom (eller din e-postadress).

mycket ämnen återspeglar REST-slutpunkter (till exempel.: v1/sessions, v1/laps, v1/location...), med möjlighet till jokertecken om din klient stöder dem. Nyttelasten är JSON och lägger till användbara fält: _id (ökande heltal för att sortera efter tid) och _nyckel (dokumentidentifierare för successiva versioner av samma objekt, till exempel rundor som uppdateras med skivor).

Exempel på ett platsmeddelande (illustrativt format): inkluderar meeting_key, session_key och driver_number, såväl som koordinater och strömmande metafält.

{
  "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
}

Säkerhet och god praxis

Prioriteten är att skydda inloggningsuppgifter och tokensUtbytet av användarnamn/lösenord-till-token bör finnas i din backend: bädda aldrig in autentiseringsuppgifter direkt i inspekterbar klientkod.

För webbappar, överför token via HTTPS och undvik att exponera den i lokalt utrymme om det finns risk för XSS; utvärdera cookies Endast Http + Säker när det är tillämpligt. I arkitekturer med strömning från webbläsaren, överväg om det är säkrare att behålla MQTT/WebSocket-anslutning i din backend och vidarebefordra händelser till klienter.

I backend-miljöer lagrar den token säkert och hanterar dess förlängning i förväg. Publicera inte tokens till offentliga repos och klistra inte in dem i delade kodexempel.

Ekosystem, bidrag och färdplan

OpenF1 siktar på att demokratisera F1-data gör dem tillgängliga. De inbjuder dig att föreslå idéer i Github-diskussioner och samarbeta genom PR. Tjänsten är gratis att använda (ingen autentisering eller hastighetsgränser för historisk data), men begäran ansvarsfull användning och, om du tycker att det är användbart, stöd dess hållbarhet med donationer.

I färdplanen nämns att man ska införliva klassificeringar och kalendrar, lägg till säsongerna 2018–2022, transkriptioner av IA för radio, mer exakta stopptider och omkörnings- och däckmätningar. Det finns också en ansvarsfriskrivning: de garanterar inte kontinuerlig tillgänglighet eller noggrannhet absolut, och ansvarar inte för eventuella förluster som uppstår till följd av användning.

Kredit till FastF1 och dess författare för inspirerande delar av systemet (inklusive SignalR-inspelaren), och juridisk påminnelse: OpenF1 är inte anslutet till F1-företagen; varumärken och rättigheter är från Formula One Licensing BV

Jämförelse och alternativ: Live Pulse och andra tjänster

I ekosystemet finns tjänster som ”F1 Live Pulse” (via RapidAPI-liknande plattformar) som syftar till att erbjuda Realtidsdata, officiella meddelanden, däckkörningar, lagradio, väder och ranking med förutsägelser. De organiserar ofta slutpunkter för förare, tider, depåstopp, radio, tävlingsledning, väder och tabellställning, med fokus på att driva appar och avancerade instrumentpaneler.

Kommersiella API:er som ”api-formula-1.p.rapidapi.com” finns också tillgängliga. En praktisk guide på spanska visade hur man använder rankningar med XMLHttpRequest och sedan migrera dem till hämta på grund av ett CORS-problem, lägger man till rubrikerna "x-rapidapi-key" och "x-rapidapi-host". Detta är en bra påminnelse om att när man arbetar med API:er från webbläsaren, CORS och nycklar kräver försiktighet; en backend som hanterar begäran via proxyserver är ofta att föredra.

Om du väljer OpenF1 har du fördelen av öppen historik, uttrycksfulla filter, Inbyggd CSV och ett liveläge med OAuth2, samt streaming via MQTT/WebSockets. Beroende på ditt fall kan du kombinera det med andra källor, alltid med respekt för licenser och villkor av varje tjänst.

Komma igång lokalt med Python och MongoDB

Vissa resurser rekommenderar att man skapar en lokal miljö för att bearbeta och spara data. En typisk metod är att installera MongoDB Community Server v7, se till att du har Python ≥ 3.10 y pip ≥ 23och installera OpenF1 Python-paketet.

Efter installationen, konfigurera miljövariabeln MONGO_CONNECTION_STRING pekar på din lokala/fjärrinstans och startar projektet för att konsumera och lagra data. Detta mönster underlättar reproducerbar analys och egna instrumentpaneler ansluten till din databas.