#construction

Railing and baluster layout maths as an API, computed locally and deterministically — the baluster-count, spacing and post numbers a deck builder, fabricator or balustrade designer sets a guardrail out with. The baluster-count endpoint gives the smallest number of balusters that keeps every gap within the safety limit: between two posts n balusters leave n+1 gaps, so the count = ceil((rail length − max gap) ÷ (baluster width + max gap)). The usual guardrail limit is a 100 mm (4-inch) sphere — a child-safety rule — so a 2000 mm rail with 40 mm balusters needs 14 of them at even 96 mm gaps; round up, because one fewer opens the gaps past the limit. The layout endpoint sets out a known count evenly: the gap = (rail length − total baluster width) ÷ (count + 1), the centre-to-centre pitch = baluster width + gap, and the first baluster's centre sits one gap plus half a baluster from the post face, so you mark the first centre and step off the pitch with the last gap landing equal to the first. The post-count endpoint sizes the frame: a run needs one more post than spans, spans = ceil(run ÷ max post spacing), posts = spans + 1, even spacing = run ÷ spans — a 6 m run at a 1.8 m max takes 4 spans and 5 posts at a tidy 1.5 m. Everything is computed locally and deterministically, so it is instant and private. Ideal for deck and balustrade design tools, fabrication and estimating apps, and building calculators. Pure local computation — no key, no third-party service, instant. Uses the common 100 mm infill rule — confirm your local code. 3 compute endpoints. For stair rise and run use a stair API; for fence pickets a fence API.

api.oanor.com/handrail-api

Circular-segment arch geometry as an API, computed locally and deterministically — the radius, arc-length and set-out numbers a mason, joiner, stonemason or CAD user lays a segmental arch out with. A segmental arch is an arc of a circle struck through the two springings and the crown: the from-span-rise endpoint takes the span and the rise (the height of the crown above the springing line) and returns the radius = (span²/4 + rise²) ÷ (2·rise), the central angle it subtends, the arc length along the curve, and the segment area of the void below it — flatter arches with a small rise have surprisingly huge radii. The from-radius-angle endpoint inverts it, returning the chord (span), the rise (sagitta), the arc length and the area from a known radius and central angle, the way a curve struck with a trammel or a router on a pivot is described. The setout-ordinates endpoint gives the practical numbers to mark a template: the rise of the arc above a straight base line at equally spaced stations across the span (y = √(R² − x²) − (R − rise)), so you can plot the heights, connect them and cut a plywood former or bend a batten without a giant compass — the ends come out zero at the springings and the middle equals the rise at the crown. Everything is computed locally and deterministically, so it is instant and private. Ideal for masonry and joinery layout tools, stair and window-head design, and CAD and woodworking calculators. Pure local computation — no key, no third-party service, instant. Segmental (up to a semicircle) arcs. 3 compute endpoints. For road curves use a horizontal- or vertical-curve API; for plain shape areas a geometry API.

api.oanor.com/arch-api

Mobile-crane lift-planning maths as an API, computed locally and deterministically — the load-moment, tipping-capacity and outrigger-pad numbers a crane operator, lift planner or rigging engineer checks a pick with. The load-moment endpoint gives the load × its working radius (the horizontal distance from the slew centre to the hook), the single figure a crane's rated-capacity limiter watches: a 5-tonne load at 8 m is a 40 tonne-metre moment, the same as 10 tonnes at 4 m, which is why chart capacity falls steeply as the boom luffs out — moment, not weight, tips the crane. The capacity endpoint gives a simplified tipping balance about the fulcrum: the load that just tips = counterweight × its radius ÷ the load radius, and the rated safe load is a stability fraction of that (~75 % on outriggers, ~66 % on crawlers per the standards) — a teaching/sanity figure that ignores the boom and superstructure, never a substitute for the load chart. The outrigger-pad endpoint sizes the float: required pad area = the outrigger leg load ÷ the soil's allowable bearing pressure (and the side of a square mat), since overloading weak ground is a leading cause of overturns — a 30-tonne leg on 200 kPa wants about a 1.2 m square mat. Everything is computed locally and deterministically, so it is instant and private. Ideal for lift-planning and rigging tools, construction and crane-operations apps, and site-safety utilities. Pure local computation — no key, no third-party service, instant. Simplified — always use the manufacturer load chart. 3 compute endpoints. For sling and WLL loads use a rigging API.

api.oanor.com/crane-api

Ladder-safety maths as an API, computed locally and deterministically — the angle, reach and load numbers that keep a ladder from sliding out or buckling. The angle endpoint applies the 4:1 rule: the base goes out one foot for every four feet of working length, which lands the ladder at about 75.5° — a 24-foot ladder sits 6 feet from the wall and reaches roughly 23 feet up, steep enough not to tip back and shallow enough not to slide. The extension endpoint gives the usable length and reach of a two-section extension ladder, which loses the overlap the sections share (3 feet up to 36, 4 to 48, 5 beyond), and the working height at the safe angle — remembering the ladder must extend 3 feet above a roof edge you step onto. The duty-rating endpoint turns a total load — your weight plus tools and materials, not just bodyweight — into the right duty class, from Type III household (200 lb) through I industrial (250) to IAA professional (375). Everything is computed locally and deterministically, so it is instant and private. Ideal for construction-safety and trades apps, jobsite and rental tools, OSHA training aids, and home-improvement sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational — always follow the manufacturer's labels and OSHA/ANSI rules.

api.oanor.com/ladder-api

Industrial and protective-coatings maths as an API, computed locally and deterministically — the film-build numbers a coatings inspector, painter or estimator works to, the ones simple paint estimating skips. The coverage endpoint gives theoretical and practical coverage from the coating's volume solids and the target dry film thickness: coverage = 1604 × the volume-solids fraction ÷ the DFT in mils, where 1604 is the square feet a gallon covers at one mil — so a 50 %-solids coating at 2 mils dry covers about 401 ft² per gallon, less a loss factor for overspray and surface profile. The film-thickness endpoint converts between wet and dry film thickness through the volume solids: WFT = DFT ÷ the solids fraction, because the solvent flashes off and the film shrinks, so a 50 %-solids coating laid 4 mils wet dries to 2 mils — the number you check with a wet-film comb as you spray. The transfer-efficiency endpoint gives the real material needed: theoretical gallons ÷ the transfer efficiency, since conventional spray lands only ~25 % on the part, HVLP ~65 %, electrostatic up to ~95 %. Everything is computed locally and deterministically, so it is instant and private. Ideal for coatings-estimating and inspection apps, industrial-painting and protective-coating tools, NACE/SSPC study aids, and spec calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For simple wall-paint area estimating use a paint API.

api.oanor.com/coating-api

HVAC duct-sizing maths as an API, computed locally and deterministically — the duct dimensions an installer or designer sizes a system with so the air moves quietly and efficiently. The round-duct endpoint gives the round duct for an airflow at a target velocity: area = airflow ÷ velocity (CFM ÷ ft/min = ft²), then diameter = √(4·area/π) — 400 CFM at a 700 fpm trunk velocity wants about a 10.2-inch round, rounded up to the next 12-inch trade size. The velocity endpoint gives the air speed inside a duct from the airflow and its size, round or rectangular — 400 CFM through a 12 × 8 duct runs at 600 fpm, comfortably quiet, while the same air in a 10-inch round moves at 733 fpm. The equivalent endpoint gives the equivalent round diameter of a rectangular duct by the ASHRAE relation De = 1.30 · (a·b)^0.625 ÷ (a+b)^0.25, so a 12 × 8 rectangular carries the same air at the same friction as a 10.7-inch round — letting you size on a round friction chart and convert to fit the space. Everything is computed locally and deterministically, so it is instant and private. Ideal for HVAC-design and installer apps, duct-sizing and takeoff tools, building-services calculators, and trade-school aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For room air changes use a ventilation API; for the cooling/heating load use an HVAC API.

api.oanor.com/ductwork-api

Chimney and flue sizing maths as an API, computed locally and deterministically — the draft and dimension numbers a stove installer, sweep or builder runs so a fire pulls cleanly and safely. The flue-size endpoint gives the minimum flue cross-section for a fireplace opening: at least a tenth of the opening area for a square or rectangular liner, a twelfth for a round one (which draws better) — a 36 × 30 inch opening needs about 108 square inches of rectangular flue, or a 10.7-inch round. The draft endpoint gives the theoretical draft from the stack effect, ΔP ≈ 3465 × height × (1/T_outside − 1/T_flue) with temperatures in kelvin, so a 6-metre chimney with 200 °C flue gas on a freezing day pulls about 32 pascals (0.13 inches of water column) — taller and hotter draws harder. The height endpoint applies the 3-2-10 rule: a chimney must finish at least 3 feet above where it pierces the roof and at least 2 feet above anything within 10 feet, whichever is higher. Everything is computed locally and deterministically, so it is instant and private. Ideal for hearth and stove-installer apps, chimney-sweep and inspection tools, building-design calculators, and DIY-safety sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational estimates — verify against your appliance listing and adopted code.

api.oanor.com/chimney-api

Plumbing-code sizing maths as an API, computed locally and deterministically — the fixture-unit and pipe-sizing numbers a plumber, designer or inspector runs from the code book. The dfu endpoint totals drainage fixture units for a set of fixtures (IPC Table 709.1): pass a list like toilet:2,lavatory:3,shower:1,kitchen_sink:1 and it weights each by its discharge — a toilet is 3, a lavatory 1, a tub or shower 2 — for a total of 13, with a grouped full bathroom counting as 6 rather than the sum of its parts. The pipe-size endpoint gives the minimum building-drain size for a DFU load at a slope (IPC Table 710.1(1)): the smallest pipe whose capacity meets the load, so 50 DFU at a quarter-inch-per-foot fall needs a 4-inch drain, with the reminder that any drain carrying a water closet is a 3-inch minimum. The supply-gpm endpoint reads probable peak water demand off the Hunter curve: diversity means 100 supply fixture units draws only about 54 GPM, not the sum of every fixture running at once — the number you size the water service against. Everything is computed locally and deterministically, so it is instant and private. Ideal for plumbing-design and estimating apps, code-check and permit tools, MEP-engineering calculators, and trade-school aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Based on the IPC — verify against the code adopted in your jurisdiction.

api.oanor.com/plumbing-api

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

api.oanor.com/caulk-api

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

api.oanor.com/adaramp-api

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.

api.oanor.com/deck-api

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.

api.oanor.com/masonry-api

Roofing geometry as an API, computed locally and deterministically. The pitch endpoint converts freely between the three ways trades describe a roof slope — the pitch as rise per 12 of run (the X:12 notation), the angle in degrees and the slope as a percentage — using angle = atan(pitch/12); a 6:12 roof is 26.57° and a 50 % slope, and it also returns the pitch multiplier √(1 + tan²) that scales a flat plan length to the true along-slope length. The rafter endpoint computes the common rafter length from the horizontal run and the pitch, rafter = √(run² + rise²) with rise = run·tan(angle), and adds the along-slope length of an optional horizontal overhang — a 12-unit run at 6:12 needs a 13.42-unit rafter. The area endpoint converts a flat building footprint into the actual sloped roof surface area, footprint / cos(angle), the figure you need to order shingles, membrane or underlay; a 100 m² footprint under a 6:12 roof is about 111.8 m². Lengths are unit-agnostic — use a consistent unit. Everything is computed locally and deterministically, so it is instant and private. Ideal for roofing, construction, contractor-estimating, home-improvement, solar-install and architecture app developers, take-off and material-ordering tools, and trade software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is roofing-specific geometry; for a general grade or gradient use a slope API.

api.oanor.com/roofpitch-api

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.

api.oanor.com/lumber-api

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.

api.oanor.com/drywall-api

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.

api.oanor.com/flooring-api

Concrete mix-design maths as an API, computed locally and deterministically. The mix endpoint breaks down a volume of concrete into its materials from a nominal mix ratio (cement:sand:aggregate, for example 1:2:4): it applies the 1.54 dry-volume allowance, then returns the cement in cubic metres, kilograms and 50 kg bags, the sand and aggregate volumes and masses, and the water from the water-cement ratio — the complete batch for the pour. The quantity endpoint computes the concrete volume of a slab, footing, or round or square column from its dimensions, adds a wastage allowance and gives the dry material volume. The watercement endpoint solves the water-cement ratio, the water or the cement from the other two — the single most important number for concrete strength and durability. Densities used are cement 1440, sand 1600 and aggregate 1450 kg/m³, with a 50 kg cement bag. Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, estimating and site-engineering tools, material take-off and ordering, DIY and builder apps, and civil-engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is nominal volume-batch concrete estimating; for retaining-wall earth pressure use an earth-pressure API.

api.oanor.com/concrete-api

Septic-system sizing as an API, computed locally and deterministically with the typical US onsite-wastewater rules of thumb. The flow endpoint estimates the design wastewater flow for a home from its number of bedrooms (assuming two people per bedroom) or an explicit occupancy, at a default 60 gallons per person per day, returning the daily flow in US gallons and litres. The tank endpoint recommends a septic tank size as the larger of a retention-based size (flow × retention days, default two days) and the typical bedroom-based code minimum (≤3 bedrooms 1,000, 4 bedrooms 1,200, 5 bedrooms 1,500, 6 bedrooms 2,000 US gallons), and tells you which one governs. The drainfield endpoint sizes the soil absorption (leach) field: it divides the daily flow by a soil loading rate — given directly or looked up from a percolation rate in minutes per inch — to get the absorption area, then divides by the trench width to get the trench length, in both imperial and metric. Everything is computed locally and deterministically, so it is instant and private. An estimating aid, not a code-stamped design — always confirm with your local health authority. Ideal for plumbing and septic-installer tools, rural real-estate and land apps, home-building and permitting calculators, and inspection software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is septic / onsite-wastewater sizing; for storage-tank volume and fill level use a tank API.

api.oanor.com/septic-api

Staircase geometry as an API, computed locally and deterministically. The calc endpoint takes the total rise (floor-to-floor height) and works out the number of steps, the exact riser height, the tread depth, the total run, the stringer (hypotenuse) length and the stair angle, and checks the result against building-code limits and the Blondel comfort rule (2 × riser + tread ≈ 24–25 in). The check endpoint validates a given riser and tread against typical US IRC limits — maximum riser 7.75 in, minimum tread 10 in — and reports the angle and comfort. The stringer endpoint returns the stringer length and angle from a total rise and total run. Dimensions are handled internally in inches but accept inches, centimetres, millimetres and metres. Everything is computed locally and deterministically, so it is instant and private. Code limits are typical US IRC values — always confirm your local building code. Ideal for construction and carpentry tools, deck and home-improvement apps, and architecture and CAD software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is staircase geometry; for paint, tile and concrete quantities use a construction-calculator API and for roof pitch use a roofing API.

api.oanor.com/stair-api

Fencing material estimating as an API, computed locally and deterministically. The posts endpoint works out the number of fence sections, line posts and rails for a run from its length and the post spacing, plus the total rail length. The pickets endpoint computes how many pickets or boards a length needs from the picket width and the gap between boards (set the gap to zero for a privacy fence). The materials endpoint produces a full bill of materials in one call — posts, rails, pickets and the concrete for the post holes, in cubic feet and metres and in 80 lb pre-mix bags — from the fence dimensions and the hole size and post depth. Everything is computed locally and deterministically, so it is instant and private. These are estimates: allow extra for waste, gates and corner posts, and follow your local building code for post depth and footing size. Picket width and gap are in inches; length can be feet, yards or metres. Ideal for fencing contractors and estimators, DIY and home-improvement tools, and landscaping and quoting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is fencing materials; for paint, tile and concrete use a construction-calculator API and for mulch and gravel use a landscaping API.

api.oanor.com/fence-api

Roofing geometry as an API, computed locally and deterministically. The pitch endpoint converts a roof pitch between every common form — rise-over-run (such as 6:12), the angle in degrees, the percent slope, and the slope multiplier (the factor that turns a flat footprint into the real sloped area). The rafter endpoint computes the rafter length from the horizontal run and the pitch — that is, the hypotenuse √(run² + rise²) — with an optional overhang projected along the slope. The area endpoint computes the true sloped roof area from the building footprint (entered directly or as length × width) and the pitch, adds a wastage allowance, and reports the number of US roofing squares and shingle bundles needed. Everything is computed locally and deterministically, so it is instant and private. Lengths are unit-agnostic — use consistent units — while the squares and bundles figures assume US roofing squares of 100 square feet, so pass the footprint in square feet for those. Ideal for roofing contractors and estimators, construction and DIY tools, solar-install planning, and quoting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is roof geometry; for paint, tile, concrete and brick quantities use a construction-calculator API.

api.oanor.com/roofing-api

Construction and material estimating as an API — the everyday "how much do I need to buy" maths for building and renovation jobs, computed locally and deterministically from standard geometry and trade rules of thumb. The paint endpoint works out the litres and number of cans for a surface, allowing for the number of coats and the paint's coverage and deducting doors and windows. The tile endpoint computes how many tiles (and full boxes) a floor or wall area needs from the tile dimensions and a wastage allowance. The concrete endpoint gives the concrete volume in cubic metres, cubic yards and litres — and the number of pre-mix bags — for a slab, footing, wall or round column, with an optional batch quantity. The bricks endpoint computes how many bricks a wall needs from the brick size and mortar joint (default 215×65 mm brick with a 10 mm joint ≈ 60 bricks per square metre). Everything is computed locally and deterministically, so it is instant and private. Ideal for builders' merchants and trade apps, DIY and home-improvement tools, quoting and estimating software, and project planners. Pure local computation — no key, no third-party service, instant. Live, nothing stored. Estimates are guidance — allow for site conditions and follow the manufacturer's stated figures. 4 endpoints. This is materials estimating; for plain unit conversion use a unit-conversion API and for tyre or drivetrain maths use a tyre API.

api.oanor.com/buildcalc-api