Anteprima del marketplace

API Marketplace

Scopri e integra le API attraverso il gateway segreto sicuro di oanor.

289–312 di 1117 API

Chicken Coop API

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

#chickens #poultry #homesteading
P da PremiumApi
Tempo di attività
100.0%
Latenza
81ms
Abbonati
4,161
Verificato dal server 9 sonde/24h

api.oanor.com/chickencoop-api

Draft Beer API

Draft-Beer-Dispenser-Mathematik als API, lokal und deterministisch berechnet – die CO₂-Druck- und Bierleitungszahlen, nach denen ein Hobbybrauer, Kegerator-Besitzer oder eine Bar einen Zapfhahn einstellt. (Dies ist die Ausschankseite; für ABV, Stammwürze und IBU handelt es sich um eine Hobbybrau-Berechnung.) Der Carbonierungs-Endpunkt liefert den Regler-Vordruck, der eine Zielcarbonierung bei Ausschanktemperatur hält, basierend auf der Standard-Volumen-Temperatur-Druck-Regression: 2,5 Volumen CO₂ bei 38 °F benötigen etwa 11 psi, und kälteres Bier hält die gleiche Carbonierung bei niedrigerem Druck – britische Ales liegen bei etwa 1,5–2,0 Volumen, US-Ales bei 2,2–2,7, Lager und Weizen höher. Der Balance-Endpunkt dimensioniert die Bierleitung, sodass das System einen sauberen Kopf ausschenkt, statt zu schäumen oder langsam zu laufen: Leitungslänge = (angelegter Druck − 0,5 × Steigung − Restdruck) ÷ Widerstand der Leitung pro Fuß, wobei die Schwerkraft etwa 0,5 psi pro Fuß Höhenunterschied hinzufügt und etwa 1 psi am Hahn verbleibt – also 12 psi ohne Steigung bei 3/16-Zoll-Vinyl (≈3 psi/ft) ergeben etwa 3,7 Fuß, während schmalere oder breitere Schläuche alles ändern. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Hobbybrau-, Kegerator-, Bar-, Brauerei-Ausschank- und Getränke-App-Entwickler, Zapfanlagen- und Fehlerbehebungstools sowie Gastronomie-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofortig. Nur Ausschankseite. Live, nichts gespeichert. 2 Compute-Endpunkte.

#draft-beer #kegerator #homebrew
P da PremiumApi
Tempo di attività
100.0%
Latenza
86ms
Abbonati
4,847
Verificato dal server 9 sonde/24h

api.oanor.com/draftbeer-api

Knife Sharpening API

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

#knife #sharpening #bevel
P da PremiumApi
Tempo di attività
100.0%
Latenza
80ms
Abbonati
3,532
Verificato dal server 12 sonde/24h

api.oanor.com/knifesharp-api

Welding Settings API

Schweißeinstellungen und Verbrauchsmaterialberechnungen als API, lokal und deterministisch berechnet – die Stromstärke-, Draht- und Gaswerte, die ein Schweißer oder Hersteller an der Maschine einstellt. (Für die Verbindungsfestigkeit gibt es eine separate Schweißfestigkeitsberechnung.) Der Stromstärke-Endpunkt liefert einen Startstrom aus der Materialdicke unter Verwendung der Faustregel für Baustahl von etwa einem Ampere pro 0,001 Zoll – eine Achtel-Zoll-Platte läuft also mit etwa 125 A, plus/minus zehn Prozent – und schlägt eine passende Elektroden- oder Drahtgröße vor. Der Abscheidungs-Endpunkt führt die MIG-Arithmetik exakt durch: Abscheidungsrate (lb/h) = Drahtvorschubgeschwindigkeit × Drahtgewicht pro Zoll × 60 × Wirkungsgrad, wobei das Gewicht pro Zoll = (π/4 · d²) × 0,284 lb/in³ für Stahl ist, also legt 0,035-Zoll-Draht bei 300 in/min etwa 4,9 lb/h zu, 4,8 abgeschieden bei 98 % – und aus einer Zielabscheidung werden die Lichtbogenzeit und die zu kaufenden Pfund Draht zurückgegeben. Der Gas-Endpunkt dimensioniert das Schutzgas: Gasverbrauch (ft³) = Durchfluss in CFH × Lichtbogenzeit in Stunden, und die Lichtbogenzeitdauer einer Flasche, also entleert 35 CFH eine 80-ft³-Flasche in etwa 2,3 Stunden tatsächlicher Lichtbogenzeit. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Schweiß-, Metallverarbeitungs-, Fertigungs- und Werkstattverwaltungs-Apps, Tools zur Auftragskalkulation und Verbrauchsplanung sowie Schweißausbildungssoftware. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Maschineneinstellungen, nicht Verbindungsfestigkeit. Live, nichts wird gespeichert. 3 Compute-Endpunkte.

#welding #fabrication #metalwork
P da PremiumApi
Tempo di attività
100.0%
Latenza
76ms
Abbonati
4,220
Verificato dal server 12 sonde/24h

api.oanor.com/welding-api

Screen Printing API

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

#screen-printing #apparel #printing
P da PremiumApi
Tempo di attività
100.0%
Latenza
79ms
Abbonati
3,682
Verificato dal server 12 sonde/24h

api.oanor.com/screenprint-api

Leathercraft API

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

#leather #leathercraft #saddlery
P da PremiumApi
Tempo di attività
100.0%
Latenza
72ms
Abbonati
4,545
Verificato dal server 12 sonde/24h

api.oanor.com/leather-api

Climbing Grade API

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

#climbing #bouldering #grades
P da PremiumApi
Tempo di attività
100.0%
Latenza
76ms
Abbonati
3,760
Verificato dal server 9 sonde/24h

api.oanor.com/climbgrade-api

Spoke Length & Wheel API

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

#cycling #wheelbuilding #spoke
P da PremiumApi
Tempo di attività
100.0%
Latenza
79ms
Abbonati
4,173
Verificato dal server 9 sonde/24h

api.oanor.com/spokelength-api

Resin & Epoxy API

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

#resin #epoxy #casting
P da PremiumApi
Tempo di attività
100.0%
Latenza
74ms
Abbonati
4,314
Verificato dal server 12 sonde/24h

api.oanor.com/resin-api

Home Canning API

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

#canning #food-preservation #homesteading
P da PremiumApi
Tempo di attività
100.0%
Latenza
83ms
Abbonati
4,575
Verificato dal server 12 sonde/24h

api.oanor.com/canning-api

Log Scaling & Timber API

Log-Scaling- und Holzmathematik als API, lokal und deterministisch berechnet – die Brettfuß-Ausbeute und das Kubikvolumen, die ein Holzfäller, Säger oder Förster mit einem Rundholz skaliert. Der Boardfeet-Endpunkt führt die drei klassischen Log-Regeln gleichzeitig aus, basierend auf dem kleinen Enddurchmesser unter Rinde und der Länge: Doyle = ((D − 4) ÷ 4)² × L, Scribner Decimal C ≈ (0,79·D² − 2·D − 4) × L ÷ 16 und die Internationale ¼-Zoll-Regel durch exakte Vier-Fuß-Segmente mit einem halben Zoll Toleranz für die Verjüngung, gerundet auf die nächsten 5 Brettfuß – so ergibt ein 20-Zoll-, 16-Fuß-Log 256 BF nach Doyle, 272 nach Scribner und 320 nach International, was deutlich zeigt, dass Doyle kleine Logs unterschätzt, International am genauesten ist und Scribner dazwischen liegt. Der Volume-Endpunkt gibt den Kubikinhalt nach Smalians Formel – dem Durchschnitt der beiden Endquerschnittsflächen mal Länge – und Hubers Formel – der mittleren Querschnittsfläche mal Länge, normalerweise die genaueste – sowohl in Kubikfuß als auch in Cords (128 ft³ = 1 Cord). Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Forst-, Holzeinschlags-, Sägewerks-, Timber-Cruising- und Landmanagement-Apps, Log-Käufer- und Holzwertermittlungstools sowie Holzplatzrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Imperiale Forsteinheiten. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Für gesägte Brettfuß verwenden Sie eine Lumber-API.

#forestry #logging #sawmill
P da PremiumApi
Tempo di attività
100.0%
Latenza
86ms
Abbonati
4,210
Verificato dal server 9 sonde/24h

api.oanor.com/logscale-api

Pet Food & Calorie API

Haustier-Ernährungsmathematik als API, lokal und deterministisch berechnet – die Kalorien-, Portions- und Wasserzahlen, die ein Hunde- oder Katzenbesitzer, Züchter oder eine Haustier-App einem Tier füttert. Der Kalorien-Endpunkt verwendet die Standard-Tierarztformel: Ruheenergie RER = 70 × (Körpergewicht in kg)^0,75, dann täglicher Erhaltungsbedarf MER = RER × einem Lebensstadium-Faktor – 1,6 für einen kastrierten erwachsenen Hund, 1,2 für eine kastrierte Katze, 1,0 oder 0,8 für Gewichtsverlust, 2–3 für Welpen und 2,5 für Kätzchen – also benötigt ein 10 kg kastrierter Hund etwa 394 kcal in Ruhe und 630 kcal pro Tag, und eine 5 kg kastrierte Katze etwa 234 und 281. Gewicht wird in kg oder Pfund angegeben, und ein benutzerdefinierter Faktor überschreibt die Tabelle. Der Portions-Endpunkt wandelt diesen Kalorienbedarf in Futter um: tägliche Gramm = Kalorien ÷ Energiedichte des Futters (kcal pro 100 g, oft 350–450 für Trockenfutter) oder Tassen ÷ kcal pro Tasse, aufgeteilt auf Mahlzeiten – also 630 kcal eines 375-kcal/100 g Trockenfutters sind etwa 168 g pro Tag, 84 g pro Mahlzeit. Der Wasser-Endpunkt gibt den täglichen Bedarf an, etwa 50–60 ml pro kg für Hunde und 50 für Katzen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Haustierpflege-, Tierarzt-, Tierfutter-, Hunde- und Katzen-Apps, Futterrechner- und Haustiergesundheits-Tools sowie Züchter-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Pädagogische Schätzungen, keine tierärztliche Beratung. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Für die Umrechnung des Hundealters verwenden Sie eine andere API.

#pet #dog #cat
P da PremiumApi
Tempo di attività
100.0%
Latenza
74ms
Abbonati
4,208
Verificato dal server 12 sonde/24h

api.oanor.com/petfood-api

Alcohol & ABV API

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

#abv #cocktail #alcohol
P da PremiumApi
Tempo di attività
100.0%
Latenza
77ms
Abbonati
4,305
Verificato dal server 12 sonde/24h

api.oanor.com/abv-api

Sailing & Hull Design API

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

#sailing #boating #marine
P da PremiumApi
Tempo di attività
100.0%
Latenza
72ms
Abbonati
4,058
Verificato dal server 12 sonde/24h

api.oanor.com/sailing-api

Archery & Arrow API

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

#archery #bowhunting #arrow
P da PremiumApi
Tempo di attività
100.0%
Latenza
75ms
Abbonati
3,709
Verificato dal server 12 sonde/24h

api.oanor.com/archery-api

Pottery & Ceramics API

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

#pottery #ceramics #glaze
P da PremiumApi
Tempo di attività
100.0%
Latenza
97ms
Abbonati
4,807
Verificato dal server 12 sonde/24h

api.oanor.com/pottery-api

Deck Builder 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.

#deck #construction #contractor
P da PremiumApi
Tempo di attività
100.0%
Latenza
77ms
Abbonati
4,490
Verificato dal server 12 sonde/24h

api.oanor.com/deck-api

Propane & LPG Tank API

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

#propane #lpg #energy
P da PremiumApi
Tempo di attività
100.0%
Latenza
80ms
Abbonati
4,756
Verificato dal server 12 sonde/24h

api.oanor.com/propane-api

Barbell & Lifting API

Barbell- und Gewichtheber-Mathematik als API, lokal und deterministisch berechnet – die Plattenbeladungs- und Prozentzahlen, die ein Lifter, Trainer oder eine Fitness-App an der Hantelbank ausrechnet. Der Platten-Endpunkt löst das alltägliche Rätsel im Fitnessstudio, welche Platten auf jeder Seite für ein Zielgewicht aufgelegt werden müssen: 100 kg auf einer Standard-20-kg-Stange bedeuten 40 kg pro Seite, zuerst die schwersten als 25er und 15er; 102,5 kg fügt die 1,25-Mikroplatte hinzu; und wenn ein Ziel mit den vorhandenen Platten nicht erreichbar ist, lädt es die nächstmögliche Kombination und teilt das Defizit mit, sodass Sie nie raten müssen. Es funktioniert in Kilogramm oder Pfund (225 lb auf einer 45-lb-Stange sind zwei 45er pro Seite), mit einem benutzerdefinierten Stangengewicht und einem benutzerdefinierten Plattensatz. Der Prozent-Endpunkt wandelt ein One-Rep-Max in das tatsächlich zu ladende Arbeitsgewicht um: 80 % eines 100-kg-Maximums sind 80 kg, und die Abfrage eines Fünf-Wiederholungs-Gewichts ergibt etwa 85,7 kg über die Epley-Formel (1RM = Gewicht × (1 + Wiederholungen ÷ 30)) – fünf Wiederholungen liegen nahe 86 % des Maximums, zehn Wiederholungen nahe 75 %. Der Aufwärm-Endpunkt baut eine Rampe von der leeren Stange bis zum Arbeitssatz bei etwa 40, 55, 70 und 85 %, jede auf einen ladbaren Schritt gerundet, wobei die Wiederholungszahl sinkt, wenn die Stange schwerer wird. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Entwickler von Fitnessstudio-, Krafttrainings-, Powerlifting- und Fitness-Apps, Workout-Logger und Coaching-Tools sowie für Entwickler von intelligenten Hantelbänken und Plattenrechnern. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Exakte Mathematik, keine Simulation. Live, nichts gespeichert. 3 Compute-Endpunkte. Für die Schätzung des One-Rep-Max aus einem Satz verwenden Sie eine Strength-API.

#barbell #weightlifting #gym
P da PremiumApi
Tempo di attività
100.0%
Latenza
80ms
Abbonati
4,560
Verificato dal server 12 sonde/24h

api.oanor.com/barbell-api

Dice Probability API

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

#dice #probability #ttrpg
P da PremiumApi
Tempo di attività
100.0%
Latenza
74ms
Abbonati
3,594
Verificato dal server 12 sonde/24h

api.oanor.com/dicepool-api

Catering & Party API

Catering- und Partyplanungs-Mathematik als API, lokal und deterministisch berechnet – die Wie-viel-kaufe-ich-Zahlen, mit denen ein Gastgeber oder Caterer eine Personenzahl plant. Der Food-Endpunkt skaliert ein Menü auf die Gästeanzahl und den Appetit: das Hauptprotein mit etwa einem halben Pfund gegartem Fleisch pro Person (leicht 0,33, herzhaft 0,75), jede Beilage mit etwa vier Unzen pro Kopf, sechs Appetizer-Stücke pro Person und eineinhalb Dinner-Brötchen – also benötigen 50 Gäste bei einem Standard-Dinner mit drei Beilagen 25 Pfund Fleisch, 300 Appetizer und 75 Brötchen. Der Drinks-Endpunkt dimensioniert die Bar: etwa ein Getränk pro Gast pro Stunde plus ein Extra in der ersten Stunde, aufgeteilt auf Bier, Wein und Cocktails und umgerechnet in die realen Einheiten, die man kauft – Bier im Kasten (24) und im Fass (~165 Portionen), Wein in der Flasche (~5 Gläser), Spirituosen in der 750-ml-Flasche (~16 Shots) – plus das Eis (etwa 1,5 Pfund pro Gast) und Wasser; eine Party mit 50 Gästen und vier Stunden kommt auf 250 Getränke, 125 Biere (0,76 eines Fasses), 15 Flaschen Wein und 75 Pfund Eis. Alles wird lokal und deterministisch berechnet, also ist es sofortig und privat. Ideal für Eventplanungs-, Catering-, Hospitality- und Party-App-Entwickler, Einkaufslisten- und Personenzahl-Tools sowie Gastgeber-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofortig. US-Einheiten; Faustregeln – aufrunden. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Anpassung an die Menge und die Jahreszeit.

#catering #party-planning #event
P da PremiumApi
Tempo di attività
100.0%
Latenza
78ms
Abbonati
4,088
Verificato dal server 9 sonde/24h

api.oanor.com/catering-api

D&D Encounter API

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

#dnd #5e #encounter
P da PremiumApi
Tempo di attività
100.0%
Latenza
74ms
Abbonati
3,707
Verificato dal server 12 sonde/24h

api.oanor.com/dndencounter-api

Darts API

Darts-Scoring-Mathematik als API, lokal und deterministisch berechnet – die X01-Checkout- und Durchschnittszahlen, die ein Dartsspieler, eine Liga oder eine Scoring-App verwendet. Der Checkout-Endpunkt löst eine verbleibende Punktzahl mit einer exakten Full-Board-Suche: ob sie beendet werden kann, die minimale Anzahl an Darts und eine gültige Kombination, die auf einem Double oder dem Bull endet – 170 Finish T20 T20 Bull (der höchstmögliche Three-Dart-Checkout), 100 ist T20 D20, 40 ist einfach D20, während 1 nicht beendet werden kann (der letzte Dart muss ein Double sein, mindestens 2) und die Bogey-Zahlen 169, 168, 166, 165, 163, 162 und 159 können in drei Darts überhaupt nicht gecheckt werden. Der Average-Endpunkt berechnet den Three-Dart-Average – Gesamtpunktzahl ÷ Darts × 3 – also 501 in 15 Darts ergibt einen Average von 100,2; ein Average über 100 ist starkes Spiel. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Darts-, Liga-Scoring-, Pub-Spiel- und Sport-App-Entwickler, Checkout-Assistenten und Übungstools sowie Darts-Ausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Standard X01-Regeln; Legs enden auf einem Double oder dem Bull. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Eine exakte Scoring-Hilfe für das Standard-20-Segment-Board.

#darts #checkout #x01
P da PremiumApi
Tempo di attività
100.0%
Latenza
76ms
Abbonati
4,296
Verificato dal server 9 sonde/24h

api.oanor.com/darts-api