API marketplace

Planted-aquarium and aquascaping maths as an API, computed locally and deterministically — the dosing and water numbers a high-tech planted tank runs on, not the rolls of a dice. The co2 endpoint gives the dissolved CO2 concentration from pH and carbonate hardness using the classic relationship CO2 (ppm) ≈ 3 × KH (dKH) × 10^(7 − pH), and flags it against the 15–30 ppm window plants want — at pH 6.6 and KH 4 you are at about 30 ppm, the top of the safe zone, while pH 7.0 and KH 3 is a carbon-limited 9 ppm. The fertilizer endpoint turns a dry-salt dose into the nutrient ppm it adds, the heart of Estimative Index dosing: ppm = grams × the nutrient mass fraction × 1000 ÷ tank litres, so 1 g of KNO3 in 100 litres adds 6.1 ppm nitrate and 3.9 ppm potassium, and it knows KNO3, KH2PO4, K2SO4, MgSO4 (Epsom) and Ca(NO3)2. The substrate endpoint sizes the substrate from the footprint and target depth — a 60 × 30 cm tank at 6 cm deep needs 10.8 litres, two 9-litre aquasoil bags. Everything is computed locally and deterministically, so it is instant and private. Ideal for aquascaping and planted-tank apps, fertiliser-dosing calculators, CO2-rig tools, and aquarium-shop and hobby sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For a tank water volume or fish stocking use an aquarium API; for pool chemistry use a pool API.

Uptime

100.0%

Latency

176ms

Subs

4,068

Reptile-husbandry maths as an API, computed locally and deterministically — the keeper numbers behind a healthy vivarium, so the setup is right before the animal moves in. The enclosure endpoint turns an animal length and its habit into the minimum floor length, width and height: terrestrial snakes want a floor at least as long as the snake (a 48-inch corn snake → a 48 × 24 × 24 inch minimum, eight square feet of floor), arboreal species trade floor for height (an 18-inch chameleon → 27 × 18 × 36 inches, tall), and ground lizards and tortoises need far more floor than their body length. The uvb endpoint gives the UV-B target by Ferguson zone — the 1-to-4 classification from Baines et al. (2016) of how much sun a species basks in — returning the mean and basking UV-index ranges (zone 3 open baskers want a basking UVI of 2.9–7.4), and, if you pass a lamp UVI measured at a reference distance, an inverse-square estimate of the mounting distance for the right basking UVI. The feeding endpoint sizes prey from body weight and life stage: a meal of roughly 10–15 % of body weight, no wider than the animal, on an interval that lengthens with age — a 500 g adult snake takes a 40–60 g prey item every fortnight. Everything is computed locally and deterministically, so it is instant and private. Ideal for reptile-keeper and herpetoculture apps, pet-store and breeder tools, vivarium-planning calculators, and care-sheet sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational husbandry estimates — not veterinary advice; research your exact species.

Uptime

100.0%

Latency

150ms

Subs

4,307

Garden and koi-pond maths as an API, computed locally and deterministically — the numbers behind a backyard water feature, so you do not have to guess at the hose. The volume endpoint turns length, width and average depth into the water volume in cubic feet, US gallons and litres, applying a shape factor (rectangular 1.0, oval or round 0.79, irregular 0.85) because a liner pond never holds the full bounding box: an 8 × 6 ft pond two feet deep is about 96 cubic feet, or 718 gallons. The liner endpoint sizes the flexible liner to fit a pond — length equals the pond length plus twice the maximum depth plus twice the overlap to anchor under the edging stones (same for width), so that same 8 × 6 pond at two feet deep with a one-foot overlap needs a 14 × 12 ft liner and matching underlayment. The stock endpoint turns a water volume into a safe fish load and the pump you need: roughly one koi per 250 gallons (they grow large and dirty) or one goldfish per 20, plus the pump flow in gallons per hour to turn the whole pond over at least once an hour for koi — 718 gallons holds about two koi and wants a ~720 GPH pump before head-height losses. Everything is computed locally and deterministically, so it is instant and private. Ideal for landscaping and pond-installer tools, garden-design and home-improvement apps, koi and water-garden hobbyist sites, and aquascaping calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For pool chemistry use a pool API; for indoor fish tanks use an aquarium API.

Uptime

100.0%

Latency

146ms

Subs

3,141

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

173ms

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

136ms

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

161ms

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

134ms

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

193ms

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

215ms

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

212ms

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

144ms

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

158ms

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

173ms

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

159ms

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

165ms

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

161ms

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

157ms

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

129ms

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

192ms

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

157ms

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

169ms

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

149ms

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

154ms

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

159ms

Subs

3,736