#fitness

Swimming maths as an API, computed locally and deterministically — the SWOLF, threshold-pace and per-100 m numbers a swimmer, coach or training app works a set out with. The swolf endpoint scores stroke efficiency for one length: SWOLF (swim + golf) = the strokes taken plus the seconds taken, and like golf lower is better — gliding further per stroke or swimming faster both cut it, so a 25 m length in 18 strokes and 30 s is a SWOLF of 48. Because it is pool-length and stroke dependent, the score is normalized to 25 m so lengths in different pools compare. The css endpoint computes Critical Swim Speed, the swimmer's threshold pace, from two all-out time trials: CSS = (distance1 − distance2) ÷ (time1 − time2) — the classic 400 m and 200 m test, where 6:00 and 2:50 give about 1.05 m/s, a 1:35 / 100 m threshold; training paces are then set as offsets from CSS, the swimmer's equivalent of a runner's threshold or an erg's 2 k pace. The pace endpoint gives speed and the per-100 m pace swimmers actually quote (time ÷ distance × 100), so 100 m in 1:30 is a 1:30 / 100 m pace at 1.11 m/s. Everything is computed locally and deterministically, so it is instant and private. Ideal for swim-training and coaching tools, lap-tracker and triathlon apps, and fitness calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For running pace use a pace API; for indoor rowing a rowing API.

api.oanor.com/swimming-api

Indoor-rowing (Concept2 erg) maths as an API, computed locally and deterministically — the watts, split and calorie numbers a rower, coach or fitness app works a piece out with, using the published Concept2 relations. The split-to-watts endpoint turns a 500 m split into power: on an erg the power is fixed by the pace, not the stroke rate, so watts = 2.80 ÷ pace³ where the pace is the seconds per metre (the split ÷ 500) — a 2:00 split is about 202 W. Because power goes as the inverse cube of pace, small split gains cost a lot of watts: pulling 1:50 instead of 2:00 is roughly 270 W, not 220. The watts-to-split endpoint inverts it — pace = (2.80 ÷ watts)^(1/3), split = pace × 500 — so a target wattage maps to the split on the monitor and a rower's power compares directly with a cyclist's or any other watts figure. The calories endpoint applies the Concept2 calorie formula, Cal/hr = (watts × 4 × 0.8604) + 300, where the +300 is a fixed resting-metabolism term that makes the erg's count run higher than pure mechanical work; 200 W is about 988 Cal/hr, roughly 494 calories over 30 minutes. Everything is computed locally and deterministically, so it is instant and private. Ideal for rowing and erg training tools, coaching and leaderboard apps, and fitness calculators. Pure local computation — no key, no third-party service, instant. Concept2 model — a machine estimate, not lab calorimetry. 3 compute endpoints. For running pace use a pace API; for cycling a cycling API.

api.oanor.com/rowing-api

Powerlifting strength-score maths as an API, computed locally and deterministically — the Wilks, DOTS and IPF GL numbers a meet, gym or training app uses to compare lifters across bodyweights and sexes. The wilks endpoint gives the classic Wilks coefficient (1996) and score: total × 500 ÷ a fifth-order polynomial in bodyweight, with separate male and female curves — long the federation standard for "best lifter", a 100 kg man totalling 600 kg scores about 365. The dots endpoint gives the modern DOTS score (2019), the same total × 500 ÷ polynomial idea but fitted to updated data with a fourth-order curve that is fairer across the weight classes and not skewed to the middleweights, now the default in most raw meet software. The ipf-gl endpoint gives the International Powerlifting Federation's current GL Points (2020): 100 × total ÷ (A − B·e^(−C·bodyweight)), with separate constants for sex and for raw (classic) versus equipped lifting, the official metric at IPF championships. Everything is computed locally and deterministically, so it is instant and private. Ideal for meet-management and scoring software, gym leaderboards and training-log apps, and strength-sport tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For one-rep-max estimation and plate loading use a strength-training API.

api.oanor.com/powerlifting-api

Barbell and weight-training maths as an API, computed locally and deterministically — the plate-loading and percentage numbers a lifter, coach or gym app works out at the rack. The plates endpoint solves the everyday gym puzzle of which plates go on each side for a target weight: 100 kg on a standard 20 kg bar means 40 kg a side, loaded heaviest first as a 25 and a 15; 102.5 kg adds the 1.25 micro-plate; and if a target is not reachable with the plates on hand it loads the closest it can and tells you the shortfall, so you never guess. It works in kilograms or pounds (225 lb on a 45 lb bar is two 45s a side), with a custom bar weight and a custom plate set. The percent endpoint turns a one-rep-max into the working weight you actually load: 80 % of a 100 kg max is 80 kg, and asking for a five-rep weight returns about 85.7 kg via the Epley formula (1RM = weight × (1 + reps ÷ 30)) — five reps sits near 86 % of max, ten reps near 75 %. The warmup endpoint builds a ramp from the empty bar to the working set at roughly 40, 55, 70 and 85 %, each rounded to a loadable increment, with the rep count dropping as the bar gets heavy. Everything is computed locally and deterministically, so it is instant and private. Ideal for gym, strength-training, powerlifting and fitness app developers, workout-logger and coaching tools, and smart-rack and plate-calculator builders. Pure local computation — no key, no third-party service, instant. Exact maths, no simulation. Live, nothing stored. 3 compute endpoints. For one-rep-max estimation from a set use a strength API.

api.oanor.com/barbell-api

Body-fat-percentage and body-composition maths as an API, computed locally and deterministically. The navy endpoint applies the US Navy circumference method — for men %BF = 495/(1.0324 − 0.19077·log10(waist − neck) + 0.15456·log10(height)) − 450, and for women a formula that adds the hip measurement — to estimate body fat from a tape measure alone, returning the percentage and the fitness category (essential, athletes, fitness, acceptable or obese); a man of 178 cm with a 40 cm neck and 90 cm waist reads about 18.7 %. The deurenberg endpoint gives the BMI-based estimate %BF = 1.20·BMI + 0.23·age − 10.8·(1 if male) − 5.4 from BMI or weight and height plus age. The composition endpoint splits a total weight into fat mass and lean (fat-free) mass from a body-fat percentage. Circumferences and height are in centimetres and weight in kilograms. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, wellness, gym, nutrition, body-tracking and health-education app developers, body-composition and progress-tracking tools, and coaching software. These are estimation formulas, not a substitute for DEXA or professional assessment. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is body-fat percentage; for body-mass index use a BMI API and for basal metabolic rate a BMR API.

api.oanor.com/bodyfat-api

Exercise calorie-burn maths as an API, computed locally and deterministically with the MET (metabolic-equivalent) method. The activity endpoint computes the calories burned by an activity, calories = MET × weight × hours, taking the MET value directly or from a named-activity table (walking, running, cycling, swimming, HIIT, rowing, yoga, weightlifting and more), and returns the calories per minute. The steps endpoint turns a step count into distance and calories: the stride is estimated from height (about 0.415 × height for walking, 0.65 for running), the distance is steps × stride, and the energy is the distance times bodyweight times a net cost of roughly 0.5 kcal/kg/km walking or 1.0 running. The duration endpoint works backwards, giving the minutes of an activity needed to burn a target number of calories. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, activity-tracking and weight-management app developers, workout and step-counter tools, and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only. 3 endpoints. This is activity energy expenditure; for resting metabolism and TDEE use a BMR API.

api.oanor.com/calorieburn-api

Hydration and fluid-balance maths as an API, computed locally and deterministically. The daily endpoint estimates the daily fluid need from bodyweight (about 35 ml per kilogram), the minutes of exercise (about 12 ml per minute) and the climate (hot adds 500 ml, very hot 1000 ml, cold subtracts 200 ml), reported in millilitres, litres and 250 ml glasses. The sweat endpoint computes the sweat rate and the degree of dehydration from a before-and-after body weight, the fluid drunk and the duration — sweat loss = (pre − post) + intake − urine, with 1 kg of lost mass treated as 1 litre, and it flags when losses pass the 2 % of body mass where performance falls off. The rehydrate endpoint computes the post-exercise rehydration target, about 1.5 times the fluid deficit to cover ongoing urine losses, with a sodium note for larger losses. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, sports and wellness app developers, endurance-training and hydration-reminder tools, and health dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. General guidance, not medical advice. 3 endpoints. This is fluid balance; for basal calories use a BMR API and for heart-rate zones use a heart-rate API.

api.oanor.com/hydration-api

Aerobic-capacity (VO2 max) estimation as an API, computed locally and deterministically. The cooper endpoint estimates VO2 max from the Cooper 12-minute run test, VO2max = (distance − 504.9)/44.73, from the distance covered in twelve minutes. The resting endpoint uses the resting heart-rate (Uth-Sørensen) method, VO2max = 15.3 × (HRmax/HRrest), with the maximum heart rate taken directly or as 220 − age — a lower resting pulse signals better fitness. The rockport endpoint applies the Rockport one-mile walk test, a multiple-regression formula on age, weight, sex, walk time and the heart rate at the finish, the most accessible sub-maximal field test. Each result comes with a broad fitness rating from poor to superior and the value in mL/kg/min. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, running and endurance-training app developers, coaching and assessment tools, sports-science and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is aerobic-capacity estimation; for heart-rate zones use a heart-rate API and for basal metabolism use a BMR API.

api.oanor.com/vo2max-api

Body-composition maths as an API, computed locally and deterministically. The bmi endpoint computes the body mass index, BMI = weight/height², classifies it on the WHO scale (underweight, normal, overweight, obese) and returns the healthy weight range for the person's height. The idealweight endpoint computes the ideal body weight by the four classic formulas — Devine, Robinson, Miller and Hamwi — each a base weight plus an increment for every inch of height above five feet, and their average. The bodyfat endpoint estimates body-fat percentage by the US Navy circumference method from the neck and waist (and hip for women) and the height, classifies it from essential to high, and — given a weight — splits it into fat mass and lean mass. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, health and wellness app developers, body-tracking and coaching tools, gym and clinic dashboards, and self-assessment apps. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is body composition; for basal metabolic rate and calories use a BMR API.

api.oanor.com/bmi-api

Energy-expenditure and nutrition maths as an API, computed locally and deterministically. The bmr endpoint computes the basal metabolic rate — the calories the body burns at rest — from weight, height, age and sex, using the modern Mifflin-St Jeor equation (BMR = 10·kg + 6.25·cm − 5·age + 5 for men, −161 for women) and reporting the classic revised Harris-Benedict value alongside for comparison. The tdee endpoint computes the total daily energy expenditure, TDEE = BMR × an activity factor from sedentary (1.2) to very active (1.9), and the goal calories for maintenance, mild and standard weight loss and weight gain — a 500 kcal/day deficit or surplus is about 0.45 kg per week. The macros endpoint splits a calorie target into protein, fat and carbohydrate grams, with protein set per kilogram of bodyweight (4 kcal/g protein and carbs, 9 kcal/g fat). Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, nutrition and health-app developers, diet and meal-planning tools, gym and coaching apps, and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is metabolic-rate and calorie maths; for body-mass-index use a BMI calculator.

api.oanor.com/bmr-api

Cycling performance maths as an API. The power endpoint estimates the power in watts needed to ride at a given speed on a given gradient, from a physical model — rolling resistance, gravity on the climb, and aerodynamic drag — with sensible defaults you can override (rolling-resistance coefficient, drag area CdA, air density, drivetrain efficiency and headwind), and breaks the power down into its rolling, gravity and aero components plus watts-per-kilogram. The ftp-zones endpoint turns a Functional Threshold Power into the seven Coggan training zones, from active recovery to neuromuscular power, as watt ranges. The vam endpoint computes VAM — vertical ascent metres per hour, the climbing-speed metric — either from elevation gained and time, or from speed and gradient. Everything is computed locally and deterministically, so it is instant and private. Ideal for cycling and training apps, bike computers and power-meter tools, coaching, and route and climb analysis. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. This is cycling maths; for running pace use a pace API and for heart-rate training zones use a heart-rate API.

api.oanor.com/cycling-api

Strength-training maths as an API. The one-rep-max endpoint estimates your one-rep max from a set of a given weight and reps using five established formulas — Epley, Brzycki, Lander, Lombardi and O'Conner — with their average, and returns a rep-max table showing the estimated weight (and percentage of 1RM) for 1 to 12 reps. The plates endpoint works out exactly which plates to load on each side of a barbell for a target weight, given the bar weight and the plate denominations you have, and tells you whether the target is achievable exactly. The wilks endpoint computes the Wilks (classic) and DOTS relative-strength scores from bodyweight and total lifted, so lifters of different sizes can be compared fairly. Everything is computed locally and deterministically, so it is instant and private. Ideal for gym and lifting apps, powerlifting and strength coaching, workout planners and progression trackers, and fitness wearables. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. This is strength maths; for BMI, BMR and calories use a health-calculator API and for heart-rate training zones use a heart-rate API.

api.oanor.com/strength-api

Heart-rate training maths as an API. The max-heart-rate endpoint estimates maximum heart rate from age by the three common formulas — Fox (220 − age), Tanaka (208 − 0.7 × age) and Gulati (206 − 0.88 × age, validated for women). The zones endpoint returns the five training zones (recovery, endurance, aerobic, threshold and maximal) as beats-per-minute ranges, computed either as a simple percentage of the maximum heart rate or, when you give a resting heart rate, by the more accurate Karvonen heart-rate-reserve method. The target endpoint computes the target heart rate for any intensity, by percentage of max or by Karvonen. You can pass an age (and choose a formula) or give your own measured max heart rate. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness and running apps, wearables and gym equipment, coaching tools, and cardio training programmes. Informational only — not medical advice. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. This is heart-rate maths; for BMI, BMR and calories use a health-calculator API and for running pace use a pace API.

api.oanor.com/heartrate-api

A running-pace calculator as an API. Work out pace and speed from a distance and a time (pace per kilometre and per mile, plus km/h, mph and m/s); compute the finish time from a distance and a target pace; predict your time at another distance using Peter Riegel's formula (T2 = T1 × (D2/D1)^1.06) — e.g. estimate a half-marathon from a 10K; and generate a split-time table for even pacing. Times accept seconds, M:SS or H:MM:SS. Perfect for running and fitness apps, race planning, training logs and pace bands. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 5 endpoints. Distinct from general unit conversion and from body-metric (BMI/BMR) health calculators.

api.oanor.com/pace-api

A complete exercise and workout database covering 870+ exercises: search and filter by target muscle, required equipment, category, difficulty level, force type and mechanic, fetch a single exercise with step-by-step instructions, primary and secondary muscles and demonstration images, pull a random exercise matching any filter, and read all available facet values to build filter UIs. Every endpoint accepts input via the query string or the request body and returns lean, predictable JSON. Pure server-side data (no third-party upstream), so responses are instant and always available. Ideal for fitness and gym apps, workout planners, personal-trainer tools and health platforms.

api.oanor.com/exercises-api

A complete health & fitness calculator suite in one API: Body Mass Index with category and healthy-weight range, Basal Metabolic Rate (Mifflin-St Jeor and Harris-Benedict), Total Daily Energy Expenditure with weight-loss/gain calorie targets, macronutrient splits (balanced, low-carb, high-protein, keto, endurance) with fibre, U.S. Navy body-fat percentage, ideal body weight across four classic formulas (Devine, Robinson, Miller, Hamwi), and daily water intake. Every endpoint accepts GET query parameters or a JSON POST body and works in both metric and imperial units. All computation is done locally with established public-domain equations, so responses are instant and the service is always available. Ideal for fitness trackers, nutrition apps, telehealth and wellness dashboards.

api.oanor.com/healthcalc-api