API marketplace

Backyard-chicken housing maths as an API, computed locally and deterministically — the coop, run and fixture numbers a flock keeper builds to. The space endpoint sizes the housing from the flock and the breed: about 4 ft² of coop floor per standard hen (2 for bantams, 5 for heavy breeds) plus roughly 10 ft² of run each, so ten standard hens want a 40 ft² coop and a 100 ft² run — and given a coop width it returns the length, or zero run for birds that free-range and only roost inside. The fixtures endpoint covers the inside: one nest box per three to four hens (they share and queue, so ten hens need three), 8–12 inches of roost bar per bird (ten birds ≈ 8.3 feet), about 4 inches of linear feeder space each, and a waterer per eight or so birds. Crowding is the root of pecking, disease and mess, so every figure rounds up and more space is always better; roosts should sit higher than the nest boxes so the birds don’t sleep — and soil — in them. Everything is computed locally and deterministically, so it is instant and private. Ideal for homesteading, backyard-poultry, farm and smallholding app developers, coop-planner and flock-management tools, and self-sufficiency software. Pure local computation — no key, no third-party service, instant. US units, rules of thumb. Live, nothing stored. 2 compute endpoints. For feed quantities use a different API.

Uptime

100.0%

Latency

81ms

Subs

4,161

Draft-beer dispense maths as an API, computed locally and deterministically — the CO₂ pressure and beer-line numbers a homebrewer, kegerator owner or bar sets a tap by. (This is the serving side; for ABV, gravity and IBU that is a homebrewing calculation.) The carbonation endpoint gives the regulator head pressure that holds a target carbonation at the serving temperature, from the standard volumes-temperature-pressure regression: 2.5 volumes of CO₂ at 38 °F needs about 11 psi, and colder beer holds the same carbonation at a lower pressure — British ales sit around 1.5–2.0 volumes, US ales 2.2–2.7, lagers and wheats higher. The balance endpoint sizes the beer line so the system pours a clean head instead of foaming or pouring slow: line length = (applied pressure − 0.5 × rise − residual) ÷ the line’s resistance per foot, where gravity adds about 0.5 psi per foot of lift and roughly 1 psi is left at the faucet — so 12 psi with no rise on 3/16-inch vinyl (≈3 psi/ft) wants about 3.7 feet, while narrower or wider tubing changes everything. Everything is computed locally and deterministically, so it is instant and private. Ideal for homebrew, kegerator, bar, brewery-taproom and beverage app developers, draft-system and troubleshooting tools, and hospitality software. Pure local computation — no key, no third-party service, instant. Dispense side only. Live, nothing stored. 2 compute endpoints.

Uptime

100.0%

Latency

86ms

Subs

4,847

Knife-sharpening maths as an API, computed locally and deterministically — the bevel and angle numbers a sharpener, cook or knifemaker sets a stone to. It uses the symmetric V-edge model: the bevel endpoint takes the blade thickness and a per-side (or inclusive) angle and returns the bevel face width = (thickness ÷ 2) ÷ sin(per-side angle), with the inclusive angle as twice the per-side — so a 2 mm blade ground at 15° per side has a 3.86 mm bevel and a 30° edge, and at a 40° inclusive (20° per side) a 2.92 mm bevel. The angle endpoint runs it in reverse for the marker (Sharpie) method: colour the edge, take one stroke, measure the shiny bevel, and per-side angle = asin((thickness ÷ 2) ÷ bevel width) tells you the angle you are actually holding. The recommend endpoint gives sensible inclusive-angle ranges by use — about 12–17° for razors, 20–30° for Japanese kitchen knives, 30–40° for Western chef’s and EDC, 40–50° for outdoor and hard use, 45–65° for axes — and converts any chosen inclusive angle to per-side and back. Everything is computed locally and deterministically, so it is instant and private. Ideal for knife, kitchen, EDC, bushcraft, woodworking and sharpening app developers, sharpening-jig and edge-geometry tools, and maker software. Pure local computation — no key, no third-party service, instant. Symmetric V-edge model, mm and degrees. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

80ms

Subs

3,532

Welding settings and consumables maths as an API, computed locally and deterministically — the amperage, wire and gas numbers a welder or fabricator dials a machine in with. (For joint strength, that is a separate weld-strength calculation.) The amperage endpoint gives a starting current from material thickness using the mild-steel rule of thumb of about one amp per 0.001 inch — so an eighth-inch plate runs around 125 A, give or take ten percent — and suggests an electrode or wire size to match. The deposition endpoint does the MIG arithmetic exactly: deposition rate (lb/hr) = wire feed speed × the wire’s weight per inch × 60 × efficiency, where weight per inch = (π/4 · d²) × 0.284 lb/in³ for steel, so 0.035-inch wire at 300 in/min lays down about 4.9 lb/hr fed, 4.8 deposited at 98 % — and from a target deposit it returns the arc time and the pounds of wire to buy. The gas endpoint sizes shielding gas: gas used (ft³) = flow in CFH × arc time in hours, and a cylinder’s arc-time duration, so 35 CFH empties an 80 ft³ bottle in about 2.3 hours of actual arc time. Everything is computed locally and deterministically, so it is instant and private. Ideal for welding, metal-fabrication, manufacturing and shop-management app developers, job-costing and consumable-planning tools, and welding-education software. Pure local computation — no key, no third-party service, instant. Machine settings, not joint strength. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

76ms

Subs

4,220

Screen-printing maths as an API, computed locally and deterministically — the ink-usage and cost numbers an apparel printer or print shop quotes a job by. It all turns on “ink mileage”, the printed area a unit of ink covers — in² per pound, with plastisol commonly 12,000–18,000 depending on mesh and deposit. The ink endpoint sizes a run: ink = (print area × prints) ÷ mileage, so a 100 in² design printed 150 times at 15,000 in²/lb takes exactly one pound (454 g, about 3 g a print); pass the design as area or as width × height. The prints endpoint runs it in reverse — how many shirts a tub of ink will do: prints = (ink weight × mileage) ÷ print area, so a pound of plastisol covers 15,000 in², roughly 150 prints of that design before waste, and it takes pounds, kilograms or grams. The cost endpoint puts a price on it: ink pounds × price per pound gives the run’s ink cost and the per-print figure, usually just a few cents — ink only, before screens, garments and labour. Everything is computed locally and deterministically, so it is instant and private. Ideal for screen-printing, apparel-decoration, print-shop and merch app developers, quoting and job-costing tools, and production-planning software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Ink only; add screens, garments and labour for a full quote.

Uptime

100.0%

Latency

79ms

Subs

3,682

Leathercraft maths as an API, computed locally and deterministically — the weight, area and strap numbers a leatherworker, saddler or maker cuts a project by. The thickness endpoint handles the quirk that leather “weight” is really a thickness: one ounce equals one sixty-fourth of an inch, or 0.397 mm, so 8 oz leather is 3.18 mm — and it converts in either direction between ounces, millimetres and inches and suggests typical uses, from 2–3 oz linings and wallets up to 9 oz-plus belts and saddlery. The area endpoint converts hide area between the US square foot, the European square decimetre (1 ft² = 9.29 dm²) and square metres, and sizes a project: given the leather a project needs and a waste allowance — 25–40 % is normal because hides have irregular edges and flaws — it returns the usable area and how many hides to buy. The strap endpoint counts straps cut from a rectangular piece (count = ⌊width ÷ strap width⌋, each as long as the piece) or the continuous lace length a spiral cut yields from an area (length = area ÷ width). Everything is computed locally and deterministically, so it is instant and private. Ideal for leatherwork, saddlery, crafting, bag-making and maker app developers, project-estimator and material-cost tools, and workshop software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

72ms

Subs

4,545

Rock-climbing grade conversion as an API, computed locally and deterministically — the cross-system grade translations a climber, gym or guidebook app needs when the same route reads differently in every country. The route endpoint takes a roped-climbing grade in any major system — the American Yosemite Decimal System (5.5 to 5.15d), French sport grades (4b to 9c+), the UIAA scale used across Central Europe (IV to XIII-) or the Australian/New Zealand Ewbank numbers (12 to 40) — and returns the equivalents in all of them, so a 5.11a is a French 6c, a UIAA VII+ and an Ewbank 22. The boulder endpoint converts between the American V-scale (VB and V0 to V17) and the French Fontainebleau scale (3 to 9A), so a V5 is Font 6C and a problem graded 7A is about V6. You can pass a grade in any supported system and it finds the row and gives the rest — handy for syncing a tick list across regions or showing a climber a grade they recognise. Everything is computed locally and deterministically, so it is instant and private. Ideal for climbing, bouldering, gym, guidebook and outdoor-sports app developers, tick-list and route-database tools, and training-log software. Pure local computation — no key, no third-party service, instant. Chart equivalents — grades are inherently approximate across systems. Live, nothing stored. 2 conversion endpoints.

Uptime

100.0%

Latency

76ms

Subs

3,760

Bicycle wheel-building maths as an API, computed locally and deterministically — the spoke-length and tension numbers a wheelbuilder laces a wheel by. The spoke endpoint runs the classic spoke-length formula from the hub and rim geometry: L = √(R² + r² + f² − 2·R·r·cos θ) − hole ÷ 2, where R is half the effective rim diameter (ERD), r is half the hub flange diameter, f is the centre-to-flange offset and θ = crosses × 720° ÷ spokes — so a 602 mm ERD rim on a 45 mm flange at 35 mm offset, 32 spokes laced 3-cross (a 67.5° crossing angle), needs a 293.9 mm spoke. It handles radial (0-cross) builds and computes the drive and non-drive sides separately from their own offsets, since a dished wheel’s two sides differ. The bracing endpoint gives each side’s bracing angle = atan(offset ÷ (ERD/2)) — the lever that resists side loads — and the resulting tension ratio, because the side with the smaller offset must carry higher tension, which is why a rear wheel’s non-drive spokes (often only about half the drive-side tension) go slack first. Everything is computed locally and deterministically, so it is instant and private. Ideal for bike-shop, wheelbuilding, cycling and bike-fit app developers, spoke-calculator and build-sheet tools, and component-database software. Pure local computation — no key, no third-party service, instant. Millimetres. Live, nothing stored. 2 compute endpoints. For gear inches or gearing use a bicycle-gear API.

Uptime

100.0%

Latency

79ms

Subs

4,173

Casting and epoxy-resin maths as an API, computed locally and deterministically — the mix, coverage and mould-volume numbers a resin artist, crafter or maker pours a project by. The mix endpoint splits a two-part resin by its label ratio: resin = total × A/(A+B), hardener = total × B/(A+B), from whichever quantity you know — the total, the resin or the hardener — so a 2:1 epoxy for 300 ml is 200 + 100, and a 100:45 by-weight system for 100 g of resin needs 45 g of hardener; it keeps your unit (ml, grams, fl oz) and reminds you that some resins mix by volume and others by weight. The coverage endpoint sizes a flood or seal coat: volume = area × thickness, in metric or US units, returned in millilitres, fluid ounces and gallons plus the mass — matching the familiar art-resin rule of about a gallon per 12 ft² at an eighth of an inch. The moldfill endpoint computes the volume of a box, cylinder, sphere or cone mould (a 10×10×5 cm box is 500 ml, 550 g at epoxy’s ~1.1 g/cm³) and subtracts the displacement of anything you embed, so you never over- or under-pour. Everything is computed locally and deterministically, so it is instant and private. Ideal for resin-art, craft, jewelry, model-making, river-table and maker app developers, project-estimator and material-cost tools, and studio software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For pot life and cure follow the product data sheet.

Uptime

100.0%

Latency

74ms

Subs

4,314

Home-canning maths as an API, computed locally and deterministically — the altitude adjustments that keep a batch of preserves safe, the numbers a canner, homesteader or recipe app processes a jar by. Because water boils cooler the higher you are, every tested sea-level recipe has to run longer or hotter, and this API does that arithmetic. The waterbath endpoint applies the USDA boiling-water-bath and steam-canner rule: for a base process of 20 minutes or less add 5, 10, 15 or 20 minutes by altitude band, and for more than 20 minutes add 10, 20, 30 or 40 — so a 15-minute pickle recipe at 4,000 feet processes 25 minutes, and a 30-minute one runs 50. The pressure endpoint adjusts the canner: a dial gauge gains 1 psi per 2,000 feet, turning an 11 psi recipe into 12, 13, 14 or 15, while a weighted gauge simply steps from 10 psi up to 1,000 feet to 15 above it, since it only has 5/10/15 settings. The boilingpoint endpoint gives the underlying reason — water boils about 1.84 °F lower per 1,000 feet, so 5,000 feet boils at 202.8 °F instead of 212. Everything is computed locally and deterministically, so it is instant and private. Ideal for canning, food-preservation, homesteading, recipe and kitchen app developers, preserving-calculator and pantry tools, and cooking-class software. Pure local computation — no key, no third-party service, instant. USDA tables — always follow a tested recipe. Live, nothing stored. 3 compute endpoints.

Uptime

100.0%

Latency

83ms

Subs

4,575

Log-scaling and timber maths as an API, computed locally and deterministically — the board-foot yield and cubic volume a logger, sawyer or forester scales a round saw log with. The boardfeet endpoint runs the three classic log rules at once from the small-end diameter inside bark and the length: Doyle = ((D − 4) ÷ 4)² × L, Scribner Decimal C ≈ (0.79·D² − 2·D − 4) × L ÷ 16, and the International ¼-inch rule by exact four-foot segments with a half-inch taper allowance, rounded to the nearest 5 board feet — so a 20-inch, 16-foot log scales 256 BF by Doyle, 272 by Scribner and 320 by International, neatly showing how Doyle under-scales small logs, International is the most accurate and Scribner sits between. The volume endpoint gives the cubic content by Smalian’s formula — the average of the two end cross-section areas times length — and Huber’s formula — the mid cross-section area times length, usually the most accurate — both in cubic feet and cords (128 ft³ = 1 cord). Everything is computed locally and deterministically, so it is instant and private. Ideal for forestry, logging, sawmill, timber-cruising and land-management app developers, log-buyer and timber-valuation tools, and woodlot calculators. Pure local computation — no key, no third-party service, instant. Imperial forestry units. Live, nothing stored. 2 compute endpoints. For sawn-board board feet use a lumber API.

Uptime

100.0%

Latency

86ms

Subs

4,210

Pet-nutrition maths as an API, computed locally and deterministically — the calorie, portion and water numbers a dog or cat owner, breeder or pet app feeds an animal by. The calories endpoint uses the standard veterinary formula: resting energy RER = 70 × (body weight in kg)^0.75, then daily maintenance MER = RER × a lifestage factor — 1.6 for a neutered adult dog, 1.2 for a neutered cat, 1.0 or 0.8 for weight loss, 2–3 for puppies and 2.5 for kittens — so a 10 kg neutered dog needs about 394 kcal at rest and 630 kcal a day, and a 5 kg neutered cat about 234 and 281. Weight takes kg or pounds, and a custom factor overrides the table. The portion endpoint turns that calorie need into food: daily grams = calories ÷ the food’s energy density (kcal per 100 g, often 350–450 for dry kibble) or cups ÷ kcal per cup, split across meals — so 630 kcal of a 375-kcal/100 g kibble is about 168 g a day, 84 g per meal. The water endpoint gives the daily requirement, roughly 50–60 ml per kg for dogs and 50 for cats. Everything is computed locally and deterministically, so it is instant and private. Ideal for pet-care, veterinary, pet-food, dog- and cat-app developers, feeding-calculator and pet-health tools, and breeder software. Pure local computation — no key, no third-party service, instant. Educational estimates, not veterinary advice. Live, nothing stored. 3 compute endpoints. For dog-age conversion use a different API.

Uptime

100.0%

Latency

74ms

Subs

4,208

Alcohol and cocktail maths as an API, computed locally and deterministically — the ABV, dilution and standard-drink numbers a bartender, brewer or drinks app works out behind the bar. The abv endpoint mixes a drink: pass the ingredients as a volume:abv list and it returns the final alcohol by volume = (sum of volume × ABV) ÷ total volume, so a Negroni-style 2 parts at 40 %, 1 at 20 % and 1 mixer at 0 % lands at 25 % ABV (50 US proof), with mixers diluting the result. The dilution endpoint models ice melt and stirring, which add water and drop the strength: final volume = volume × (1 + dilution) and ABV falls by the same factor while the alcohol itself is unchanged, so a 4 oz stirred drink at 25 % with 25 % dilution becomes 5 oz at 20 % — stirred drinks pick up roughly 20–25 %, shaken a little more. The standard endpoint counts the dose: pure alcohol = volume × ABV, then a US standard drink is 14 grams (0.6 fl oz) and a UK unit is 10 ml of pure alcohol, so a 12 fl oz beer at 5 % is one standard drink (14 g, 1.77 UK units) and a 5 fl oz glass of 12 % wine is one too. Everything is computed locally and deterministically, so it is instant and private. Ideal for bartending, brewing, beverage, hospitality and responsible-drinking app developers, cocktail-builder and drink-tracker tools, and bar-menu calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For drink recipes use a cocktails database API.

Uptime

100.0%

Latency

77ms

Subs

4,305

Sailing and naval-architecture maths as an API, computed locally and deterministically — the hull-speed and design-ratio numbers a sailor, boat-shopper or yacht designer sizes a boat with. The hullspeed endpoint gives the theoretical displacement speed limit from the waterline: hull speed = 1.34 × √LWL (feet) in knots, so a 25-foot waterline tops out around 6.7 knots (7.7 mph, 12.4 km/h) — with a tunable coefficient up to about 1.5 for light, easily-driven hulls, since planing boats leave the formula behind entirely. The ratios endpoint computes the two classic performance numbers: the Sail Area/Displacement ratio, SA/D = sail area ÷ (displaced volume in ft³)^⅔ using displaced volume = displacement ÷ 64 lb/ft³ for seawater — around 16–18 is a typical cruiser and 20-plus is sporty — and the Displacement/Length ratio, DLR = (displacement in long tons) ÷ (0.01 × LWL)³, where under 200 is light and over 300 is heavy, each returned with a class label. The ballast endpoint gives the ballast ratio = ballast ÷ displacement × 100, a rough proxy for stiffness and sail-carrying power that most cruisers hit near 35–45 %. Everything is computed locally and deterministically, so it is instant and private. Ideal for sailing, boating, marine, yacht-brokerage and boat-design app developers, boat-comparison and rig-sizing tools, and naval-architecture calculators. Pure local computation — no key, no third-party service, instant. Imperial units. Live, nothing stored. 3 compute endpoints. Design-ratio estimates, not a velocity prediction program.

Uptime

100.0%

Latency

72ms

Subs

4,058

Archery and arrow maths as an API, computed locally and deterministically — the FOC, energy and arrow-weight numbers an archer or bowhunter tunes a setup with. The FOC endpoint finds the front-of-center balance, the share of an arrow’s weight that sits forward of the middle: FOC = ((balance point − length ÷ 2) ÷ length) × 100 measured from the throat of the nock, so a 28-inch arrow balancing at 16 inches is 7.1 % — and it bands the result, since target archers run about 7–12 % while hunters push 12–19 % for penetration and forgiveness. The energy endpoint turns arrow weight and speed into terminal performance: kinetic energy (ft-lb) = grains × fps² ÷ 450,240 and momentum (slug-fps) = grains × fps ÷ 225,218, so a 400-grain arrow at 280 fps carries about 69.7 ft-lb and 0.50 slug-fps, with a suggested game class — momentum, not KE, is the better penetration predictor for heavy arrows. The weight endpoint totals a finished arrow from its parts — shaft (grains-per-inch × length) plus point, insert, nock and fletching — and divides by draw weight for grains-per-pound, flagging the 5-GPP minimum that protects the bow. Everything is computed locally and deterministically, so it is instant and private. Ideal for archery, bowhunting, traditional-archery and outdoor-sports app developers, arrow-builder and bow-tuning tools, and pro-shop calculators. Pure local computation — no key, no third-party service, instant. Imperial archery units. Live, nothing stored. 3 compute endpoints. For sight marks or bow tuning use a different API.

Uptime

100.0%

Latency

75ms

Subs

3,709

Pottery and ceramics maths as an API, computed locally and deterministically — the shrinkage, glaze-batch and firing numbers a potter works out at the wheel and the kiln. The shrinkage endpoint handles the fact that clay shrinks from wet to bone-dry to fired: with a typical 12 % linear shrinkage a 100 mm rim fires down to 88 mm, and run in reverse it tells you to throw a piece larger to land on a target size — make it 100 mm wet to finish at 88 mm — and reports the volume shrinkage, which is the cube of the linear factor (about 32 %). The glaze endpoint scales a percentage recipe to a real batch: pass the ingredients as a name:percent list and a dry batch weight and it returns the grams of each, dividing by the recipe’s own percent sum so recipes that total over 100 % (a base 100 plus colorant and opacifier additions) still scale correctly, plus the water to add for dipping. The cone endpoint gives the approximate firing temperature for an Orton self-supporting cone at the standard 108 °F/hour ramp — cone 06 is about 1828 °F (998 °C) for bisque, cone 6 about 2232 °F (1222 °C) and cone 10 about 2345 °F (1285 °C) for stoneware — and reminds you that a cone measures heat-work, not just temperature. Everything is computed locally and deterministically, so it is instant and private. Ideal for ceramics, pottery-studio, maker and craft app developers, kiln-log and glaze-calculator tools, and studio-management software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For kiln-element power use a different API.

Uptime

100.0%

Latency

97ms

Subs

4,807

Deck-building maths as an API, computed locally and deterministically — the board, joist and fastener counts a homeowner or contractor needs to material out a rectangular deck. The boards endpoint turns the deck size into a real shopping list: rows = deck width ÷ (board width + gap), rounded up, so a 16 ft × 12 ft deck with a 5.5-inch board face (a 5/4×6) and a 1/8-inch gap needs 26 rows; boards run the length, each row takes one 16 ft board, and a 10 % waste allowance brings it to 29 boards plus the linear footage and the deck area. The joists endpoint frames it: joists are spaced along the length, so count = ⌊length ÷ spacing⌋ + 1 — thirteen joists at 16-inch on-center (seventeen at 12-inch for stronger or diagonal decking), each spanning the width, plus two rim joists and a ledger as total framing linear feet. The fasteners endpoint counts the screws: every decking row crosses every joist once and is fastened with two face screws there, so a 16×12 deck takes 26 × 13 × 2 = 676 screws, about 744 with waste — or one hidden clip per intersection. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, contractor, home-improvement, building-materials and renovation app developers, deck-estimator and takeoff tools, and lumber-yard calculators. Pure local computation — no key, no third-party service, instant. US units (feet/inches). Live, nothing stored. 3 compute endpoints. Rectangular decks; for indoor floor area use a flooring API.

Uptime

100.0%

Latency

77ms

Subs

4,490

Propane and LPG tank maths as an API, computed locally and deterministically — the usable-fill, energy and burn-time numbers a homeowner, RV-er, grill-master or HVAC tech works out at the tank. The tank endpoint turns a tank size into real numbers: liquid propane is 4.24 lb per gallon and holds 91,452 BTU per gallon (about 21,569 BTU per pound), so a 20 lb barbecue cylinder carries roughly 4.7 gallons and 431,000 BTU. It knows the two ways tanks are sized — a portable cylinder (20, 30, 40 lb) is rated by the propane weight it holds, while a bulk tank (100, 250, 500, 1000 gal) is filled to only 80 % of its water capacity to leave room for expansion, so a 500-gallon tank actually holds 400 gallons of propane and about 36.6 million BTU. The burntime endpoint divides that energy by an appliance’s BTU-per-hour input rating to give run time: that same 20 lb cylinder runs a 30,000 BTU/hr patio heater about 14 hours, and an optional hours-per-day turns it into days. The refill endpoint costs a fill from a price per gallon, gives the cost per 100,000 BTU so you can compare propane to natural gas or electricity, and — with an appliance rating — the running cost per hour. Everything is computed locally and deterministically, so it is instant and private. Ideal for home-energy, HVAC, RV, off-grid, grilling and outdoor-living app developers, fuel-cost and tank-monitor tools, and propane-delivery calculators. Pure local computation — no key, no third-party service, instant. US units. Live, nothing stored. 3 compute endpoints. For vehicle fuel economy or the ideal gas law use a different API.

Uptime

100.0%

Latency

80ms

Subs

4,756

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

Uptime

100.0%

Latency

80ms

Subs

4,560

Tabletop dice-probability maths as an API, computed locally and deterministically and exactly — the odds behind the rolls, not the rolls themselves. The advantage endpoint gives the D&D-style chances of beating a target on a d20 (or any die) rolling normally, with advantage (roll twice, keep the higher) or with disadvantage (keep the lower): needing an 11+ is 50 % normally, 75 % with advantage and 25 % with disadvantage, and it reports the average roll — advantage lifts a d20 from 10.5 to about 13.8. The pool endpoint handles success-counting systems (World of Darkness, Shadowrun): for a pool of dice that succeed on a face at or above a threshold it gives the chance per die, the expected number of successes and the exact binomial probability of getting exactly, or at least, a target number — six d10s succeeding on 7+ average 2.4 successes with a 45.6 % chance of three or more. The exploding endpoint gives the mean of an exploding ("acing", open-ended) die that re-rolls and adds on its maximum face — a d6 averages 4.2 instead of 3.5. Everything is computed locally and deterministically, so it is instant and private. Ideal for tabletop, virtual-tabletop, game-design and TTRPG app developers, odds-and-probability helpers, and game-master tools. Pure local computation — no key, no third-party service, instant. Exact maths, no simulation. Live, nothing stored. 3 compute endpoints. For random rolls use a dice-roller API.

Uptime

100.0%

Latency

74ms

Subs

3,594

Catering and party-planning maths as an API, computed locally and deterministically — the how-much-do-I-buy numbers a host or caterer plans a headcount with. The food endpoint scales a menu to the guest count and appetite: the main protein at about half a pound of cooked meat per person (light 0.33, hearty 0.75), each side dish at roughly four ounces a head, six appetizer pieces each and one-and-a-half dinner rolls — so 50 guests at a standard dinner with three sides need 25 lb of meat, 300 appetizers and 75 rolls. The drinks endpoint sizes the bar: about one drink per guest per hour plus an extra in the first hour, split across beer, wine and cocktails, and converted into the real units you buy — beer by the case (24) and the half-keg (~165 servings), wine by the bottle (~5 glasses), spirits by the 750 ml bottle (~16 shots) — plus the ice (about 1.5 lb per guest) and water; a 50-guest, four-hour party comes to 250 drinks, 125 beers (0.76 of a keg), 15 bottles of wine and 75 lb of ice. Everything is computed locally and deterministically, so it is instant and private. Ideal for event-planning, catering, hospitality and party app developers, shopping-list and headcount tools, and host calculators. Pure local computation — no key, no third-party service, instant. US units; rules of thumb — round up. Live, nothing stored. 2 compute endpoints. Adjust for the crowd and the season.

Uptime

100.0%

Latency

78ms

Subs

4,088

Dungeons & Dragons 5th-edition encounter-building maths as an API, computed locally and deterministically — the XP-budget and difficulty numbers a Dungeon Master balances a fight with. The budget endpoint sums the per-character XP thresholds from the DMG across the party — by party size and level, or a list of mixed levels — to give the easy, medium, hard and deadly budget for one encounter (a party of four 5th-level characters has thresholds of 1,000 / 2,000 / 3,000 / 4,400 XP), plus the total adventuring-day budget. The difficulty endpoint rates an encounter: it sums the monsters' XP, multiplies by the encounter multiplier for the number of monsters (×1.5 for two, ×2 for three to six, up to ×4 for fifteen or more), and compares the adjusted XP to the party thresholds — four 450-XP monsters against that party come to 3,600 adjusted XP, a hard fight. The carry endpoint gives the carrying capacity (Strength × 15, scaled by size), push/drag/lift and the encumbrance thresholds. Everything is computed locally and deterministically, so it is instant and private. Ideal for tabletop, virtual-tabletop, DM-tool and TTRPG app developers, encounter-builder and balance tools, and game-master education. Pure local computation — no key, no third-party service, instant. Uses the DMG tables. Live, nothing stored. 3 compute endpoints. For monster stats and spells use a D&D SRD data API.

Uptime

100.0%

Latency

74ms

Subs

3,707

Darts scoring maths as an API, computed locally and deterministically — the X01 checkout and average numbers a darts player, league or scoring app runs on. The checkout endpoint solves a remaining score with an exact full-board search: whether it can be finished, the minimum number of darts and one valid combination that ends on a double or the bull — 170 finishes T20 T20 Bull (the highest possible three-dart checkout), 100 is T20 D20, 40 is simply D20, while 1 cannot be finished (the last dart must be a double, minimum 2) and the bogey numbers 169, 168, 166, 165, 163, 162 and 159 cannot be checked out in three darts at all. The average endpoint computes the three-dart average — total score ÷ darts × 3 — so 501 in 15 darts is a 100.2 average; a 100-plus average is strong play. Everything is computed locally and deterministically, so it is instant and private. Ideal for darts, league-scoring, pub-game and sports app developers, checkout-assistant and practice tools, and darts education. Pure local computation — no key, no third-party service, instant. Standard X01 rules; legs end on a double or the bull. Live, nothing stored. 2 compute endpoints. An exact scoring aid for the standard 20-segment board.

Uptime

100.0%

Latency

76ms

Subs

4,296

Golf scoring and handicap maths as an API, computed locally and deterministically — the World Handicap System and Stableford numbers a golfer, club or scoring app works to. The handicap endpoint computes the course handicap from a handicap index: course handicap = index × (slope rating ÷ 113) + (course rating − par), rounded, so a 14.5 index on a 130-slope, 71.5-rated par-72 course plays off 16; it also applies the format allowance (e.g. 95 % for stroke play) to give the playing handicap. The stableford endpoint scores a hole on the standard scale: net par is 2 points, each stroke better adds one (birdie 3, eagle 4) and each worse subtracts one (bogey 1), with net double bogey or worse scoring 0, where the net score is the gross minus the strokes received on that hole. The net endpoint gives the round's net score — gross total minus the course handicap — against par. Everything is computed locally and deterministically, so it is instant and private. Ideal for golf, club-management, scoring and sports app developers, handicap and Stableford tools, and golf education. Pure local computation — no key, no third-party service, instant. Slope defaults to the neutral 113. Live, nothing stored. 3 compute endpoints. A scoring aid, not an official handicap record.

Uptime

100.0%

Latency

78ms

Subs

4,634