#motorsport

Formula 1 live timing and telemetry as an API, powered by OpenF1 — clean JSON, no key. List race weekends and their sessions (practice, qualifying, sprint, race), the drivers in any session with team and colours, and dive into the timing: lap times with sector splits and speed-trap speeds, pit stops with durations, tyre stints with compound and lap range, track weather (air and track temperature, humidity, rainfall, wind), race-control messages (flags, safety cars, penalties) and team-radio clips. Granular session-by-session data from 2023 onward. Distinct from F1 reference data: this is the live-timing and telemetry layer — ideal for live dashboards, strategy and lap-time analysis, second-screen apps and Discord bots. 9 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

api.oanor.com/openf1-api

Turbocharger and boost engineering maths as an API, computed locally and deterministically — the pressure-ratio, charge-air and airflow numbers a tuner, engine builder or motorsport engineer sizes forced induction with. The pressure-ratio endpoint gives the compressor pressure ratio = absolute manifold pressure ÷ ambient = (atmospheric + boost) ÷ atmospheric, so 10 psi at sea level is a 1.68 ratio — the x-axis of every compressor map, which climbs at altitude where ambient pressure is lower. The charge-air endpoint shows why an intercooler matters: compressing air heats it (T₂ = T₁ × (1 + (PR^0.2857 − 1)/efficiency)), and hot air is less dense, so the real gain is the charge density ratio = pressure ratio × (T₁/T_charge), not the pressure ratio alone — 10 psi at 70 % compressor efficiency makes ~93 °C and a 1.37 density ratio with no intercooler, rising toward 1.6 once an intercooler claws back the heat, and the estimated power gain tracks the density. The airflow endpoint gives the engine mass airflow ≈ displacement × (rpm/2) × volumetric efficiency × charge density, in lb/min — the y-axis of the compressor map you plot against the pressure ratio to land in the efficient island and avoid surge or choke. Everything is computed locally and deterministically, so it is instant and private. Ideal for engine-tuning and turbo-sizing tools, dyno and data-logging apps, and motorsport calculators. Pure local computation — no key, no third-party service, instant. Sizing estimates — verify on a dyno. 3 compute endpoints. For engine displacement and compression use an engine API; for shop compressed air a compressor API.

api.oanor.com/turbo-api

Air-fuel ratio and lambda maths for engine tuning as an API, computed locally and deterministically — the lambda, AFR and mixture numbers a tuner, ECU developer or motorsport engineer dials fuelling in with. The lambda endpoint turns a measured air-fuel ratio into lambda (the AFR divided by the fuel's stoichiometric AFR — 14.7 for gasoline) and the equivalence ratio φ = 1/lambda, classifying the mix as rich, stoichiometric or lean: a gasoline AFR of 13.0 is lambda 0.88, an 11.6 % rich mixture, the sort used at wide-open throttle for power and a cooler, safer burn. The afr endpoint runs it the other way — pick a target lambda and it gives the AFR the wideband should read — and because the AFR number is fuel-specific (E85's stoichiometric AFR is about 9.8, not 14.7) it always works from the right fuel, which is why pros tune in lambda when switching fuels. The mixture endpoint links the air the engine breathes to the fuel the injectors must add: give an air mass and a target lambda and it returns the fuel mass (or vice-versa), the heart of how an ECU sizes fuelling from measured airflow. Built-in stoichiometric ratios for gasoline, E10, E85, ethanol, methanol, diesel, LPG, propane, methane/CNG and hydrogen, or pass your own. Everything is computed locally and deterministically, so it is instant and private. Ideal for engine-tuning and dyno tools, ECU and standalone-management apps, motorsport and data-logging utilities. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For engine displacement and power use an engine API; for chemical reaction stoichiometry a stoichiometry API.

api.oanor.com/airfuel-api

Quarter-mile drag-strip maths as an API, computed locally and deterministically — the classic empirical estimates a racer, tuner or car enthusiast uses to relate a car's power and weight to its performance. The et endpoint gives the predicted elapsed time and trap speed from flywheel horsepower and race weight using the standard formulas — ET = 5.825 × (weight ÷ hp) raised to the one-third, trap speed = 234 × (hp ÷ weight) raised to the one-third — so a 3,000 lb car with 300 hp is predicted to run about 12.6 seconds at 109 mph, assuming a competent launch and decent traction. The horsepower endpoint runs it in reverse: because trap speed is set by power-to-weight and barely by the launch, hp ≈ weight × (trap ÷ 234) cubed is a popular way to estimate flywheel power straight off a timeslip. The power-to-weight endpoint gives the ratio that actually decides acceleration — in horsepower per pound, horsepower per ton and watts per kilogram, the cleanest cross-unit figure — with a performance class from commuter through hot hatch and supercar to hypercar, because a light 200 hp car can beat a heavy 400 hp one. Everything is computed locally and deterministically, so it is instant and private. Ideal for drag-racing and tuner apps, car-spec and comparison tools, automotive enthusiasts and motorsport dashboards. Pure local computation — no key, no third-party service, instant. Empirical estimates assuming a good launch and traction — not a timeslip. 3 compute endpoints. For aerodynamic drag use a drag API; for gearing use a gear-ratio API.

api.oanor.com/quartermile-api

Vehicle-suspension maths as an API, computed locally and deterministically — the spring and frequency numbers a racer, tuner or chassis engineer sets a car up with. The wheel-rate endpoint converts a spring rate to the rate the wheel actually feels: wheel rate = spring rate × motion ratio², where the motion ratio is the spring's travel per unit of wheel travel — a 200 lb/in spring at a 0.7 motion ratio gives a 98 lb/in wheel rate, because the spring's leverage softens it. The frequency endpoint gives the ride (natural) frequency at a corner, f = (1/2π)·√(wheel rate × g ÷ corner sprung weight), the number that really sets the ride: luxury cars run about 0.5–1.2 Hz, sporty street 1.2–1.7, race cars 2 Hz and up. The spring-rate endpoint inverts it — the spring rate needed to hit a target frequency for a corner weight and motion ratio — so you can pick the frequency for the car's job and get the spring straight out. Everything is computed locally and deterministically, so it is instant and private. Ideal for motorsport and tuning apps, chassis-setup and corner-balancing tools, suspension-design calculators, and engineering study aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — real ride also depends on damping and tyres.

api.oanor.com/suspension-api

Internal-combustion engine maths as an API, computed locally and deterministically. The displacement endpoint computes an engine's swept volume from the bore, the stroke and the number of cylinders, V = (π/4)·bore²·stroke per cylinder, in cubic centimetres, litres and cubic inches, and classifies the bore-to-stroke geometry as oversquare, square or undersquare. The compression endpoint relates the compression ratio and the clearance volume, CR = (swept + clearance)/clearance — give the clearance to get the ratio or the ratio to get the clearance — and, with a boost pressure, estimates the effective compression ratio of a forced-induction engine. The power-to-weight endpoint computes the power-to-weight ratio in horsepower per tonne, kilowatts per tonne and watts per kilogram, the weight per horsepower, and, with a displacement, the specific output in horsepower per litre. Bore and stroke are in millimetres, volumes in cc, weight in kilograms and power in horsepower or kilowatts. Everything is computed locally and deterministically, so it is instant and private. Ideal for automotive, motorsport, motorcycle and engine-builder app developers, build-spec and tuning tools, and mechanical education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is engine geometry and tuning; for EPA fuel-economy data use a fuel-economy API and for tyre sizes a tyre-calculator API.

api.oanor.com/engine-api

Formula 1 reference data as an API, built on the Ergast / Jolpica F1 dataset — every driver, constructor and circuit in F1 history plus every season since 1950. Look up a driver by id or name (e.g. hamilton → Lewis Hamilton, code HAM, #44, British), a constructor/team (ferrari → Ferrari), or a circuit with its coordinates and country (monza → Autodromo Nazionale di Monza, Italy); or search across all three (e.g. "verstappen" → Jos & Max Verstappen). 879 drivers, 214 constructors, 78 circuits. Ideal for motorsport apps, fantasy F1, sports trivia and data dashboards.

api.oanor.com/f1-api