API marketplace

Weaving and loom maths as an API, computed locally and deterministically — the warp, weft and sett numbers a handweaver warps a loom by. The warp endpoint computes the total ends and the warp yarn for a project: ends = warp width × EPI (ends per inch, the sett), and the warp length per end = the cloth length adjusted for take-up (~10 %) and shrinkage plus the loom waste (~24 inches of thrums), so a 20-inch-wide piece at 12 EPI woven to 60 inches needs 240 ends and 600 yards of warp. The weft endpoint computes the weft yarn from the picks per inch, the width and the woven length: picks = PPI × woven length, each crossing the width plus the draw-in. The sett endpoint turns a yarn's wraps-per-inch into the ends-per-inch to set: a balanced plain weave is half the WPI, twill two-thirds, satin three-quarters — so a yarn that wraps 24 times per inch setts at 12 EPI for plain weave. Everything is computed locally and deterministically, so it is instant and private. Ideal for weaving, fiber-arts, textile and craft app developers, warp-calculator and project-planning tools, and weaving education. Pure local computation — no key, no third-party service, instant. Imperial inches in; yards out. Live, nothing stored. 3 compute endpoints. Take-up, draw-in and loom waste have sensible defaults — measure your own loom.

Uptime

100.0%

Latency

75ms

Subs

4,475

Cross-stitch and counted-thread maths as an API, computed locally and deterministically — the design-size and floss numbers a stitcher plans a pattern with. The design endpoint turns a stitch count into a finished size on a given fabric count: design size = stitch count ÷ fabric count (stitches per inch), so a 140×98-stitch chart on 14-count Aida stitches up at 10×7 inches (25.4×17.8 cm); it adds the fabric to cut with a margin (≈3 inches each side for the hoop and finishing), reports the total stitches, and converts the same chart to another count — that 140×98 design shrinks to 7.8×5.4 inches on 18-count. The floss endpoint estimates the skeins of thread: skeins ≈ ceil(stitches ÷ stitches-per-skein), where about 1,200 full cross-stitches per skein is typical for two strands on 14-count, and it makes sure you buy at least one skein per colour. Everything is computed locally and deterministically, so it is instant and private. Ideal for cross-stitch, embroidery, needlework and craft-pattern app developers, pattern-and-kit and fabric tools, and needlework education. Pure local computation — no key, no third-party service, instant. Fabric count is stitches per inch; sizes in inches and centimetres. Live, nothing stored. 2 compute endpoints. Floss/skein figures are estimates — buy a little extra.

Uptime

100.0%

Latency

78ms

Subs

3,192

Picture-framing maths as an API, computed locally and deterministically — the mat-cutting and moulding numbers a framer or artist measures a job by. The mat endpoint sizes the mat board around an artwork: the window opening is the art minus a small overlap on each edge (≈ 0.25 inch so the mat holds the print), and the outer mat is the window plus the border widths — give one border or per-side borders, with a heavier bottom for a balanced, bottom-weighted mat, so an 8×10 print with a 2-inch border has a 7.5×9.5 window and an 11.5×13.5 mat. The moulding endpoint computes the frame stick needed: length = inner perimeter + 8 × the moulding width, because each of the four 45-degree mitred corners adds one moulding width — an 11.5×13.5 frame in 1.5-inch moulding needs 62.5 inches, plus any waste allowance. Everything is computed locally and deterministically, so it is instant and private. Ideal for picture-framing, custom-framing, art-gallery and DIY app developers, mat-cutter and moulding-estimating tools, and framing education. Pure local computation — no key, no third-party service, instant. Imperial inches in; lengths in inches and feet. Live, nothing stored. 2 compute endpoints. A planning aid — measure twice, cut once.

Uptime

100.0%

Latency

82ms

Subs

4,231

Sewing and fabric-estimating maths as an API, computed locally and deterministically — the yardage numbers a sewist, quilter or curtain-maker works a project out with. The yardage endpoint lays cut pieces onto a bolt: pieces per row = floor(fabric width ÷ piece width), rows = ceil(quantity ÷ per row), and the fabric length = rows × piece height plus a waste allowance — six 18×22-inch pieces from 44-inch quilting cotton need about 2 yards. The curtain endpoint sizes drapery for fullness: drops = ceil(window width × fullness ÷ fabric width), where 2× is a standard gather and 2.5–3× is luxe, and each drop is the finished length plus top and bottom hems (rounded up to the pattern repeat) — a 60-inch window at 2.5× fullness on 54-inch fabric takes three drops and about 8.3 yards. The binding endpoint sizes quilt binding: length = perimeter + overlap for corners and joins, strips = ceil(length ÷ fabric width) cut at the strip width. Everything is computed locally and deterministically, so it is instant and private. Ideal for sewing, quilting, home-decor, upholstery and craft app developers, fabric-calculator and project-planning tools, and sewing education. Pure local computation — no key, no third-party service, instant. Imperial inches in; yards and metres out. Live, nothing stored. 3 compute endpoints. Add pattern-repeat allowance for prints; a planning aid.

Uptime

100.0%

Latency

77ms

Subs

3,991

Bookbinding and print-production maths as an API, computed locally and deterministically — the spine-width and imposition numbers a book designer, printer or self-publisher needs to lay out a title. The spine endpoint computes the spine width from the page count and the paper's bulk: spine = page count ÷ pages-per-inch (the printer's paper spec, typically ~400–500 for book stock), or leaves × sheet caliper, plus the cover boards — so a 250-page book on 400-PPI stock has a 0.625-inch (15.9 mm) spine. The imposition endpoint works out the binding layout: for saddle-stitch it rounds the page count up to the next multiple of four (one folded sheet is four pages) and reports the blanks to pad and the sheets; for perfect-bound or section-sewn books it gathers the pages into signatures of 8, 16 or 32 and reports the signature count, the required page total and the blank pages. Everything is computed locally and deterministically, so it is instant and private. Ideal for self-publishing, print-on-demand, book-design, prepress and printing app developers, spine-and-cover and imposition tools, and graphic-design education. Pure local computation — no key, no third-party service, instant. Page count counts both sides; PPI is the paper spec. Live, nothing stored. 2 compute endpoints. For paper weight use a paper API and for DPI/resolution a resolution API.

Uptime

100.0%

Latency

81ms

Subs

3,687

Water turnover and circulation maths as an API, computed locally and deterministically — the flow-rate numbers a pool tech or aquarist sizes a pump to. The turnover endpoint relates a body of water's volume to its flow: turnover time = volume ÷ flow rate, and turnovers per day = 24 ÷ turnover time, so a 50,000-litre pool circulated at 10,000 L/h turns over in 5 hours, almost 5 times a day (pools usually target an 8–12 hour turnover, 2–4 a day); give a target turnover time instead and it returns the flow rate to size the pump to. The aquarium endpoint accounts for the real-world head loss that robs a pump of flow: effective flow = rated flow × (1 − head loss), so a 1,500 L/h pump at 40 % loss really moves 900 L/h, about 4.5× a 200-litre tank an hour; give a target turnovers-per-hour (freshwater 4–6×, planted 5–10×, reef 10×+) and it returns the rated pump to buy so losses still leave enough flow. Everything is computed locally and deterministically, so it is instant and private. Ideal for pool-service, aquarium, hydroponics, water-feature and pond app developers, pump-sizing and circulation tools, and equipment education. Pure local computation — no key, no third-party service, instant. Use consistent volume and flow units. Live, nothing stored. 2 compute endpoints. For pump power and head use a pump API; for pool chemistry a pool-chemistry API.

Uptime

100.0%

Latency

89ms

Subs

3,899

Beekeeping and apiary maths as an API, computed locally and deterministically — the mite, brood and winter-stores numbers a beekeeper manages a hive with. The varroa endpoint turns an alcohol-wash or sugar-shake count into the infestation rate: mites per 100 bees = mite count ÷ bees sampled × 100, where a half-cup scoop is about 300 bees, and it flags when the colony crosses the treatment threshold (commonly 3 mites per 100 bees, or 3 %). The brood endpoint projects the development calendar from the day an egg is laid: it hatches around day 3, the cell is capped around day 8–10 and the adult emerges on day 16 for a queen, 21 for a worker and 24 for a drone — so a worker egg laid on the 1st emerges three weeks later. The stores endpoint sizes winter honey: how many kilograms the colony needs by climate (about 12 kg mild to 35 kg harsh), the equivalent full deep frames (~2.25 kg each), and the deficit and frames to feed against the current stores. Date arithmetic is exact. Everything is computed locally and deterministically, so it is instant and private. Ideal for beekeeping, apiary-management, homestead and agriculture app developers, hive-inspection and mite-monitoring tools, and beekeeping education. Pure local computation — no key, no third-party service, instant. Dates as YYYY-MM-DD; metric weights. Live, nothing stored. 3 compute endpoints. A planning aid — local conditions vary.

Uptime

100.0%

Latency

81ms

Subs

4,732

Maple-syrup making maths as an API, computed locally and deterministically — the sap-to-syrup yield and finishing numbers a sugarmaker plans a season around. The yield endpoint takes the volume of sap and its sugar content in °Brix and returns the syrup it makes from the sugar balance (syrup = sap × sap °Brix / finished °Brix, finishing at 66.9 °Brix), the water that has to boil off, the sap-to-syrup ratio, and the classic Jones' Rule of 86 (86 ÷ sap °Brix) — the field rule that famously gives about 43 litres of 2 % sap per litre of syrup. The finish endpoint gives the boil-off finishing temperature: syrup is done about 4 °C (7.1 °F) above the boiling point of water, so at sea level that is ~104 °C / 219 °F — calibrate to your own water boiling point, which drops with altitude, and finish that many degrees higher; it also returns the finished density (~66.9 °Brix, SG ≈ 1.337). Everything is computed locally and deterministically, so it is instant and private. Ideal for maple-sugaring, homestead, craft-food and farm app developers, evaporator and yield-planning tools, and sugaring education. Pure local computation — no key, no third-party service, instant. Consistent volume units; temperatures in °C or °F. Live, nothing stored. 2 compute endpoints. A planning aid — a hydrometer or refractometer confirms the finish.

Uptime

100.0%

Latency

76ms

Subs

4,388

Cheese-making maths as an API, computed locally and deterministically — the yield and rennet numbers an artisan or home cheesemaker plans a make around. The yield endpoint applies the classic Van Slyke formula, yield % of milk = [(0.93 × fat) + (casein − 0.1)] × 1.09 / (1 − cheese moisture), from the milk fat, the casein (or true protein, since casein ≈ 0.78 × protein) and the target cheese moisture — whole milk at 3.5 % fat and 2.5 % casein making a 37 %-moisture cheddar yields about 9.78 % of the milk weight, so 100 litres gives roughly 10 kg of cheese and it takes about 9.9 litres of milk per kilogram. The rennet endpoint doses a milk volume to set: single-strength liquid rennet at roughly 0.2 ml per litre (double and triple strengths and tablets too), diluted about 20× in cool, non-chlorinated water before stirring in. Everything is computed locally and deterministically, so it is instant and private. Ideal for cheesemaking, dairy, creamery and artisan-food app developers, make-sheet and yield-planning tools, and dairy-science education. Pure local computation — no key, no third-party service, instant. Metric: litres, grams, percent. Live, nothing stored. 2 compute endpoints. Rennet strengths vary by product — confirm the label IMCU; a planning aid.

Uptime

100.0%

Latency

85ms

Subs

3,985

Animal gestation and egg-incubation date maths as an API, computed locally and deterministically — the breeding and hatch calendar a farmer, breeder or vet works to. The gestation endpoint takes a species and a breeding date and returns the expected due date with the normal early-to-late window: due date = breeding date + the species' average gestation, so a cow bred on the 1st of January (283 days) calves around the 11th of October, a dog (63 days) whelps nine weeks later, a goat 150 days, a horse 340, a pig 114 — dozens of species from rabbit to camel to elephant, with an override for your own herd average. Give a target birth date instead and it works backwards to the date to breed. The incubation endpoint does the same for poultry and birds — chicken 21 days, duck 28, goose 30, quail 18, ostrich 42 and more — returning the hatch date, the lockdown date (stop turning and raise humidity ~3 days before hatch) and the day-7 and day-14 candling dates. Date arithmetic is exact, including leap years. Everything is computed locally and deterministically, so it is instant and private. Ideal for livestock, breeding, veterinary, farm-management and hatchery app developers, gestation-calculator and breeding-calendar tools, and agricultural education. Pure local computation — no key, no third-party service, instant. Dates as YYYY-MM-DD. Live, nothing stored. 2 compute endpoints. Averages, not a veterinary prediction.

Uptime

100.0%

Latency

78ms

Subs

4,515

Candle-making maths as an API, computed locally and deterministically — the wax, fragrance and burn-time numbers a chandler scales a batch with. The recipe endpoint sizes a pour from the container water volume: wax (g) per candle = volume(ml) × fill% × wax density (soy ≈ 0.9, beeswax ≈ 0.96, paraffin ≈ 0.9 g/ml), so a 250 ml jar at 80 % fill takes 180 g of soy wax; it adds the fragrance oil at the load percentage (commonly 6–10 %, never above the wax's maximum) and multiplies everything by the number of candles for the total wax, total fragrance and batch weight. The burn endpoint estimates how long a candle lasts: burn time ≈ wax grams ÷ burn rate, where a typical container candle consumes about 7–9 g of wax an hour. Everything is computed locally and deterministically, so it is instant and private. Ideal for candle-making, home-fragrance, handmade-craft and maker app developers, batch-calculator and recipe tools, and chandlery education. Pure local computation — no key, no third-party service, instant. Metric: millilitres, grams, percent. Live, nothing stored. 2 compute endpoints. A planning aid — pour tests and your wax datasheet always win.

Uptime

100.0%

Latency

88ms

Subs

3,785

Coffee-roasting maths as an API, computed locally and deterministically — the roast-profile numbers a home or specialty roaster tracks batch to batch. The loss endpoint works the weight-loss relationship from any two of the green weight, the roasted weight and the loss percentage: weight loss % = (green − roasted) / green × 100, so 1 kg of green dropping to 840 g is a 16 % loss, a 15 % target leaves 850 g, and to bag 800 g of roasted you charge 952 g of green (roasted ÷ (1 − loss%)). Light roasts shed about 12–14 %, medium 15–17 %, dark 18–20 %. The development endpoint computes the development time and the Development Time Ratio (DTR) from the total roast time and the first-crack time — DTR = (total − first crack) / total × 100, with most roasters aiming for roughly 20–25 %; times accepted as seconds or mm:ss. Everything is computed locally and deterministically, so it is instant and private. Ideal for coffee-roasting, roastery, specialty-coffee and roast-logging app developers, profile and batch tools, and roasting education. Pure local computation — no key, no third-party service, instant. Weights in grams, times in seconds or mm:ss. Live, nothing stored. 2 compute endpoints. This is roast-profile maths; for brewing ratios use a coffee-brewing API.

Uptime

100.0%

Latency

77ms

Subs

4,761

Soap-making and saponification maths as an API, computed locally and deterministically — the lye-calculator numbers every cold- and hot-process soaper needs, with the safety margin built in. The lye endpoint takes a list of oils as oil:grams pairs (olive, coconut, palm, shea, castor, lard, tallow and a couple of dozen more, each with its standard SAP value) and returns the sodium hydroxide (NaOH) or potassium hydroxide (KOH) to saponify them: lye = Σ(oil grams × SAP) × (1 − superfat), so 1 kg of coconut oil at 5 % superfat needs 169.1 g of NaOH (or 263.6 g of 90 %-pure KOH for liquid soap). It sizes the water by lye-to-water ratio, percentage of oils, or lye-solution concentration, adds the fragrance (a few percent of the oils) and totals the batch weight. The mould endpoint sizes a batch to a mould: oils to fill it ≈ volume(cm³) × 0.40, from a volume or length × width × height. SAP values are grams of NaOH per gram of oil. Everything is computed locally and deterministically, so it is instant and private. Ideal for soap-making, cosmetics, handmade-craft and maker app developers, lye-calculator and recipe tools, and soaping education. Pure local computation — no key, no third-party service, instant. Metric: grams, cm³, percent. Live, nothing stored. 2 compute endpoints. Lye is caustic — wear protection and double-check a new recipe; this is a planning aid.

Uptime

100.0%

Latency

77ms

Subs

4,002

Winemaking and oenology maths as an API, computed locally and deterministically — the must-correction, sulfite and acid numbers a home or small-batch winemaker dials in. The sugar endpoint reads the must as Brix or specific gravity, gives the potential alcohol (potential ABV = (SG − 1) × 131.25), and works out the chaptalization sugar to reach a target ABV — sugar (g) = volume(L) × Δ potential-ABV × 16.83, since roughly 17 g/L of sugar ferments to about 1 % alcohol. The so2 endpoint handles sulfite protection: it converts between free and molecular SO2 at the wine's pH (molecular SO2 = free / (1 + 10^(pH − 1.81)), aiming for the protective 0.8 mg/L molecular), shows how the free SO2 needed plummets as pH drops, and doses the potassium metabisulfite (57.6 % SO2) and campden tablets (~0.44 g each) to hit a target free SO2 in a given volume. The acid endpoint moves titratable acidity to a target with tartaric acid to raise it (grams = ΔTA × volume) or potassium bicarbonate to lower it. Everything is computed locally and deterministically, so it is instant and private. Ideal for winemaking, cidery, mead, home-fermentation and craft-beverage app developers, must-calculator and cellar tools, and oenology education. Pure local computation — no key, no third-party service, instant. Metric: litres, grams, g/L, mg/L. Live, nothing stored. 3 compute endpoints. A planning aid — your lab numbers and palate always win. For beer ABV from gravity use a homebrewing API.

Uptime

100.0%

Latency

82ms

Subs

3,495

Meat-curing and charcuterie maths as an API, computed locally and deterministically — the cure, salt and nitrite numbers a home charcutier or butcher works to, with the safety check that matters most. The cure endpoint plans an equilibrium dry cure from the meat weight: cure grams = target ppm × meat ÷ (0.0625 × 1,000,000), so about 2.5 g of Cure #1 per kilogram lands on the classic 156 ppm of nitrite (well under the 200 ppm ingoing limit), plus the salt and sugar as a configurable percentage of the meat, the salt the cure blend itself carries, and — with Cure #2 — the added nitrate for long-aged salami. The brine endpoint sizes a wet brine: salt = water × salinity %, with the salometer degrees (a saturated 26.45 % brine is 100°), and an optional cure dose returning the nitrite ppm spread over the meat and brine for an equilibrium brine. Cure #1 is 6.25 % sodium nitrite; Cure #2 adds 4 % nitrate. Everything is computed locally and deterministically, so it is instant and private. Ideal for charcuterie, butchery, smoking, sausage-making and food-craft app developers, cure-calculator and recipe tools, and culinary training. Pure local computation — no key, no third-party service, instant. Metric: grams, millilitres, percent. Live, nothing stored. 2 compute endpoints. THIS IS A CALCULATION AID — always follow a tested, approved curing recipe; nitrite is toxic in excess.

Uptime

100.0%

Latency

77ms

Subs

3,547

Hydroponics and indoor-grow maths as an API, computed locally and deterministically — the nutrient-strength and grow-light numbers a grower dials in every day. The ec endpoint converts between electrical conductivity (EC in mS/cm) and the PPM/TDS reading on whichever scale a meter uses: the 500 (NaCl, US) scale turns EC 2.0 into 1000 ppm, the 700 (KCl) scale into 1400 ppm and the 640 (EU) scale into 1280 — the source of endless confusion between meters. The dli endpoint computes the Daily Light Integral, DLI = PPFD × photoperiod × 3600 ÷ 1,000,000, the total moles of light a crop gets in a day (leafy greens want about 12–17, fruiting crops 20–30+), and reverses it to the PPFD a fixture must deliver to hit a target DLI over a given day length. The reservoir endpoint balances a tank to a target EC: how much plain water to add to dilute a too-strong solution (W = V × (current/target − 1)), or how much concentrated stock to add to raise it. Everything is computed locally and deterministically, so it is instant and private. Ideal for hydroponics, vertical-farming, controlled-environment-agriculture, grow-room and smart-garden app developers, dosing and lighting tools, and horticulture education. Pure local computation — no key, no third-party service, instant. EC in mS/cm, volume in litres, PPFD in µmol/m²/s. Live, nothing stored. 3 compute endpoints. State your TDS scale; confirm with a calibrated meter.

Uptime

100.0%

Latency

74ms

Subs

4,829

Swimming-pool water-chemistry maths as an API, computed locally and deterministically — the dosing and water-balance numbers a pool service tech or owner runs at every visit. The chlorine endpoint works out how much of a product to add to raise free chlorine from the current to a target ppm in a given volume: dose (g) = Δppm × litres / 1000 ÷ the product's available-chlorine fraction, with built-in strengths for liquid chlorine (12.5 %), household bleach (6 %), cal-hypo (65 %), dichlor (56 %) and trichlor (90 %), or your own — raising 50,000 litres by 2 ppm needs 800 g of liquid chlorine or 154 g of cal-hypo. The lsi endpoint computes the Langelier Saturation Index, LSI = pH + temperature factor + calcium factor + alkalinity factor − 12.1, the standard measure of whether water is corrosive (below −0.3, eating plaster and metal), balanced (−0.3 to +0.3) or scaling (above +0.3), with a cyanuric-acid correction to the carbonate alkalinity. Everything is computed locally and deterministically, so it is instant and private. Ideal for pool-service, spa, water-treatment and home-maintenance app developers, dosing and water-balance tools, and pool-care education. Pure local computation — no key, no third-party service, instant. Metric: litres, ppm (mg/L), °C. Live, nothing stored. 2 compute endpoints. Always confirm with a test kit — this is an aid, not a substitute. For pool water volume use a pool-geometry API.

Uptime

100.0%

Latency

80ms

Subs

4,962

NEC conduit-fill and box-fill maths as an API, computed locally and deterministically — the electrical-code calculations an electrician or estimator does on every run. The conduit-fill endpoint takes a set of conductors (as size:count pairs, e.g. 12:3,10:2) and a conduit trade size and returns the conductor cross-sectional area, the conduit's internal area, the fill percentage and whether it stays within the NEC Chapter 9 limit — 53 % for a single conductor, 31 % for two, 40 % for three or more — so nine #12 THHN fill a half-inch EMT to 39 % (legal) but ten do not. The box-fill endpoint applies NEC 314.16(B): each conductor adds its free-space allowance (2.00 in³ for #14, 2.25 for #12, and so on), a device yoke counts as two, internal cable clamps as one, and all equipment grounds together as one — all at the largest conductor's volume — to give the minimum junction-box size, checked against a box volume if you give one. Uses the THHN/THWN and EMT areas from NEC Chapter 9. Everything is computed locally and deterministically, so it is instant and private. Ideal for electrical-contractor, estimating, inspection and electrician app developers, conduit and box-sizing tools, and apprentice training. Pure local computation — no key, no third-party service, instant. Imperial: square inches and cubic inches. Live, nothing stored. 2 compute endpoints. Always verify against the adopted code edition — this is an estimating aid, not an inspection.

Uptime

100.0%

Latency

68ms

Subs

3,256

Stock dividend and valuation fundamentals as an API, computed locally and deterministically — the per-share ratios value and income investors screen on. The dividend endpoint takes a share price and an annual dividend (per share, or total dividends ÷ shares) and returns the dividend yield, and with earnings per share the payout ratio (dividend ÷ EPS), the dividend coverage (EPS ÷ dividend) and the retention ratio — a $2 dividend on a $50 share yields 4 %, and on $4 EPS is a 50 % payout covered twice. The valuation endpoint computes the price-to-earnings ratio, earnings yield, the PEG ratio against a growth rate, the price-to-book ratio and the Graham number √(22.5 · EPS · book value) — Benjamin Graham's rough fair-value ceiling. The ddm endpoint runs the Gordon Growth dividend discount model, fair value = D1 ÷ (r − g) from next year's dividend, the required return and the perpetual growth rate, and against a market price flags whether the share looks under- or over-valued and the implied cost of equity. Everything is computed locally and deterministically, so it is instant and private. Ideal for investing, brokerage, robo-advisor, dividend-screener and fintech app developers, stock-valuation and income-portfolio tools, and finance education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. These are valuation ratios from your inputs; for live quotes use a market-data API and for project DCF/NPV an investment-appraisal API.

Uptime

100.0%

Latency

77ms

Subs

4,714

Trading risk-management maths as an API, computed locally and deterministically — the position-sizing and money-management numbers every disciplined trader runs before a trade. The position-size endpoint is instrument-agnostic: from an account balance, the percentage of it you are willing to risk, an entry and a stop-loss it returns the position size in units (shares, contracts, lots or coins), the cash at risk and, with a target, the potential reward and the risk-reward ratio — risk 1 % of a $10,000 account on a 50-pip stop and you trade 0.2 lots, losing exactly $100 if the stop hits. The pip-value endpoint gives the forex pip value for a lot or unit size in the quote currency, with a quote-to-account rate for non-account pairs — a standard lot at a 0.0001 pip is 10 units of the quote currency. The kelly endpoint computes the Kelly criterion optimal bet fraction f* = W − (1−W)/R from a win rate and the win/loss payoff ratio (or average win and loss), plus the half-Kelly many traders prefer and the per-unit expectancy, flagging whether the edge is positive at all. Everything is computed locally and deterministically, so it is instant and private. Ideal for trading-journal, broker, prop-firm, backtesting and fintech app developers, position-sizing and risk-management tools, and trading education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is risk and position-sizing maths; for FX rate conversion use a currency API and for option pricing a Black-Scholes API.

Uptime

100.0%

Latency

79ms

Subs

4,328

Masonry estimating maths as an API, computed locally and deterministically — the brick, block and mortar counts a bricklayer, builder or estimator works to. The brick endpoint computes how many bricks a wall needs from its area (or length × height in feet): bricks per square foot = 144 / ((brick length + joint) × (brick height + joint)), so a standard modular brick with a 3/8-inch mortar joint works out to the well-known 6.86 bricks per square foot — a 100 ft² wall is 686 bricks, plus a waste allowance and the mortar bags (about 7 per 1000 bricks). The block endpoint does the same for concrete masonry units: a standard 16×8-inch CMU with a 3/8-inch joint is 1.125 blocks per square foot, with roughly 2.5 mortar bags per 100 blocks. Both endpoints take custom unit face dimensions and joint thickness, add a configurable waste percentage and round up to whole units. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, masonry-contractor, building-supply and home-improvement app developers, takeoff and material-estimating tools, and trade calculators. Pure local computation — no key, no third-party service, instant. Imperial units (inches and square feet). Live, nothing stored. 2 compute endpoints. This is brick/block and mortar estimating; for poured-concrete volume use a concrete API and for drywall use a drywall API.

Uptime

100.0%

Latency

75ms

Subs

3,732

Freight and logistics maths as an API, computed locally and deterministically — the LTL freight class and load-planning numbers a shipper, broker or warehouse works to. The freight-class endpoint computes the density (weight ÷ cubic feet) of a shipment and maps it to the NMFC density-based freight class — the 18-band scale from class 50 (densest, cheapest) to 500 (lightest) — so a 200 lb pallet measuring 48×40×48 inches is 3.75 lb/ft³ and lands in class 250. The pallet endpoint palletizes a carton: it takes the better of the two footprint orientations for cartons per layer, fills the usable stack height in layers, and returns the cartons per pallet limited by the smaller of the cube and the weight cap, with the cargo weight and stack height (defaulting to a 48×40 GMA pallet). The container endpoint loads a 40-foot high-cube container (or any dimensions you give): how many units fit by axis-aligned stacking and by payload, which one is the limiting factor, the total weight and the cube utilisation. Everything is computed locally and deterministically, so it is instant and private. Ideal for logistics, freight-brokerage, 3PL, warehouse-management and supply-chain app developers, LTL rating and load-planning tools, and shipping calculators. Pure local computation — no key, no third-party service, instant. Imperial units (inches, pounds, cubic feet) as the NMFC scale is US-based. Live, nothing stored. 3 compute endpoints. This is freight-class and load-planning maths; for single-parcel courier billing weight use a dimensional-weight API.

Uptime

100.0%

Latency

76ms

Subs

4,094

Restaurant food-costing maths as an API, computed locally and deterministically — the menu-engineering and cost-control numbers a kitchen runs on. The recipe endpoint totals a dish from its ingredient line costs (or quantities × unit prices), divides by the yield factor (1 − waste %) so trim and shrinkage raise the true cost, and splits it across the portions to a cost per plate — and against a menu price it returns the food-cost percentage and gross profit. The plate endpoint prices a dish both ways: give a menu price and get the food-cost percentage and markup factor, or give a target food-cost percentage and get the suggested menu price (a 30 % target is a 3.33× markup), plus gross profit, gross margin and, with a labour cost, the prime-cost percentage. The period endpoint turns inventory movement into the cost of goods sold — COGS = opening inventory + purchases − closing inventory — and the food or pour cost percentage against sales, the headline number on every P&L (28–35 % for food, 18–24 % for beverage). Everything is computed locally and deterministically, so it is instant and private. Ideal for restaurant-tech, POS, kitchen-management, catering and hospitality app developers, menu-engineering and recipe-costing tools, and culinary-school training. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is food-cost and menu-pricing maths; for unit conversion use a cooking API and for generic margin maths a pricing API.

Uptime

100.0%

Latency

74ms

Subs

4,982

Overall Equipment Effectiveness (OEE) and lean-manufacturing maths as an API, computed locally and deterministically — the factory-floor productivity metric behind TPM and continuous improvement. The oee endpoint takes the planned production time, downtime, the total and good piece counts and the ideal cycle time (seconds per piece, or an ideal rate in pieces per minute) and returns the three factors and their product: Availability = run time / planned time, Performance = ideal time for the parts made / run time, Quality = good / total, and OEE = Availability × Performance × Quality — the textbook example of a 420-minute shift with 47 minutes down, 19,271 parts and 423 rejects lands exactly on 74.79 % (88.81 % × 86.11 % × 97.80 %). It also breaks out the six-big-losses view: availability loss, performance (speed) loss in parts, quality loss and the fully-productive part count. The takt endpoint gives the takt time = available time / customer demand (the drumbeat the line must match), the required rate, and — given a cycle time or a total work content — the line capacity, utilisation, whether it meets demand and the minimum number of workstations with the line-balancing efficiency. Everything is computed locally and deterministically, so it is instant and private. Ideal for manufacturing, smart-factory, MES, IoT-dashboard and lean/TPM app developers, production-line monitoring and continuous-improvement tools, and industrial-engineering training. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. This is OEE and takt maths; for equipment reliability/MTBF use a reliability API.

Uptime

100.0%

Latency

78ms

Subs

4,575