API marketplace

Data-transfer and bandwidth maths as an API, computed locally and deterministically. The time endpoint computes how long a file takes to transfer at a given bandwidth, time = file bits ÷ (rate × (1 − overhead)), accepting sizes in B, KB, MB, GB, TB or the binary KiB/MiB/GiB and rates in bps, Kbps, Mbps, Gbps or bytes-per-second (MB/s), with an optional protocol-overhead allowance, and returns the time in seconds, minutes, hours and a human-readable form. The bandwidth endpoint works backwards: the bandwidth needed to move a file within a target time, in bps, Mbps, Gbps and MB/s. The convert endpoint converts a data size between decimal (1 MB = 1,000,000 bytes) and binary (MiB = 1,048,576) units, or a data rate between bit-rates and byte-rates. Everything is computed locally and deterministically, so it is instant and private. Ideal for networking, cloud, backup and streaming app developers, download-time and capacity-planning tools, and dev dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is transfer time and bandwidth; for media encoding bitrate use a bitrate API.

Uptime

100.0%

Latency

80ms

Subs

3,566

Inferential-statistics maths as an API, computed locally and deterministically. The samplesize endpoint computes how many respondents a survey or experiment needs for a proportion, n = Z²·p(1−p)/E², from a confidence level and a margin of error (using p = 0.5 for the most conservative size), with a finite-population correction when the population is known. The confidence endpoint builds a confidence interval for a mean (estimate ± Z·σ/√n) or a proportion (p ± Z·√(p(1−p)/n)), returning the standard error, margin of error and the lower and upper bounds. The ztest endpoint runs a one-sample z-test, z = (x̄ − μ₀)/(σ/√n), and returns the z-score, the one- or two-tailed p-value and whether the result is significant at the chosen alpha. The z-scores come from an exact inverse-normal and the p-values from the normal CDF. Everything is computed locally and deterministically, so it is instant and private. Ideal for A/B-testing, survey, research and analytics app developers, experiment dashboards and data-science tools, and education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is inferential statistics; for descriptive statistics use a statistics API and for probability distributions use a probability API.

Uptime

100.0%

Latency

80ms

Subs

4,030

Descriptive-statistics maths as an API, computed locally and deterministically. The descriptive endpoint summarises a list of numbers — the count, sum, mean, median, mode, minimum, maximum and range, the population and sample variance and standard deviation, and the quartiles Q1/Q2/Q3 with the interquartile range by Tukey's method. The correlation endpoint computes the Pearson correlation coefficient r between two equal-length series — from −1 (perfect inverse) through 0 (none) to +1 (perfect direct) — along with R² and the covariance. The regression endpoint fits a least-squares line y = a + b·x, returning the slope, intercept and R², the equation, and an optional prediction for a given x. Data is accepted as a JSON array or a comma-separated list. Everything is computed locally and deterministically, so it is instant and private. Ideal for data-analysis, dashboard, research and education app developers, reporting and BI tools, and spreadsheet replacements. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is descriptive statistics; for probability distributions and combinatorics use a probability API.

Uptime

100.0%

Latency

74ms

Subs

4,403

Digital-marketing metrics maths as an API, computed locally and deterministically. The ads endpoint computes campaign KPIs from any two of the spend, impressions, clicks and conversions: the CPM (cost per thousand impressions), the CPC (cost per click), the CTR (click-through rate), the conversion rate and the CPA (cost per acquisition). The roas endpoint computes the return on ad spend, ROAS = revenue ÷ spend, the ROI percentage and the gross profit, and — given a gross margin — the break-even ROAS of 1 ÷ margin. The ltv endpoint computes the customer lifetime value, average order value × purchase frequency × lifespan × gross margin, and, with the marketing spend and number of new customers, the customer acquisition cost, the all-important LTV:CAC ratio and the CAC payback period in months. Everything is computed locally and deterministically, so it is instant and private. Ideal for marketing, advertising, e-commerce and growth app developers, campaign dashboards and reporting tools, and agency calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is marketing-metrics maths; for percentage maths use a percentage API and for currency conversion use a currency API.

Uptime

100.0%

Latency

91ms

Subs

3,880

Personal-savings planning maths as an API, computed locally and deterministically. The future endpoint computes the future value of regular saving — FV = initial·(1+r)^n + deposit·((1+r)^n − 1)/r with the rate compounded monthly — and breaks it into the total you put in and the interest earned. The goal endpoint works backwards: the monthly deposit needed to reach a target by a date, (target − initial·(1+r)^n)·r / ((1+r)^n − 1), and tells you when an initial sum already grows to the target by itself. The emergency endpoint sizes an emergency fund as a number of months of expenses (3–6 is the usual advice), reports the shortfall against current savings and, with a monthly saving amount, how many months it takes to get there. Everything is computed locally and deterministically, so it is instant and private. Ideal for personal-finance, budgeting and fintech app developers, savings-goal and money-coaching tools, and banking dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates, not financial advice. 3 endpoints. This is savings planning; for loans and mortgages use a loan API and for NPV/IRR use a finance-calc API.

Uptime

100.0%

Latency

83ms

Subs

3,249

Asset-depreciation maths as an API, computed locally and deterministically, returning the full year-by-year schedule. The straight-line endpoint spreads the depreciable amount evenly, annual = (cost − salvage) / life, with the book value falling to the salvage value over the asset life. The declining-balance endpoint is accelerated — each year depreciates the current book value times factor/life (a factor of 2 is the double-declining method) — and it is capped so the book value never drops below salvage. The sum-of-years-digits endpoint is also accelerated, front-loading the expense: year t depreciates (remaining life / SYD) × (cost − salvage), where SYD = n(n+1)/2. Each method returns the depreciation, accumulated depreciation and book value for every year. Everything is computed locally and deterministically, so it is instant and private. Ideal for accounting, ERP, asset-management and bookkeeping app developers, fixed-asset registers, and finance dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. General accounting maths — tax rules such as MACRS differ by jurisdiction. 3 endpoints. This is asset depreciation; for NPV and IRR use a finance-calc API and for loans use a loan API.

Uptime

100.0%

Latency

76ms

Subs

3,172

Lumber and framing material-estimation maths as an API, computed locally and deterministically. The boardfeet endpoint computes board feet — the standard volume unit for sawn timber, (thickness_in × width_in × length_ft) ÷ 12 — for a quantity of boards, with the total board feet and linear feet. The studs endpoint frames a wall: the number of vertical studs, ceil(wall length ÷ spacing) + 1 (16-inch ≈ 0.4064 m or 24-inch ≈ 0.6096 m centres), with two extra studs per opening, plus the plate boards for the top and bottom plates. The cost endpoint totals the lumber either by board foot (board feet × price per board foot) or by piece (pieces × price per piece). Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, carpentry and DIY app developers, framing and material take-off tools, and lumberyard and builder calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is lumber and framing estimation; for drywall sheets use a drywall API and for concrete use a concrete API.

Uptime

100.0%

Latency

81ms

Subs

4,756

Drywall (plasterboard) material-estimation maths as an API, computed locally and deterministically. The sheets endpoint computes how many boards a wall or ceiling needs — the area (given directly, or as perimeter × height, or length × width) divided by the sheet area, with a waste allowance — and the number of screws (about 32 per standard sheet). The compound endpoint estimates the joint compound in kilograms and the joint tape in metres for taping and finishing the boarded area, with adjustable per-square-metre factors for your product and number of coats. The cost endpoint totals the project from the sheets and their price plus the compound and tape. The standard 2.4 × 1.2 m board is assumed unless you override it. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, renovation and trade app developers, drywall and plastering estimators, and builder and retailer tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is drywall material estimation; for insulation R-values use a U-value API and for wall paint use a paint API.

Uptime

100.0%

Latency

81ms

Subs

3,893

Wallpaper-estimating maths as an API, computed locally and deterministically. The rolls endpoint uses the proper drop method: it works out how many full-height drops come from each roll, floor(roll length ÷ (wall height + pattern repeat)), how many drops the room perimeter needs, ceil(perimeter ÷ roll width), and from those the rolls required — so a larger pattern repeat correctly increases the count. The simple endpoint gives a quick area-based estimate, rolls = ceil(wall area·(1+waste) ÷ roll coverage), handy for plain papers. The cost endpoint totals the project from the rolls and price per roll plus the adhesive, with one tub of paste hanging about five rolls. The standard roll of 10.05 m × 0.53 m is assumed unless you override it. Everything is computed locally and deterministically, so it is instant and private. Ideal for home-decor, renovation and trade app developers, DIY and room-planning tools, and decorator and retailer calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is wallpaper estimation; for wall paint use a paint API and for floor tiles use a flooring API.

Uptime

100.0%

Latency

83ms

Subs

4,222

Flooring and tiling material-estimation maths as an API, computed locally and deterministically. The tile endpoint computes how many tiles a floor needs — the floor area (given directly or as length × width) divided by the tile area, with a waste allowance for cuts and breakage (10 % by default) — and, given the tiles per box, how many boxes to buy. The packs endpoint sizes laminate, vinyl or carpet from the coverage printed on each pack: packs = ceil(area·(1+waste) / coverage per pack), with the total coverage supplied. The grout endpoint estimates the grout in kilograms for a tiled area from the tile size, the joint width and the tile thickness, ((A+B)/(A·B))·joint·thickness·density per square metre. Everything is computed locally and deterministically, so it is instant and private. Ideal for home-improvement, renovation and trade app developers, DIY and material-ordering tools, and builder and retailer calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is floor-covering estimation; for wall paint use a paint API, for roofing use a roofing API and for concrete use a concrete API.

Uptime

100.0%

Latency

81ms

Subs

4,281

Inventory-management maths as an API, computed locally and deterministically. The eoq endpoint computes the economic order quantity, EOQ = √(2·D·S/H) from the annual demand, the cost per order and the holding cost per unit per year — the order size that minimises total cost — and returns the number of orders per year, the days between orders and the annual ordering, holding and total costs (which are equal at the EOQ). The reorder endpoint computes the reorder point, daily demand × lead time + safety stock, the stock level at which to place the next order. The safety endpoint computes the safety stock for a target service level, Z × σ × √lead_time, where Z is the normal-distribution value for the service level (95 % gives 1.645) found by an exact inverse-normal calculation, so any service level works. Everything is computed locally and deterministically, so it is instant and private. Ideal for e-commerce, retail, warehouse and supply-chain app developers, stock-planning and procurement tools, and operations dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is inventory optimisation; for break-even and cost-volume-profit use a break-even API.

Uptime

100.0%

Latency

79ms

Subs

3,606

Break-even and cost-volume-profit maths as an API, computed locally and deterministically. The breakeven endpoint computes the break-even point of a product — the units you must sell to cover all costs, fixed costs ÷ (price − variable cost) — together with the break-even revenue, the contribution margin per unit and the contribution-margin ratio. The target endpoint computes the units and revenue needed to reach a target profit, (fixed costs + target profit) ÷ contribution margin. The margin-of-safety endpoint takes an actual sales level (in units or revenue) and returns the margin of safety — how far sales can fall before a loss — both in units and as a percentage, plus the profit at that level. Everything is computed locally and deterministically, so it is instant and private. Ideal for business, startup and finance app developers, pricing and product-planning tools, and small-business and accounting dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is cost-volume-profit analysis; for per-unit margin and markup pricing use a margin API.

Uptime

100.0%

Latency

79ms

Subs

3,686

Predicted-adult-height maths as an API, computed locally and deterministically. The midparental endpoint applies the Tanner mid-parental method — for a boy (father + mother + 13)/2 and for a girl (father + mother − 13)/2 in centimetres — and returns the target height together with the ±8.5 cm range within which most children fall. The double endpoint uses the well-known rule of thumb that a child's adult height is about twice their height at age two. The remaining endpoint takes a child's current height and a predicted adult height (given directly or worked out from the parents) and returns the remaining growth and the percentage of adult height already reached. Everything is computed locally and deterministically, so it is instant and private. Ideal for parenting, paediatric and family-health app developers, growth-tracking and milestone tools, and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Population estimates with wide individual variation — not medical advice. 3 endpoints. This is adult-height prediction; for BMI and body composition use a BMI API.

Uptime

100.0%

Latency

80ms

Subs

3,563

Trailer-towing weight maths as an API, computed locally and deterministically. The tongue endpoint computes the tongue (hitch) weight as a percentage of the loaded trailer weight and reports the recommended 10–15 % range — too little tongue weight is the main cause of trailer sway. The capacity endpoint computes the maximum trailer weight a tow vehicle can pull, GCWR − curb weight − payload (the passengers and cargo in the vehicle), and checks a proposed trailer against it with the margin remaining. The payload endpoint computes the vehicle payload still available once the trailer is hitched, GVWR − curb weight − tongue weight, since the tongue weight presses down on the tow vehicle and counts against its payload rating. Everything is computed locally and deterministically, so it is instant and private. Ideal for RV, caravan, trailer and fleet apps, tow-vehicle matching and load-planning tools, and automotive calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Guidance only — follow the manufacturer's ratings. 3 endpoints. This is trailer-towing weights; for tyre size and rolling circumference use a tyre API.

Uptime

100.0%

Latency

80ms

Subs

3,655

Exercise calorie-burn maths as an API, computed locally and deterministically with the MET (metabolic-equivalent) method. The activity endpoint computes the calories burned by an activity, calories = MET × weight × hours, taking the MET value directly or from a named-activity table (walking, running, cycling, swimming, HIIT, rowing, yoga, weightlifting and more), and returns the calories per minute. The steps endpoint turns a step count into distance and calories: the stride is estimated from height (about 0.415 × height for walking, 0.65 for running), the distance is steps × stride, and the energy is the distance times bodyweight times a net cost of roughly 0.5 kcal/kg/km walking or 1.0 running. The duration endpoint works backwards, giving the minutes of an activity needed to burn a target number of calories. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, activity-tracking and weight-management app developers, workout and step-counter tools, and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only. 3 endpoints. This is activity energy expenditure; for resting metabolism and TDEE use a BMR API.

Uptime

100.0%

Latency

82ms

Subs

3,732

Hydration and fluid-balance maths as an API, computed locally and deterministically. The daily endpoint estimates the daily fluid need from bodyweight (about 35 ml per kilogram), the minutes of exercise (about 12 ml per minute) and the climate (hot adds 500 ml, very hot 1000 ml, cold subtracts 200 ml), reported in millilitres, litres and 250 ml glasses. The sweat endpoint computes the sweat rate and the degree of dehydration from a before-and-after body weight, the fluid drunk and the duration — sweat loss = (pre − post) + intake − urine, with 1 kg of lost mass treated as 1 litre, and it flags when losses pass the 2 % of body mass where performance falls off. The rehydrate endpoint computes the post-exercise rehydration target, about 1.5 times the fluid deficit to cover ongoing urine losses, with a sodium note for larger losses. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, sports and wellness app developers, endurance-training and hydration-reminder tools, and health dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. General guidance, not medical advice. 3 endpoints. This is fluid balance; for basal calories use a BMR API and for heart-rate zones use a heart-rate API.

Uptime

100.0%

Latency

77ms

Subs

4,678

Aerobic-capacity (VO2 max) estimation as an API, computed locally and deterministically. The cooper endpoint estimates VO2 max from the Cooper 12-minute run test, VO2max = (distance − 504.9)/44.73, from the distance covered in twelve minutes. The resting endpoint uses the resting heart-rate (Uth-Sørensen) method, VO2max = 15.3 × (HRmax/HRrest), with the maximum heart rate taken directly or as 220 − age — a lower resting pulse signals better fitness. The rockport endpoint applies the Rockport one-mile walk test, a multiple-regression formula on age, weight, sex, walk time and the heart rate at the finish, the most accessible sub-maximal field test. Each result comes with a broad fitness rating from poor to superior and the value in mL/kg/min. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, running and endurance-training app developers, coaching and assessment tools, sports-science and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is aerobic-capacity estimation; for heart-rate zones use a heart-rate API and for basal metabolism use a BMR API.

Uptime

100.0%

Latency

79ms

Subs

4,112

Body-composition maths as an API, computed locally and deterministically. The bmi endpoint computes the body mass index, BMI = weight/height², classifies it on the WHO scale (underweight, normal, overweight, obese) and returns the healthy weight range for the person's height. The idealweight endpoint computes the ideal body weight by the four classic formulas — Devine, Robinson, Miller and Hamwi — each a base weight plus an increment for every inch of height above five feet, and their average. The bodyfat endpoint estimates body-fat percentage by the US Navy circumference method from the neck and waist (and hip for women) and the height, classifies it from essential to high, and — given a weight — splits it into fat mass and lean mass. Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, health and wellness app developers, body-tracking and coaching tools, gym and clinic dashboards, and self-assessment apps. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is body composition; for basal metabolic rate and calories use a BMR API.

Uptime

100.0%

Latency

73ms

Subs

3,780

Energy-expenditure and nutrition maths as an API, computed locally and deterministically. The bmr endpoint computes the basal metabolic rate — the calories the body burns at rest — from weight, height, age and sex, using the modern Mifflin-St Jeor equation (BMR = 10·kg + 6.25·cm − 5·age + 5 for men, −161 for women) and reporting the classic revised Harris-Benedict value alongside for comparison. The tdee endpoint computes the total daily energy expenditure, TDEE = BMR × an activity factor from sedentary (1.2) to very active (1.9), and the goal calories for maintenance, mild and standard weight loss and weight gain — a 500 kcal/day deficit or surplus is about 0.45 kg per week. The macros endpoint splits a calorie target into protein, fat and carbohydrate grams, with protein set per kilogram of bodyweight (4 kcal/g protein and carbs, 9 kcal/g fat). Everything is computed locally and deterministically, so it is instant and private. Ideal for fitness, nutrition and health-app developers, diet and meal-planning tools, gym and coaching apps, and wellness dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates only, not medical advice. 3 endpoints. This is metabolic-rate and calorie maths; for body-mass-index use a BMI calculator.

Uptime

100.0%

Latency

73ms

Subs

4,047

Gear-train ratio, speed and torque maths as an API, computed locally and deterministically. The ratio endpoint computes the gear ratio of a single pair from the driver and driven tooth counts (or pitch diameters), ratio = N_driven/N_driver, classifies it as a reduction (more torque, less speed) or an overdrive, and — given an input speed and torque — returns the output speed (input/ratio) and the output torque (input·ratio·efficiency). The train endpoint computes a compound gear train: the overall ratio is the product of the individual stage ratios, and it returns each stage ratio, the output speed and torque, noting that idler gears change only the direction of rotation, not the ratio. The solve endpoint finds the missing one of the input speed, the output speed and the ratio from the other two — for example, the ratio needed to drop a 1500 rpm motor to a 500 rpm output. Everything is computed locally and deterministically, so it is instant and private. Ideal for drivetrain, robotics and machine-design tools, gearbox and transmission selection, bicycle and vehicle gearing, and mechanical-engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is gear-train ratio and torque; for spur-gear tooth geometry use a spur-gear API.

Uptime

100.0%

Latency

74ms

Subs

3,511

Colligative-properties maths for solutions as an API, computed locally and deterministically. The osmotic endpoint computes the osmotic pressure by the van 't Hoff equation, π = i·M·R·T, from the molarity, the temperature and the van 't Hoff factor (the number of dissolved particles per formula unit — 1 for sugar, 2 for NaCl, 3 for CaCl₂), reported in atmospheres, bar and kilopascals, and also solves the molarity back from a measured pressure. The freezing endpoint computes the freezing-point depression, ΔTf = i·Kf·m, from the molality and the cryoscopic constant (1.86 °C·kg/mol for water), and the new freezing point. The boiling endpoint computes the boiling-point elevation, ΔTb = i·Kb·m, from the ebullioscopic constant (0.512 °C·kg/mol for water), and the new boiling point. Everything is computed locally and deterministically, so it is instant and private. Ideal for chemistry, biology and food-science tools, reverse-osmosis and desalination estimates, antifreeze and de-icing formulation, lab and education apps. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is colligative-properties chemistry; for solution dilution use a dilution API and for pH and buffers use a pH API.

Uptime

100.0%

Latency

79ms

Subs

4,006

Particle settling-velocity maths as an API, computed locally and deterministically. The stokes endpoint computes the terminal settling velocity of a small spherical particle by Stokes' law, vt = (ρp − ρf)·g·d²/(18·μ), from the particle diameter and density, the fluid density and the dynamic viscosity, and checks the particle Reynolds number to tell you whether the creeping-flow assumption (Re < 1) still holds — a negative velocity means a buoyant particle that rises. The terminal endpoint computes the drag-based terminal velocity for larger, faster particles, vt = √(4·g·d·(ρp − ρf)/(3·Cd·ρf)), from a drag coefficient (≈0.44 in the turbulent Newton regime). The time endpoint computes the time for a particle to settle through a given depth, t = height/vt, taking the velocity directly or deriving it from the particle properties via Stokes. Everything is computed locally and deterministically, so it is instant and private. Ideal for water- and wastewater-treatment, mineral-processing and environmental-engineering tools, clarifier and settling-tank design, sediment and aerosol analysis, and engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is particle sedimentation; for pipe-flow Reynolds/Froude/Mach numbers use a Reynolds API.

Uptime

100.0%

Latency

78ms

Subs

4,135

Heating and cooling degree-day maths as an API, computed locally and deterministically. The daily endpoint computes the heating degree days, HDD = max(0, base − mean), and the cooling degree days, CDD = max(0, mean − base), for a single day from a base temperature and the daily mean — or the minimum and maximum, since the mean is taken as their average. The period endpoint sums the degree days over a list of daily temperatures (means or min/max pairs), returning the total HDD and CDD, the count of heating and cooling days and the average temperature — the standard way to characterise a heating or cooling season. The energy endpoint turns degree days into an energy estimate: the heat delivered is UA·DD·24/1000 kWh from the building heat-loss coefficient, the fuel or electricity input is that divided by the boiler efficiency (or a heat-pump COP), and — with an energy price — the cost. Everything is computed locally and deterministically, so it is instant and private. Ideal for building-energy, HVAC and facilities tools, heating-bill and fuel-budget estimation, weather-normalisation and energy-benchmarking apps, and engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is degree-day demand estimation; for U-value and heat-loss fabric calculations use a U-value API.

Uptime

100.0%

Latency

81ms

Subs

3,467

Belt-conveyor design maths as an API, computed locally and deterministically. The capacity endpoint computes the throughput of a belt conveyor — the volumetric capacity Q = A·v·3600 (m³/h) from the belt cross-section and speed, and the mass capacity Q·ρ/1000 (t/h) from the bulk density — and, when only the belt width is given, estimates the cross-section as A ≈ load_factor·width². The power endpoint computes the drive power as the sum of the horizontal friction power, μ·g·(material + 2·belt + idler mass per metre)·length·speed, and the vertical lift power, ṁ·g·height, then divides by the drive efficiency to give the motor power. The tension endpoint computes the belt tensions from the effective tension Te = P/v: the tight-side tension T1 = Te·e^(μθ)/(e^(μθ)−1) and the slack-side tension T2 = T1 − Te, using the Euler-Eytelwein grip of the belt on the drive pulley. Everything is computed locally and deterministically, so it is instant and private. Ideal for bulk-materials-handling, mining and plant-design tools, conveyor selection and motor sizing, and mechanical-engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is a simplified belt-conveyor model; for rope/belt capstan friction use a capstan API and for belt-drive geometry use a belt-drive API.

Uptime

100.0%

Latency

80ms

Subs

4,207