API marketplace

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.

Uptime

100.0%

Latency

76ms

Subs

3,356

Cross-stitch and embroidery maths as an API, computed locally and deterministically — the design-size, fabric and floss numbers a cross-stitcher, embroidery designer or needlework-shop works a project out with. The design-size endpoint turns a stitch count and a fabric count (stitches per inch) into the finished size: size = stitch count ÷ fabric count, so a 140 × 98 design on 14-count Aida finishes at 10 × 7 inches (25.4 × 17.8 cm), smaller on 18-count and larger on 11-count because a higher count packs more stitches per inch — and it returns the total stitch count (width × height) that drives the floss and the hours. The fabric-needed endpoint adds a margin on every side to give the fabric to cut: design size + twice the margin per dimension, with the usual 3 inches per side for hooping, framing and finishing, so a 10 × 7 design wants a 16 × 13 inch cut. The thread-length endpoint estimates floss from the geometry of a full cross — the front two diagonals plus the back returns is about (2√2 + 2) ÷ fabric count inches per stitch — so 5,000 stitches on 14-count is roughly 1,724 inches, about 44 m, and it estimates the skeins given the number of strands (a 6-strand skein is ~8 m). Everything is computed locally and deterministically, so it is instant and private. Ideal for cross-stitch and embroidery pattern tools, needlework-shop and kit apps, and craft-project calculators. Pure local computation — no key, no third-party service, instant. Floss figures are planning estimates — buy a little extra and dye-lot match. 3 compute endpoints. For sewing yardage use a sewing API; for knitting gauge a knitting API.

Uptime

100.0%

Latency

77ms

Subs

4,435

Ice-cream and gelato batch maths as an API, computed locally and deterministically — the overrun, yield and solids numbers a gelatiere, ice-cream maker or production planner balances a mix by. The overrun endpoint measures the air whipped into the mix during freezing by the weight method: from the same container filled first with mix and then with frozen ice cream, overrun = (mix weight − frozen weight) ÷ frozen weight × 100 — a cup that drops from 1000 g to 625 g ran 60 % overrun. Dense gelato sits around 20–35 %, premium ice cream 25–50 %, soft-serve and economy tubs 50–100 %+; more air means a lighter, cheaper, faster-melting product. The yield endpoint turns a mix volume and an overrun into the frozen volume (mix × (1 + overrun/100)) and the number of scoops at a given scoop size, so 2 litres of mix at 60 % overrun yields 3.2 litres and about 53 sixty-millilitre scoops — which is why overrun is a direct cost lever. The total-solids endpoint balances a recipe: total solids (sugar + fat + milk-solids-not-fat + other) as a percent of the mix weight, with the fat, sugar, MSNF and water percentages — a typical ice cream runs 36–42 % total solids, gelato lower in fat, and balancing solids against water is what keeps the texture smooth rather than icy. Everything is computed locally and deterministically, so it is instant and private. Ideal for gelateria and creamery tools, recipe-balancing apps, and food-production calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For general cooking measure conversions use a cooking API.

Uptime

100.0%

Latency

75ms

Subs

4,166

Wood-moisture maths as an API, computed locally and deterministically — the moisture-content, oven-dry-weight and drying-target numbers a woodworker, sawyer, kiln operator or firewood seller weighs timber by. The moisture-content endpoint takes a wet weight and an oven-dry weight and returns the moisture content on both conventions: the dry basis (water ÷ oven-dry weight × 100, the forestry and woodworking standard) and the wet/green basis (water ÷ wet weight × 100, common in agriculture and paper) — a board weighing 120 g that dries to 100 g holds 20 g of water and is 20 % dry-basis or 16.7 % wet-basis, so it always matters which is quoted. Above fibre saturation (~28–30 %) the wood is still shedding free water and has not begun to shrink. The dry-weight endpoint back-calculates the unchanging oven-dry weight from a current weight and a meter reading (wet ÷ (1 + MC/100)), the anchor for any drying plan because the wood substance does not change as water leaves. The target-weight endpoint uses that anchor to give the weight a piece should reach for a target moisture content and the water still to drive off — taking 120 g at 20 % down to 12 % means a 112 g target and 8 g of water to lose, so you simply weigh the piece down to that figure. Everything is computed locally and deterministically, so it is instant and private. Ideal for woodworking and lutherie tools, sawmill and kiln-drying apps, and firewood-seasoning calculators. Pure local computation — no key, no third-party service, instant. Mass-balance maths — pair it with a real moisture meter. 3 compute endpoints. For board feet use a lumber API; for a wood-stack volume a firewood API.

Uptime

100.0%

Latency

78ms

Subs

4,875

Gemstone weight maths as an API, computed locally and deterministically — the carat, gram, point and measured-weight numbers a jeweller, gem dealer, appraiser or lapidary works to. The carat-to-grams endpoint converts a carat weight to grams, milligrams and points: the metric carat is exactly 0.2 g (200 mg) and is split into 100 points, so a 1.5 ct stone is 0.3 g and 150 points and a quarter-carat is a twenty-five pointer — the carat is a mass unit, not a size, so a 1 ct diamond and a 1 ct emerald weigh the same but look different because their densities differ. The grams-to-carat endpoint inverts it (divide grams by 0.2, or multiply by 5), for a weight taken on a gram balance. The round-brilliant-weight endpoint gives the trade estimate used when a stone is set and cannot be put on a scale: carat ≈ diameter² × depth × 0.0061, with the girdle diameter and total depth in millimetres — a 6.5 mm round about 4 mm deep estimates near 1 carat, which is exactly why a 1 ct round brilliant measures roughly 6.5 mm across; the factor can be nudged for a thick girdle or a different cut. Everything is computed locally and deterministically, so it is instant and private. Ideal for jewellery and appraisal tools, gem-dealer and auction apps, and lapidary calculators. Pure local computation — no key, no third-party service, instant. Weight maths only — it does not price the stone or grade the colour and clarity. 3 compute endpoints. For gold karat and fineness use a gold-purity API.

Uptime

100.0%

Latency

79ms

Subs

3,955

Gold purity and karat maths as an API, computed locally and deterministically — the karat, fineness and alloy numbers a jeweller, goldsmith, assayer or refiner works to. The karat-to-fineness endpoint converts between the two purity systems: karat is the number of 24ths of a piece that is pure gold, so the fineness (parts per thousand, the figure on a hallmark stamp) = karat ÷ 24 × 1000 and the gold percentage = karat ÷ 24 × 100 — 24K is pure (1000‰), 18K is 750‰ (75 %), 14K is 583‰, 9K is 375‰. The pure-gold-weight endpoint gives the actual fine gold in a piece = its total weight × the gold fraction (karat ÷ 24): a 10 g 18K ring holds 7.5 g of gold and 2.5 g of alloy, the fine-gold content a refiner pays on and the basis of the intrinsic metal value. The alloy-mix endpoint inverts it for the bench: to bring refined fine gold down to a target karat, the total weight = the fine gold ÷ (target karat ÷ 24) and the alloy to add = the total − the fine gold, so 7.5 g of pure gold makes 10 g of 18K with 2.5 g of master alloy. Everything is computed locally and deterministically, so it is instant and private. Ideal for jewellery and goldsmithing tools, pawn and scrap-gold apps, and assay and metal-value calculators. Pure local computation — no key, no third-party service, instant. Purity maths only — it does not fetch the live gold price. 3 compute endpoints. For a metal part's weight from its dimensions use a metal-weight API.

Uptime

100.0%

Latency

75ms

Subs

3,617

Circular-segment arch geometry as an API, computed locally and deterministically — the radius, arc-length and set-out numbers a mason, joiner, stonemason or CAD user lays a segmental arch out with. A segmental arch is an arc of a circle struck through the two springings and the crown: the from-span-rise endpoint takes the span and the rise (the height of the crown above the springing line) and returns the radius = (span²/4 + rise²) ÷ (2·rise), the central angle it subtends, the arc length along the curve, and the segment area of the void below it — flatter arches with a small rise have surprisingly huge radii. The from-radius-angle endpoint inverts it, returning the chord (span), the rise (sagitta), the arc length and the area from a known radius and central angle, the way a curve struck with a trammel or a router on a pivot is described. The setout-ordinates endpoint gives the practical numbers to mark a template: the rise of the arc above a straight base line at equally spaced stations across the span (y = √(R² − x²) − (R − rise)), so you can plot the heights, connect them and cut a plywood former or bend a batten without a giant compass — the ends come out zero at the springings and the middle equals the rise at the crown. Everything is computed locally and deterministically, so it is instant and private. Ideal for masonry and joinery layout tools, stair and window-head design, and CAD and woodworking calculators. Pure local computation — no key, no third-party service, instant. Segmental (up to a semicircle) arcs. 3 compute endpoints. For road curves use a horizontal- or vertical-curve API; for plain shape areas a geometry API.

Uptime

100.0%

Latency

78ms

Subs

4,123

Riveted-joint strength maths as an API, computed locally and deterministically — the shear, bearing and rivet-count numbers a structural, sheet-metal or aircraft fitter checks a riveted connection by. The shear-capacity endpoint gives the load a rivet group carries across its shanks = the rivet area (π/4·d²) × the shear strength × the number of rivets × the shear planes — a rivet in single shear is cut on one plane, in double shear (the centre plate of a butt joint with cover plates) on two, so it carries twice. The bearing-capacity endpoint gives the load the rivets can press against the sides of their holes before the plate crushes = the projected contact area (diameter × plate thickness) × the bearing strength × the number of rivets; thin plates fail in bearing long before the rivet shears, which is exactly why both must be checked — the joint strength is the lesser of the two. The rivets-required endpoint inverts it: the rivets a design load needs = the load ÷ the allowable load per rivet (area × allowable shear × planes), rounded up to a whole rivet, using the working shear (strength ÷ safety factor) not the raw value. Everything is computed locally and deterministically, so it is instant and private. Ideal for structural and sheet-metal estimating, mechanical-design and fastener tools, and engineering calculators. Pure local computation — no key, no third-party service, instant. Shank-shear and bearing only — also confirm edge tear-out and minimum pitch. 3 compute endpoints. For bolt preload and torque use a bolt-torque API; for thread geometry a thread API; for welded joints a welding API.

Uptime

100.0%

Latency

78ms

Subs

4,075

Tensioned-line point-load statics as an API, computed locally and deterministically — the line-tension and anchor-force numbers a slackliner, highliner or rigger works out before they weight a line. This is the V a loaded line makes under a person, not a self-weight catenary: the tension endpoint takes the span, the sag and the body load and returns the line tension and the horizontal anchor pull, because vertical balance is 2·T·sin(angle) = the body weight — so the flatter the line (the smaller the sag) the more the tension blows up, which is exactly why drum-tightening a line to kill the bounce can load the anchors to many times body weight. The sag endpoint inverts it: from a known line tension it returns the sag a mid-span load settles to (sin angle = weight ÷ twice the tension), and flags when the tension is too low to hold the load at all. The off-centre-load endpoint handles standing away from the middle, where the two halves carry different tensions: the horizontal pull is equal on both sides (H = weight × a × b ÷ (sag × span)) but the shorter, steeper segment runs at the higher tension and fails first — the reason a highliner near an anchor stresses that leash harder than one in the centre. Everything is computed locally and deterministically, so it is instant and private. Ideal for slackline and highline rigging tools, climbing and outdoor-gear apps, and tension-and-anchor calculators. Pure local computation — no key, no third-party service, instant. Geometric statics — combine with the real webbing and anchor ratings. 3 compute endpoints. For a self-weight hanging cable use a catenary API; for working-load-limit and safety factor a rigging API.

Uptime

100.0%

Latency

68ms

Subs

3,192

Textile-dyeing recipe maths as an API, computed locally and deterministically — the dye, water and auxiliary numbers a dyer weighs out to mix a repeatable dye-bath, whether for a swatch or a full bolt. The dye-weight endpoint gives the dye to weigh = the weight of fabric × the depth of shade, the percentage of dye on the weight of the goods: a 2 % shade on 100 g of fabric is 2 g of dye, pale shades run under half a percent, deep blacks 4 % or more — working on-weight-of-fabric is exactly what makes a recipe scale and repeat. The liquor-ratio endpoint gives the dye-bath volume = the weight of goods in kilos × the liquor ratio, the litres of bath per kilo (a 20:1 ratio is 20 L per kg); lower ratios save water, dye and energy and exhaust deeper, higher ratios level more evenly on delicate or pale work. The auxiliary endpoint gives the salt, soda ash or levelling agent to add = the bath volume × the dosing concentration in grams per litre — salt (50–80 g/L) drives reactive and direct dyes onto cotton, soda ash (10–20 g/L) raises the pH to fix them. Everything is on-weight or per-litre, so the same recipe gives the same colour and chemistry at any scale, and it is computed locally and deterministically, so it is instant and private. Ideal for craft and studio dyers, textile and yarn shops, and dye-recipe and batch-calculator tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For knitting yardage and gauge use a knitting API; for vegetable-ferment or meat-cure salt a fermentation or curing API.

Uptime

100.0%

Latency

77ms

Subs

4,009

Solar-array row-spacing and shading geometry as an API, computed locally and deterministically — the shadow-length, inter-row-spacing and ground-coverage numbers a PV designer or installer lays a ground-mount or flat-roof array out with. The shadow-length endpoint gives the shadow an object casts = its height ÷ tan(sun elevation), longer the lower the sun (which is why layouts are designed for the worst-case winter-solstice low sun), stretched by 1/cos(azimuth difference) when the sun is off-axis. The row-spacing endpoint gives the minimum row pitch (front edge to front edge) to stop a row shading the one behind = the module's horizontal base (length × cos tilt) + the shadow its back edge casts (module height ÷ tan of the minimum sun elevation) — a 1.7 m module at 30° tilt clearing a 20° winter sun needs about a 3.8 m pitch — and returns the resulting ground coverage ratio. The ground-coverage endpoint gives that GCR = module length ÷ row pitch, the packing density: fixed-tilt fields typically run 0.4–0.5, higher packs more kW per acre but loses winter yield to mutual shading, lower wastes land. Everything is computed locally and deterministically, so it is instant and private. Ideal for solar-design and layout tools, EPC and site-assessment apps, and renewable-energy calculators. Pure local computation — no key, no third-party service, instant. Geometric model — use the real worst-hour sun altitude. 3 compute endpoints. For solar position/altitude use a solar-position API; for irradiance a solar API; for off-grid sizing an off-grid API.

Uptime

100.0%

Latency

79ms

Subs

3,276

Winch and cable-drum maths as an API, computed locally and deterministically — the rope-capacity, line-pull and rope-out numbers a winch operator, rigger or recovery driver works a drum with. The capacity endpoint gives the rope a drum holds by exact layer geometry: the sum over every full layer of the turns per layer × π × that layer's mean wrap diameter, where turns per layer = drum width ÷ rope diameter and the number of layers = the flange-to-barrel depth ÷ rope diameter — a 10-inch barrel, 20-inch flange, 12-inch-wide drum on half-inch rope holds about 940 ft over 10 layers. The layer-pull endpoint shows why pull falls as the drum fills: the rated pull is for the bare-drum first layer, and as rope piles on, the growing lever arm cuts the line pull and raises the line speed in the same ratio — pull × (first-layer diameter ÷ this layer's diameter) — so the top layer of a deep drum can pull barely half the bottom-layer rating, which is why you spool off to bare drum for a hard pull or add a snatch block. The length-at-layer endpoint gives the rope wound after a number of full layers, for marking the rope or knowing how much line is out. Everything is computed locally and deterministically, so it is instant and private. Ideal for winch- and hoist-sizing tools, recovery and off-road apps, marine and industrial-rigging utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Geometric estimate — allow for nesting and freeboard. 3 compute endpoints. For capstan friction use a capstan API; for block-and-tackle a pulley API.

Uptime

100.0%

Latency

76ms

Subs

4,761

Mobile-crane lift-planning maths as an API, computed locally and deterministically — the load-moment, tipping-capacity and outrigger-pad numbers a crane operator, lift planner or rigging engineer checks a pick with. The load-moment endpoint gives the load × its working radius (the horizontal distance from the slew centre to the hook), the single figure a crane's rated-capacity limiter watches: a 5-tonne load at 8 m is a 40 tonne-metre moment, the same as 10 tonnes at 4 m, which is why chart capacity falls steeply as the boom luffs out — moment, not weight, tips the crane. The capacity endpoint gives a simplified tipping balance about the fulcrum: the load that just tips = counterweight × its radius ÷ the load radius, and the rated safe load is a stability fraction of that (~75 % on outriggers, ~66 % on crawlers per the standards) — a teaching/sanity figure that ignores the boom and superstructure, never a substitute for the load chart. The outrigger-pad endpoint sizes the float: required pad area = the outrigger leg load ÷ the soil's allowable bearing pressure (and the side of a square mat), since overloading weak ground is a leading cause of overturns — a 30-tonne leg on 200 kPa wants about a 1.2 m square mat. Everything is computed locally and deterministically, so it is instant and private. Ideal for lift-planning and rigging tools, construction and crane-operations apps, and site-safety utilities. Pure local computation — no key, no third-party service, instant. Simplified — always use the manufacturer load chart. 3 compute endpoints. For sling and WLL loads use a rigging API.

Uptime

100.0%

Latency

79ms

Subs

4,593

Traction-elevator engineering maths as an API, computed locally and deterministically — the counterweight, hoist-motor and rope-traction numbers a lift engineer or building-services designer sizes a passenger elevator with. The counterweight endpoint gives the balancing mass = the empty car plus a fraction of the rated load (the overbalance, typically 40–50 %, 45 % common), so a 1,000 kg car rated for 1,000 kg uses a 1,450 kg counterweight — the car and weight balance near half load and the machine is sized for the worst-case imbalance, not the full load. The motor-power endpoint uses that: because the counterweight cancels most of the car, the motor only lifts the out-of-balance load = rated load × (1 − overbalance), so power = that × g × speed ÷ efficiency (~65–75 % geared) — a 1,000 kg lift at 1.5 m/s needs only about 11–12 kW, half what a counterweight-less hoist would draw. The traction-ratio endpoint checks the friction grip: a traction elevator moves the ropes by friction over the sheave, so the available traction (e^(μθ), the capstan equation) must beat the T1/T2 tension ratio at both worst cases — a full car at the bottom and an empty car at the top — and it returns the governing ratio. Everything is computed locally and deterministically, so it is instant and private. Ideal for lift-design and building-services tools, vertical-transport and MEP utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Sizing estimates — follow the lift code and maker data. 3 compute endpoints. For block-and-tackle use a pulley API; for capstan friction a capstan API.

Uptime

100.0%

Latency

78ms

Subs

3,189

Railway train-performance maths as an API, computed locally and deterministically — the tractive-effort, resistance and adhesion numbers a railway engineer, train planner or rail-sim developer rates motive power with. The tractive-effort endpoint gives the pulling force a locomotive develops = 375 × horsepower × efficiency ÷ speed (mph), the classic hyperbolic curve where a constant-power loco pulls hardest at low speed and tapers as it accelerates — 4,000 hp at 25 mph and 82 % efficiency is about 49,200 lbf at the rail. The resistance endpoint gives the forces a train fights: grade resistance ≈ 20 lb per ton per 1 % of grade (the weight component along the slope, the dominant force on a hill — a 5,000-ton train on a 1 % grade fights 100,000 lbf) plus curve resistance ≈ 0.8 lb per ton per degree of curve from flange friction. The adhesion endpoint gives the hard ceiling: however much power a loco has, it can only pull as hard as the wheels grip — maximum starting tractive effort = the adhesion coefficient (≈ 0.25 dry, more with sand) × the weight on the driving wheels, so 200 tons on the drivers is about 100,000 lbf before slip. Everything is computed locally and deterministically, so it is instant and private. Ideal for rail-operations and motive-power planning tools, train-simulator and railfan apps, and transport-engineering utilities. Pure local computation — no key, no third-party service, instant. Excludes the speed-dependent Davis rolling/air resistance. 3 compute endpoints. For highway curve geometry use a horizontal-curve API.

Uptime

100.0%

Latency

75ms

Subs

3,272

Sea-horizon and visibility maths as an API, computed locally and deterministically — the distance-to-horizon, geographic-range and dip numbers a mariner, coastal navigator or marine app works sightings with. The horizon endpoint gives the distance to the sea horizon ≈ 1.169·√(height of eye in feet) nautical miles, including the standard atmospheric refraction that bends the line of sight a little past the geometric edge — at 9 ft of eye height the horizon is about 3.5 nm off — together with the dip, how far below true horizontal that watery edge lies (≈ 0.97′·√h), the correction subtracted from a sextant altitude shot to the sea horizon. The geographic-range endpoint gives how far off a light or landmark first peeps over the horizon = the sum of two horizon distances, your own plus the object's: 1.169·(√h_eye + √h_object), so a 100 ft lighthouse from a 9 ft cockpit lifts above the sea at about 15 nm — purely geometric, before the light's own luminous range and the visibility. The object-height endpoint inverts it: how tall a tower, light or headland must stand to break the horizon at a target range, or how close you must be before a known landmark appears. Everything is computed locally and deterministically, so it is instant and private. Ideal for marine-navigation and chartplotter apps, coastal-pilotage and lighthouse tools, and sailing utilities. Pure local computation — no key, no third-party service, instant. Geometric/refraction model. 3 compute endpoints. For great-circle distance use a geo-distance API; for set & drift a set-and-drift API.

Uptime

100.0%

Latency

85ms

Subs

3,283

Current-sailing (set and drift) navigation maths as an API, computed locally and deterministically — the course-over-ground, course-to-steer and current numbers a mariner, navigator or marine app plots a passage with. The course-made-good endpoint adds the boat's velocity through the water to the current vector to give the real track: the course over ground (COG) and speed over ground (SOG), with the drift angle the current pushes you off your nose — steering 090° through the water at 10 knots with a 2-knot current setting north comes out around 079° over the ground at 10.2 knots. The course-to-steer endpoint solves the other way: the heading to steer to make good a desired ground track, steering up-current to cancel the across-track set (sin(H−T) = −drift·sin(set−track) ÷ speed), and the resulting SOG — usually slower into a current, faster with it astern, and impossible if the current across the track beats your speed. The current endpoint finds the set and drift from the offset between a dead-reckoning position and an observed fix: the set is the bearing DR-to-fix and the drift is that distance ÷ the elapsed time, ready to carry forward. Everything is computed locally and deterministically, so it is instant and private. Ideal for marine-navigation and chartplotter apps, sailing and boating tools, and maritime-training utilities. Pure local computation — no key, no third-party service, instant. Degrees true. 3 compute endpoints. For great-circle distance use a geo-distance API; for tide times a tides API.

Uptime

100.0%

Latency

79ms

Subs

4,178

Hay and forage bale maths as an API, computed locally and deterministically — the weight, dry-matter and feed-supply numbers a rancher, hay producer or livestock manager plans winter feed with. The round-bale endpoint gives the weight from the cylinder volume (π·r²·width) × the dry-matter density (typically ~9–12 lb/ft³ for cured hay), so a 5×5 ft bale runs about 1,000 lb, and reports the dry-matter weight (≈88 % of as-fed) that actually feeds the animals — buy and ration on dry matter, not gate weight. The square-bale endpoint gives the weight of a rectangular bale from its length, width and height (÷ 1,728 for cubic feet from inches) × the density — a typical 14×18×36-inch small square is about 50 lb, big 3×3 or 4×4 ft bales hundreds — with a reminder that high moisture both adds weight and risks mould and barn-fire heating. The feed-supply endpoint sizes the stack: feed needed = head × daily intake × days (cattle eat ~2–2.5 % of bodyweight, about 25–30 lb of dry matter for a beef cow), and bales = that ÷ the bale weight, so 30 cows for 120 days at 30 lb is about 108 thousand-pound bales — add 10–20 % for feeding waste. Everything is computed locally and deterministically, so it is instant and private. Ideal for ranch- and farm-management tools, hay-trading and livestock apps, and ag calculators. Pure local computation — no key, no third-party service, instant. US units; densities are estimates. 3 compute endpoints. For grain storage use a grain-bin API; for rotational grazing a grazing API.

Uptime

100.0%

Latency

75ms

Subs

3,845

Planting seed-rate maths as an API, computed locally and deterministically — the plant-population, seed-spacing and seeding-rate numbers a farmer, agronomist or precision-ag tool sets a planter or drill to. The population endpoint gives the plants per acre = 6,272,640 ÷ (row spacing × in-row seed spacing) in inches (the 6,272,640 is the square inches in an acre), so 30-inch rows with seeds 6 inches apart give about 34,800 plants per acre — closer spacing raises the population and the competition. The seed-spacing endpoint runs it the other way: the in-row spacing for a target population = 6,272,640 ÷ (target plants × row spacing), so 35,000 plants per acre in 30-inch rows means a seed about every 6 inches, the value to set on a singulating meter or seed-rate drive. The seeding-rate endpoint gives the pounds of seed per acre = the target population ÷ the germination rate ÷ the seeds per pound, over-seeding for the seeds that never come up — 35,000 plants of a 1,500-seeds-per-lb crop at 95 % germination needs about 24.6 lb/acre, working from the seed lot's own tag. Everything is computed locally and deterministically, so it is instant and private. Ideal for precision-ag and farm-management tools, planter-calibration and agronomy apps, and seed-retail utilities. Pure local computation — no key, no third-party service, instant. US units. 3 compute endpoints. For sprayer rates use a spray API; for fertiliser a fertilizer API.

Uptime

100.0%

Latency

76ms

Subs

4,531

Agricultural sprayer maths as an API, computed locally and deterministically — the calibration, coverage and tank-mix numbers a farmer, agronomist or custom applicator dials a boom sprayer in with. The calibration endpoint gives the broadcast application rate GPA = 5940 × the per-nozzle flow (GPM) ÷ (ground speed in mph × nozzle spacing in inches), the 5940 converting the units for a full-coverage boom — so a 0.4 GPM nozzle at 5 mph on 20-inch spacing lays down about 24 gallons per acre, and driving faster or spacing nozzles wider drops the rate. The coverage endpoint gives the acres a tank covers (tank ÷ GPA) and, for a field size, the total spray volume and the number of tank-loads, with the partial last fill called out so it can be mixed to the leftover acres. The product endpoint gives the pesticide or nutrient to add per tank = the acres a tank covers × the label rate per acre (in whatever unit the rate uses — ounces, pints, pounds), plus the total product for the field. Everything is computed locally and deterministically, so it is instant and private. Ideal for precision-ag and farm-management tools, sprayer-calibration and tank-mix apps, and ag-retail utilities. Pure local computation — no key, no third-party service, instant. Always follow the product label and calibrate with a real catch test. 3 compute endpoints. For fertiliser rates use a fertilizer API; for sprinkler/irrigation design an irrigation API.

Uptime

100.0%

Latency

75ms

Subs

3,615

RTD (resistance-temperature-detector) sensor maths as an API, computed locally and deterministically with the IEC 60751 Callendar–Van Dusen equation — the resistance, temperature and tolerance numbers an instrumentation or controls engineer reads a Pt100 or Pt1000 with. The resistance endpoint gives the sensor resistance from temperature: above 0 °C, R = R₀·(1 + A·T + B·T²) with A = 3.9083×10⁻³ and B = −5.775×10⁻⁷; below 0 °C a third term adds C·(T−100)·T³ — a standard Pt100 (100 Ω at 0 °C) reads 138.51 Ω at 100 °C and 80.31 Ω at −50 °C, and a Pt1000 is ten times that. The temperature endpoint inverts it to turn a measured resistance back into temperature — analytically above 0 °C, iteratively below — exactly what a transmitter does with the bridge reading, and a reminder that a 3- or 4-wire connection cancels the lead-wire resistance so it does not read as extra degrees. The tolerance endpoint gives the IEC 60751 accuracy band in both °C and Ω by class — AA ±(0.10 + 0.0017·|T|), A ±(0.15 + 0.002·|T|), B ±(0.30 + 0.005·|T|), C ±(0.60 + 0.010·|T|) — the error growing with distance from 0 °C. Everything is computed locally and deterministically, so it is instant and private. Ideal for instrumentation and controls software, data-logger and transmitter firmware, calibration and industrial-IoT tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For NTC thermistors use a thermistor API; for thermocouples a thermocouple API.

Uptime

100.0%

Latency

77ms

Subs

4,661

Sauna-heater sizing maths as an API, computed locally and deterministically — the heater-power, stone-mass and electrical numbers a sauna builder, installer or wellness retailer sizes a cabin with. The heater-size endpoint gives the power: about 1 kW per 1.3 m³ of well-insulated cabin (room volume ÷ 1.3), with cold surfaces the heater must also warm — a glass door or wall, bare stone, tile or uninsulated timber — adding roughly 1.2 m³ of equivalent volume per square metre, so a 10 m³ room with a 2 m² glass door wants about a 10 kW heater, rounded up to the next standard size. The stones endpoint gives the recommended sauna-stone mass, roughly 10–20 kg per kW (more stones for a softer, steamier löyly, fewer for a faster warm-up), with a note to use proper peridotite/olivine stones stacked loosely. The electrical endpoint gives the current the resistive heater draws — power ÷ voltage for single-phase or ÷ (√3 × voltage) for three-phase, since most heaters above ~4 kW are wired three-phase to keep the per-leg current and cable size down — to size the breaker and the dedicated RCD-protected circuit. Everything is computed locally and deterministically, so it is instant and private. Ideal for sauna and wellness retailers, home-improvement and DIY tools, and HVAC/electrical estimating apps. Pure local computation — no key, no third-party service, instant. Estimates — follow the heater maker's chart and local wiring code. 3 compute endpoints. For steam-boiler maths use a boiler API; for room heat loss a U-value API.

Uptime

100.0%

Latency

70ms

Subs

4,237

Hot-air-balloon lift maths as an API, computed locally and deterministically — the thermal-lift, envelope-temperature and air-density numbers a balloon pilot, designer or physics teacher works a flight out with. The lift endpoint gives the buoyant lift from heating the air: gross lift = envelope volume × (outside air density − inside air density), the densities from the ideal-gas law — a 2,500 m³ envelope at 100 °C on a 15 °C day lifts about 698 kg gross, from which you subtract the envelope, basket, burner and fuel for the payload, and the hotter the air and colder the day the more it lifts. The required-temp endpoint inverts it: to carry a target lift the inside air must reach a particular density and so a particular temperature, with a check that it stays under the ~120 °C that nylon envelopes can take — the everyday pre-flight question of whether the balloon can lift today's crew and fuel. The air-density endpoint gives the moist-air density ρ = (P − 0.378·Pv) ÷ (R·T), and explains the counter-intuitive fact that humid air is LESS dense than dry air, slightly cutting the lift. Everything is computed locally and deterministically, so it is instant and private. Ideal for ballooning and aviation tools, STEM and physics-education apps, and buoyancy calculators. Pure local computation — no key, no third-party service, instant. Idealised dry-lift model. 3 compute endpoints. For Archimedes flotation in water use a buoyancy API; for party-balloon helium lift a balloon API.

Uptime

100.0%

Latency

80ms

Subs

4,252

Water-hammer (hydraulic-transient) maths as an API, computed locally and deterministically — the surge-pressure, wave-speed and valve-timing numbers a piping or plumbing engineer guards a system with. The surge endpoint applies the Joukowsky equation Δp = ρ · a · Δv: a sudden stop of the flow spikes the pressure by the fluid density × the pressure-wave speed × the velocity change — stopping 2 m/s of water at a ≈ 1200 m/s adds about 24 bar (348 psi), far above the line pressure, which is what bangs the pipes and can split fittings. The wave-speed endpoint gives that pressure-wave speed: a = √(K/ρ) in a rigid pipe (≈ 1,480 m/s for water), slowed in a real elastic pipe to √(K/ρ) ÷ √(1 + (K·D)/(E·t)) — a thin or plastic pipe gives a lower wave speed and a gentler surge, which is why PVC tolerates hammer better than steel. The critical-time endpoint gives 2L/a, the round-trip time of the wave: close a valve faster than this and you get the full Joukowsky surge, slower and the returning relief wave eats into it, so sizing closure times (or fitting a surge tank or air chamber) above the critical time is the standard cure. Everything is computed locally and deterministically, so it is instant and private. Ideal for piping- and plumbing-design tools, pump-station and pipeline-surge analysis, and hydraulic-engineering utilities. Pure local computation — no key, no third-party service, instant. Idealised single-pipe transient. 3 compute endpoints. For steady pipe pressure drop use a Darcy API; for pump head and affinity a pump API.

Uptime

100.0%

Latency

76ms

Subs

3,906