API marketplace

Sun-safety maths as an API, computed locally and deterministically — the burn-time, SPF and reapplication numbers a sunscreen, weather or outdoor app keeps people safe with. The burntime endpoint estimates how long until sunburn from the Fitzpatrick skin type (1 very fair to 6 deeply pigmented), the UV index and the SPF: unprotected time is a skin-type base (type II around 15 minutes) scaled by 6 ÷ UV index, and protected time is that times the SPF — so fair type-II skin at UV 8 burns in about 11 minutes bare, or roughly 5½ hours under SPF 30, while very fair type-I skin in extreme UV 11 burns in 5 minutes. The spf endpoint flips it: the SPF needed = your desired minutes outdoors ÷ the unprotected time, with the reminder that real protection plateaus around SPF 30–50. The amount endpoint covers the part people get wrong — about 2 mg/cm², roughly 1 ounce (30 g, a shot glass) for a full adult body, reapplied every two hours — and totals the sunscreen for a day out. Everything is computed locally and deterministically, so it is instant and private. Ideal for sun-safety, weather, skincare and outdoor app developers, UV-alert and reminder tools, and wellness software. Pure local computation — no key, no third-party service, instant. Educational estimates, not medical advice. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

76ms

Subs

4,957

Hammock-hang maths as an API, computed locally and deterministically — the suspension-force, ridgeline and strap-height numbers a camper or hammock hanger sets up by. It all comes back to the 30-degree rule. The force endpoint shows why: the tension in each suspension line is the occupant weight ÷ (2 × sin of the hang angle), so at a 30° hang each strap carries about one body weight, but flatten the hang to 15° and it jumps to roughly 1.9 times — which is what over-stresses straps, trees and your back when people pull a hammock drum-tight. The ridgeline endpoint sizes a structural ridgeline at about 83 % of the hammock length, the fixed line that reproduces that ~30° lay and the right sag on any pair of trees. The strapheight endpoint estimates how high to attach the straps from the distance between the trees and the seat height you want, since trees farther apart need higher anchor points to hold the angle. Everything is computed locally and deterministically, so it is instant and private. Ideal for camping, backpacking, outdoor-gear and hammock app developers, hang-calculator and trip-planning tools, and adventure software. Pure local computation — no key, no third-party service, instant. Weight and lengths in your own unit. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

74ms

Subs

4,324

Caulk and sealant coverage maths as an API, computed locally and deterministically — the linear-feet-per-tube and how-many-tubes numbers a builder, glazier or DIYer buys sealant by. A bead of caulk is essentially a thin cylinder, so the coverage endpoint works out the feet a cartridge lays from the bead width: volume per foot ≈ (π/4 × width²) × 12 inches, and a standard 10.1 fl oz cartridge (18.2 in³) lays about 30 feet of a quarter-inch bead, 13 feet of a fat three-eighths or 55 of a fine three-sixteenths — pass cartridge_oz for sausage packs or 28-oz tubes, and a tube count to total it. The tubes endpoint runs it backwards: cartridges needed = (joint length × a waste factor) ÷ feet per cartridge, rounded up, so a 100-foot run of quarter-inch bead with 10 % waste takes four tubes. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, glazing, weatherproofing and home-improvement app developers, material-estimator and shopping-list tools, and contractor software. Pure local computation — no key, no third-party service, instant. Inches and feet; estimates — tooling and waste vary. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

78ms

Subs

4,064

Party-balloon maths as an API, computed locally and deterministically — the helium-lift and balloon-count numbers a party planner or balloon artist decorates by. The helium endpoint gives a balloon’s lift from its inflated diameter: net lift is the inflated volume times the difference between air and helium density, about 1.046 grams per litre, so a fully inflated 11-inch latex balloon (around 11.4 litres) lifts roughly 12 grams gross and about 9 after its own weight, while a 36-inch giant lifts hundreds of grams. The float endpoint flips it around — how many balloons to float a payload = the weight divided by the net lift per balloon, rounded up, so a 50-gram card floats on six 11-inch balloons. The garland endpoint sizes an organic balloon garland or arch from its length: about 12 balloons per foot in a mix of sizes — roughly 40 % 5-inch, 45 % 11-inch and 15 % 16-inch for that full, textured look — so a 10-foot garland takes about 120 balloons, denser if you want it lush. Everything is computed locally and deterministically, so it is instant and private. Ideal for party-planning, event-decor, balloon-artist and celebration app developers, decor-estimator and shopping-list tools, and event software. Pure local computation — no key, no third-party service, instant. Inches and grams. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

76ms

Subs

3,107

Grain-bin storage maths as an API, computed locally and deterministically — the bushel and weight numbers a farmer or elevator sizes storage by. The bushels endpoint measures a round bin: floor area × grain depth gives the cubic feet, and a cubic foot holds about 0.8036 bushels, so an 18-foot bin filled 20 feet level holds roughly 4,090 bushels — and grain heaped to a peak adds a cone of (1/3) × floor area × peak height, so a 4-foot peak adds about 270 more. The weight endpoint converts bushels to weight by the crop’s standard test weight — corn and sorghum at 56 pounds a bushel, wheat and soybeans 60, oats 32, barley 48 — so those 4,090 bushels of corn weigh 229,040 pounds, about 114.5 US tons or 104 tonnes; pass a measured test weight for light or heavy grain. Everything is computed locally and deterministically, so it is instant and private. Ideal for agriculture, grain-elevator, farm-management and ag-tech app developers, storage-capacity and inventory tools, and harvest software. Pure local computation — no key, no third-party service, instant. US units (feet, bushels, pounds). Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

83ms

Subs

3,142

ADA wheelchair-ramp maths as an API, computed locally and deterministically — the run, landing and slope numbers a builder or accessibility planner sizes a ramp by. The rule the ADA fixes is 1 inch of rise per 12 of run, a maximum 8.33 % slope, so the ramp endpoint turns a rise into the ramp: run = rise × 12 (or × 16 / × 20 for a gentler grade if you have the room), plus the level landings the code requires — a 5-foot landing top and bottom and another between runs whenever the rise exceeds 30 inches — and the total length end to end, so a 24-inch rise needs a 24-foot run and 34 feet overall, while a 36-inch rise breaks into two runs with an intermediate landing for 51 feet. The fit endpoint answers the real-world question: does a ramp for this rise fit the run you have? It returns the minimum run an ADA 1:12 ramp needs, whether your space is enough, and the slope you would actually get if you forced it in — flagging when that exceeds 8.33 % and you need a switchback or a lower rise. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, accessibility, home-modification and contractor app developers, ramp-estimator and code-check tools, and building software. Pure local computation — no key, no third-party service, instant. Confirm against current ADA and local code. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

75ms

Subs

3,185

Farkle dice-scoring maths as an API, computed locally and deterministically — the points a Farkle (Zilch, Ten Thousand) scoring app tallies a roll by. The score endpoint takes up to six dice and returns the value by the common ruleset: a single 1 is 100 and a single 5 is 50; three of a kind scores the face times 100 (three 1s being the exception at 1000); four, five and six of a kind are 1000, 2000 and 3000; a 1-to-6 straight or three pairs is 1500; and two triplets is 2500 — so 1-1-1-5-5-5 scores 2500 as two triplets rather than 1100, a 1-2-3-4-5-6 straight is 1500, and 6-6-6-2-3 is 600 with the 2 and 3 dead. It flags a farkle when nothing scores (you lose the turn’s points) and tells you whether every die counted — a hot dice that lets you roll all six again. Rulesets vary, so it scores the widely-used set and says so. Everything is computed locally and deterministically, so it is instant and private. Ideal for dice-game, party-game and scoring app developers, score-helper and game-night tools, and board-game-companion software. Pure local computation — no key, no third-party service, instant. Scores a roll; it does not roll the dice. Live, nothing stored. 1 compute endpoint.

Uptime

100.0%

Latency

92ms

Subs

4,517

Cribbage hand-scoring maths as an API, computed locally and deterministically — the count a cribbage player, app or league tallies a hand by. The score endpoint takes the four-card hand and the starter (cut) card and returns the full breakdown by the rules: every distinct combination of cards summing to fifteen scores 2, each pair scores 2 (so three of a kind is 6 and four is 12), each run of three or more consecutive cards scores its length — counting the duplicate runs that pairs create — a four-card flush in the hand is 4 (five with the starter is 5, and the crib only scores a five-card flush), and his nobs, a Jack in hand matching the starter’s suit, is 1. It correctly scores the famous best hand, J-5-5-5 with a fifth 5 cut, at the maximum 29. The count endpoint tallies just fifteens, pairs and runs for any one to eight cards — useful for checking part of a hand or the pegging pile. Everything is computed locally and deterministically, so it is instant and private. Ideal for cribbage, card-game, board-game-companion and scoring app developers, score-verification and teaching tools, and game software. Pure local computation — no key, no third-party service, instant. Cards as rank+suit (5H, TD, JS). Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

76ms

Subs

3,978

Baking-pan maths as an API, computed locally and deterministically — the area and scale-factor numbers a baker resizes a recipe between pans with. The trick everyone gets wrong is that a recipe scales by the pan’s AREA, not its diameter, so a 10-inch round holds far more batter than a 9-inch. The area endpoint gives the surface area of any pan — round and springform as π/4·d², square as s², rectangle as length × width, and bundt or tube pans as the ring (the outer circle minus the centre hole) — so a 9-inch round is 63.6 in², an 8-inch square 64 and a 9×13 is 117; add a depth and it returns the volume in cubic inches and cups. The convert endpoint gives the scale factor to move a recipe from one pan to another, factor = target area ÷ source area: a 9-inch round to a 9×13 is ×1.84, and two 8-inch rounds really do equal one 9×13. Pass an ingredient amount and it scales it for you, with a note to keep the batter depth similar and adjust the bake time. Everything is computed locally and deterministically, so it is instant and private. Ideal for baking, recipe, meal-prep and kitchen app developers, recipe-scaling and substitution tools, and culinary software. Pure local computation — no key, no third-party service, instant. Inches. Live, nothing stored. 2 compute endpoints. For ingredient unit conversion use a cooking API.

Uptime

100.0%

Latency

84ms

Subs

4,995

Rotational-grazing maths as an API, computed locally and deterministically — the animal-unit, grazing-day and acreage numbers a rancher or homesteader moves a herd by. It all hangs on the animal unit: a 1000-pound cow eating about 26 pounds of dry matter a day. The animalunits endpoint converts a mixed herd to that common basis — a cow is 1.0 AU, a cow-calf pair 1.3, a horse 1.25, a sheep 0.2, a goat 0.17 — so ten cows and fifty sheep are 20 AU demanding 520 pounds of forage a day; pass a weight instead and it scales by weight ÷ 1000. The days endpoint works out how long a paddock lasts: grazing days = (acres × forage per acre × utilization) ÷ (animal units × 26), where the classic “take half, leave half” puts utilization near 50 %, so five acres yielding 3,000 lb at 50 % feeds 10 AU for about 29 days. The acres endpoint sizes the paddock the other way — acres = (AU × 26 × days) ÷ (forage × utilization) — so 20 AU for a 30-day move needs about 10.4 acres. Everything is computed locally and deterministically, so it is instant and private. Ideal for ranching, regenerative-agriculture, homesteading and farm-management app developers, paddock-planner and stocking-rate tools, and grazing-chart software. Pure local computation — no key, no third-party service, instant. US units; forage yield varies with season — measure it. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

75ms

Subs

4,306

Egg-incubation maths as an API, computed locally and deterministically — the hatch timeline, conditions and brooder numbers a hatchery or backyard chicken-keeper raises a clutch by. The hatch endpoint turns the set day (day 0) into the schedule by species: it knows the incubation period — chicken 21 days, duck 28, quail 17, goose 30, turkey 28, Muscovy 35 and more — and gives the lockdown day, about three days before hatch, when you stop turning the eggs, raise the humidity and leave the lid shut; pass a custom incubation_days for anything else. The conditions endpoint gives the targets: a forced-air incubator at 99.5 °F (still-air a degree or two higher at the top of the eggs), with humidity around 45–55 % through incubation and 65–75 % at lockdown so the membrane stays soft. The brooder endpoint schedules the chicks after they hatch — 95 °F under the lamp in week one, dropping 5 °F a week until they reach room temperature around 70 °F and are feathered enough to leave it. Everything is computed locally and deterministically, so it is instant and private. Ideal for poultry, hatchery, homesteading and farm app developers, incubation-timer and brooder tools, and 4-H / education software. Pure local computation — no key, no third-party service, instant. Guidance — candle the eggs and watch the chicks. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,453

Vegetable lacto-fermentation maths as an API, computed locally and deterministically — the salt numbers a fermenter weighs sauerkraut, kimchi and pickles by. (Vegetables, not meat — for cure and nitrite that is a separate calculation.) Salt is the whole game: too little and the wrong microbes win, too much and the ferment stalls. The salt endpoint does the dry-salt method for shredded veg, salt = vegetable weight × percent, with about 2 % being the classic sauerkraut and kimchi target — so a kilo of cabbage takes 20 grams — and it bands the result from low-and-fast to a near salt-cure. The brine endpoint sizes a submerged ferment, salt = water weight × percent where the percent is of the water as recipes state it (1 ml water ≈ 1 g), so a litre at 5 % needs 50 grams for a standard sour pickle, 3.5 % for a milder one; it also reports the salinity as a percent of the total solution. The salinity endpoint converts the two ways the same brine is expressed — percent of water versus percent of total — so a 5 %-of-water brine reads about 4.76 % on a refractometer. Everything is computed locally and deterministically, so it is instant and private. Ideal for fermentation, homesteading, recipe and food app developers, ferment-calculator and batch tools, and culinary software. Pure local computation — no key, no third-party service, instant. Grams and ml. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,771

Candy-making maths as an API, computed locally and deterministically — the sugar-syrup stage numbers a confectioner reads a thermometer by. As sugar syrup boils it passes through named stages, each a temperature window with its own texture and uses, and getting within a few degrees is the difference between fudge and toffee. The stage endpoint names the stage for a temperature: 238 °F is the soft-ball stage (fudge, fondant, pralines), 305 °F is hard-crack (toffee, brittle, lollipops), and it handles °F or °C and the off-the-chart cases — still a thin syrup below thread, or darkening to burnt past caramel. The range endpoint gives the temperature window and uses of a named stage, from thread (223–234 °F) through soft-ball, firm-ball, hard-ball, soft-crack and hard-crack to caramel (320–350 °F), in both °F and °C. The altitude endpoint applies the rule that matters in the mountains: cook to 1 °F lower for every 500 feet of elevation, since water boils cooler, so a 300 °F hard-crack recipe is done at 290 °F at 5,000 feet. Everything is computed locally and deterministically, so it is instant and private. Ideal for baking, confectionery, recipe and kitchen app developers, candy-thermometer and timer tools, and cooking-class software. Pure local computation — no key, no third-party service, instant. Use a calibrated thermometer. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

70ms

Subs

4,923

Window-tint maths as an API, computed locally and deterministically — the net VLT numbers an installer or car owner picks a film by. The catch with tint is that visible light transmission multiplies through layers: factory automotive glass already passes only about 70–80 % of light, so a film’s rated VLT is not what you end up with. The vlt endpoint multiplies it out — net % = the product of each layer’s VLT ÷ 100 — so a 35 % film on 78 % factory glass nets 27.3 %, a 5 % limo film on the same glass nets 3.9 %, and you can stack several layers in one call; it also describes how dark that looks, from near-clear down to blackout. The required endpoint runs it backwards: to land on a target net VLT through known glass you need a film of target ÷ glass × 100, so hitting a 35 % net on 78 % glass takes a 44.9 % film — and it flags the impossible case where the target is lighter than the bare glass already allows. Everything is computed locally and deterministically, so it is instant and private. Ideal for auto-tint, detailing, glass and automotive app developers, film-selection and compliance tools, and shop software. Pure local computation — no key, no third-party service, instant. Legal limits vary by jurisdiction — check local law. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,622

Yahtzee scoring maths as an API, computed locally and deterministically — the category scores and totals a dice-game scoring app runs on. (It scores a given roll; it does not roll the dice.) The score endpoint takes five dice and returns the value of every one of the thirteen boxes at once: the upper boxes (ones through sixes) score the sum of that number, three- and four-of-a-kind and chance score all five dice, a full house is 25, a small straight (four in a row) 30, a large straight (five in a row) 40 and a Yahtzee (five of a kind) 50 — so 3-3-3-5-6 is worth 20 in three-of-a-kind, 4-4-4-5-5 is a 25-point full house, and it flags the highest-scoring box for you. The total endpoint adds up a finished card: the 35-point upper-section bonus when the upper boxes reach 63 (and how many points you still need for it), plus 100 for each extra Yahtzee, to give the grand total. Everything is computed locally and deterministically, so it is instant and private. Ideal for dice-game, board-game-companion, family-game and scorekeeping app developers, score-sheet and tournament tools, and game software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. For random rolls use a dice API.

Uptime

100.0%

Latency

74ms

Subs

4,654

Two-stroke premix maths as an API, computed locally and deterministically — the gas-to-oil numbers anyone running a chainsaw, string trimmer, leaf blower, outboard, dirt bike or RC engine mixes fuel by. The mix endpoint gives the oil to add to a tank of fuel at a given ratio: oil = fuel ÷ ratio, so one US gallon at 50:1 needs about 75.7 ml (2.6 fl oz) of two-stroke oil, 40:1 about 94.6 ml (3.2 fl oz) and 32:1 about 118 ml (4.0 fl oz), and it returns the total mix and the oil percentage too, in litres, gallons, millilitres or fluid ounces. The ratio endpoint runs it the other way — measure the fuel and the oil you actually put in and it tells you the real N:1 ratio, the oil percentage and the nearest common ratio, so you can check a mix or reverse-engineer a pre-mixed can. Get it wrong and it matters: too little oil and the engine seizes, too much and it fouls plugs and smokes — so always use the ratio in your tool’s manual. Everything is computed locally and deterministically, so it is instant and private. Ideal for small-engine, outdoor-power-equipment, marine, powersports and DIY app developers, fuel-mixing and shop tools, and maintenance software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

80ms

Subs

4,659

Fretted-instrument lutherie maths as an API, computed locally and deterministically — the fret positions a guitar, bass, mandolin or ukulele builder slots a fingerboard to. This is instrument-building geometry, not music theory. The positions endpoint lays out a whole fingerboard from the scale length using the twelve-tone equal-temperament rule: the distance from the nut to fret n = scale length × (1 − 1 ÷ 2^(n/12)), so the 12th fret lands at exactly half the scale (the octave) and each gap shrinks by the constant ratio 2^(1/12) ≈ 1.0595 toward the bridge — a 25.5-inch Fender scale puts fret 1 at 1.431 inches and fret 12 at 12.75. The fret endpoint gives one fret’s distance from the nut, from the previous fret and to the bridge; the scalelength endpoint runs it backwards, recovering the scale length from a measured distance to a known fret (measure to the 12th and double it). It works in inches or millimetres — 25.5 Fender, 24.75 Gibson, 25.4 classical, 34 bass. Everything is computed locally and deterministically, so it is instant and private. Ideal for lutherie, guitar-building, instrument-design and maker app developers, fingerboard-slotting and fret-calculator tools, and CAD/CNC templates. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For note names or frequencies use a music-theory API.

Uptime

100.0%

Latency

75ms

Subs

4,721

Fuse-bead maths as an API, computed locally and deterministically — the bead-count, pegboard and colour numbers a Perler, Hama or melty-bead crafter plans a pixel design with. The grid endpoint turns a width × height pixel pattern into the real build: total beads = width × height, pegboards = ⌈width ÷ board⌉ × ⌈height ÷ board⌉ (a 29-peg square board for midi beads), and the finished size = beads × the bead pitch — so a 58 × 58 midi design is 3,364 beads, four pegboards and about 29 × 29 cm, in millimetres, centimetres and inches, with midi at 5 mm, mini at 2.6 mm and biggie at 9–10 mm. The palette endpoint splits the beads by colour: give it the total and a list of colour percentages and it returns the count per colour (normalised by the percent sum, so it works even when they don’t add to exactly 100) and the bags to buy at about a thousand beads each, or pass raw counts to bag them directly. Everything is computed locally and deterministically, so it is instant and private. Ideal for fuse-bead, pixel-art, kids-craft and maker app developers, pattern-to-shopping-list and project-estimator tools, and craft software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. For cross-stitch fabric counts use a different API.

Uptime

100.0%

Latency

83ms

Subs

3,942

Paracord-craft maths as an API, computed locally and deterministically — the cord-length numbers a paracord crafter cuts a project to. The bracelet endpoint sizes the cord from the finished length and the weave using the well-known rule of thumb — about a foot of cord per inch of work for a cobra (Solomon) bar, double that for a king cobra, less for a fishtail — so an 8-inch cobra bracelet takes around 9 feet of cord including a foot of waste for the tails; give it a wrist measurement instead and it adds the fit ease and the buckle to get the finished length first, so a 7-inch wrist comes out near 10 feet. The weave endpoint generalises it to any project — lanyards, belts, dog leashes — as cord = finished length × cord-per-inch × the number of working strands, with the weave factors built in or your own cord-per-inch, and answers in inches, feet and metres. Everything is computed locally and deterministically, so it is instant and private. Ideal for paracord, survival-gear, scouting, craft and maker app developers, project-estimator and cut-list tools, and DIY software. Pure local computation — no key, no third-party service, instant. Rules of thumb — cut long and trim. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

92ms

Subs

3,815

Chainmaille maths as an API, computed locally and deterministically — the aspect-ratio and ring numbers a maille artist weaves to. The aspect endpoint computes the all-important Aspect Ratio = inner diameter ÷ wire diameter, and solves for whichever of the three you are missing, then lists the weaves that ring will make: AR, not absolute size, decides everything — too low and the rings won’t close through each other, too high and the weave goes floppy, so a 6.4 mm ID on 1.6 mm wire is AR 4.0, good for European 4-in-1, Byzantine, box chain and more. The ring endpoint does the material maths: wire per ring ≈ π × (inner diameter + wire diameter) — the mean-diameter circumference — so those AR-4 rings take about 25 mm of wire each and weigh roughly 0.4 g in steel; pass a wire length to get how many rings it yields, or a ring count to get the total wire and weight, in any of nine metals from aluminium to silver. Everything is computed locally and deterministically, so it is instant and private. Ideal for chainmaille, jewelry, cosplay-armour and maker app developers, ring-buying and project-estimator tools, and craft software. Pure local computation — no key, no third-party service, instant. Dimensions in mm. Live, nothing stored. 2 compute endpoints. For wire-gauge ↔ mm use a wire-gauge API.

Uptime

100.0%

Latency

78ms

Subs

3,487

Tennis scoring maths as an API, computed locally and deterministically — the game, set and match logic a scoring app, umpire tool or tennis league runs on. The game endpoint plays a game from a sequence of who won each point and returns the proper tennis score: points run 0, 15, 30, 40 and then game, but at 40-40 it is Deuce and a player must lead by two — Advantage, then game — so a,a,a,a is 40-0 and a win, while three-all is Deuce; a tiebreak flag scores to seven by two instead (and keeps going at 7-7). The set endpoint reads a set from the games each player has won: a set is taken at six games with a two-game lead, 6-6 triggers a tiebreak that ends it 7-6, and 7-5 wins if a player pulls ahead first. The match endpoint settles the match from the sets won — best-of-three is decided by two sets, best-of-five by three — and tells you the winner the moment it is reached. Everything is computed locally and deterministically, so it is instant and private. Ideal for tennis, racket-sport, scoring, umpiring and league app developers, scoreboard and live-scoring tools, and club software. Pure local computation — no key, no third-party service, instant. Scoring logic, not analytics. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,736

Ten-pin bowling maths as an API, computed locally and deterministically — the scoring, handicap and average numbers a bowler, league or scoring app runs on. The score endpoint plays a full game from a comma list of the pins knocked down on each roll and applies the real rules: a strike scores 10 plus your next two rolls, a spare 10 plus the next one, an open frame just the pins, with the 10th frame’s bonus rolls handled — so twelve strikes is a perfect 300, twenty 9-then-miss frames are 90, and all spares with a 5 bonus is 150, returned frame by frame with the running total. The handicap endpoint levels a league: handicap per game = ⌊(basis − average) × percent⌋, never below zero, so a 150 average on the common 90 %-of-220 setup earns 63 pins a game and 189 over a three-game series. The average endpoint divides total pins by games (dropping the fraction, as leagues do), rolls in a new series to update it, and works out the pins you need over the next games to reach a target average. Everything is computed locally and deterministically, so it is instant and private. Ideal for bowling-league, scoring, sports and recreation app developers, scorekeeping and handicap tools, and centre-management software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,310

Scale-model maths as an API, computed locally and deterministically — the real-to-model conversions a modeller, model-railroader, wargamer or diorama-builder works in. The convert endpoint scales a dimension either way at any scale, given as a ratio (1:35), a number (87.1) or a name (Z, N, TT, HO, OO, S, O, G, 1/72, 1/48, 1/35, 1/24, 1/64, 1/43, 1/18): real → model divides by the ratio, model → real multiplies, so a 1:35 tank 6 metres long becomes 171 mm and an HO (1:87.1) boxcar 12.2 metres long becomes 140 mm, with the answer in mm, cm, m, inches and feet. The identify endpoint finds the scale from a real measurement and the model of it — scale = real ÷ model — and names the nearest standard scale with how far off it is, so you know whether figures and accessories will match. The scales endpoint lists the common named scales and compares any two, telling you that a 1:35 model is about 2.06 times the size of the same subject at 1:72. Everything is computed locally and deterministically, so it is instant and private. Ideal for scale-modelling, model-railroad, wargaming, diecast, architecture and diorama app developers, conversion and shopping tools, and hobby software. Pure local computation — no key, no third-party service, instant. Length in mm/cm/m/in/ft. Live, nothing stored. 3 compute endpoints. For typographic modular scales use a different API.

Uptime

100.0%

Latency

76ms

Subs

3,519

O-ring seal-design maths as an API, computed locally and deterministically — the squeeze, gland and stretch numbers an engineer or maker designs a seal to. The squeeze endpoint gives the compression that makes the seal: squeeze = (cross-section − gland depth) ÷ cross-section, so a 0.139-inch cord in a 0.113-inch deep groove is squeezed 18.7 %, and it grades the result — roughly 10–16 % suits dynamic (reciprocating) seals and 15–30 % static ones — and, given the groove width, the gland fill percentage, which should stay under about 85 % so the rubber has room to expand from heat or fluid swell. The gland endpoint works the other way: from the cross-section and whether the seal is static or dynamic (or a target squeeze) it returns the groove depth and a width sized for about 70 % fill — typically 1.3 to 1.5 times the cross-section — plus a corner radius. The stretch endpoint checks installation: stretch = (mating diameter − o-ring ID) ÷ ID, which should stay under about 5 % on a rod because stretching thins the cross-section and steals squeeze. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical-engineering, hydraulics, pneumatics, vacuum and product-design app developers, seal-selection and gland-design tools, and CAD plugins. Pure local computation — no key, no third-party service, instant. Inches or millimetres. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

79ms

Subs

3,608