Marktplatz-Vorschau

API-Marktplatz

Entdecke und integriere APIs über oanors secret-sicheres Gateway.

289–312 von 1117 APIs

Chicken Coop API

Hühnerstall-Mathematik für den Hinterhof als API, lokal und deterministisch berechnet – die Stall-, Auslauf- und Einrichtungszahlen, nach denen ein Herdenhalter baut. Der Space-Endpunkt dimensioniert die Unterbringung anhand der Herde und der Rasse: etwa 4 ft² Stallfläche pro Standardhenne (2 für Zwerghühner, 5 für schwere Rassen) plus ungefähr 10 ft² Auslauf pro Tier, also benötigen zehn Standardhennen einen 40 ft² großen Stall und einen 100 ft² großen Auslauf – und bei gegebener Stallbreite gibt er die Länge zurück, oder null Auslauf für Vögel, die frei herumlaufen und nur drinnen schlafen. Der Fixtures-Endpunkt deckt das Innere ab: ein Nistkasten pro drei bis vier Hennen (sie teilen sich und stellen sich an, also brauchen zehn Hennen drei), 8–12 Zoll Sitzstange pro Vogel (zehn Vögel ≈ 8,3 Fuß), etwa 4 Zoll linearen Futtertrogplatz pro Tier und eine Tränke pro etwa acht Vögel. Überbelegung ist die Ursache von Pickerei, Krankheit und Unordnung, daher wird jeder Wert aufgerundet und mehr Platz ist immer besser; Sitzstangen sollten höher sitzen als die Nistkästen, damit die Vögel nicht darin schlafen – und sie verschmutzen. Alles wird lokal und deterministisch berechnet, also ist es sofort und privat. Ideal für Entwickler von Apps für Selbstversorgung, Hinterhofgeflügel, Bauernhöfe und Kleinbetriebe, Stallplanungs- und Herdenmanagement-Tools sowie Software zur Selbstversorgung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. US-Einheiten, Faustregeln. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Für Futtermengen eine andere API verwenden.

#chickens #poultry #homesteading
P von PremiumApi
Uptime
100.0%
Latenz
81ms
Subs
4,161
Server-geprüft 9 Probes/24h

api.oanor.com/chickencoop-api

Draft Beer API

Draft-Bier-Ausgabe-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 Ausgabeseite; für ABV, Stammwürze und IBU handelt es sich um eine Hobbybrau-Berechnung.) Der Carbonierungs-Endpoint gibt den Regler-Vordruck an, der eine Zielcarbonierung bei der Serviertemperatur 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, Lagerbiere und Weizen höher. Der Balance-Endpoint 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 auf 3/16-Zoll-Vinyl (≈3 psi/ft) benötigen etwa 3,7 Fuß, während schmalere oder breitere Schläuche alles ändern. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Hobbybrau-, Kegerator-, Bar-, Brauerei-Ausschank- und Getränke-App-Entwickler, Ausschank- und Fehlerbehebungstools sowie Gastronomie-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofort. Nur Ausgabeseite. Live, nichts gespeichert. 2 Compute-Endpoints.

#draft-beer #kegerator #homebrew
P von PremiumApi
Uptime
100.0%
Latenz
86ms
Subs
4,847
Server-geprüft 9 Probes/24h

api.oanor.com/draftbeer-api

Messer-Schärf-API

Messer-Schärf-Mathematik als API, lokal und deterministisch berechnet – die Fasen- und Winkelzahlen, auf die ein Schleifer, Koch oder Messermacher einen Stein einstellt. Es verwendet das symmetrische V-Kanten-Modell: Der Bevel-Endpunkt nimmt die Klingendicke und einen Winkel pro Seite (oder inklusiven Winkel) und gibt die Fasenbreite zurück = (Dicke ÷ 2) ÷ sin(Winkel pro Seite), wobei der inklusive Winkel das Doppelte des Winkels pro Seite ist – eine 2 mm Klinge, die auf 15° pro Seite geschliffen ist, hat eine 3,86 mm Fase und eine 30° Schneide, und bei 40° inklusiv (20° pro Seite) eine 2,92 mm Fase. Der Angle-Endpunkt führt dies für die Marker-Methode (Sharpie) umgekehrt durch: Die Schneide einfärben, einen Strich machen, die glänzende Fase messen, und der Winkel pro Seite = asin((Dicke ÷ 2) ÷ Fasenbreite) gibt den Winkel an, den Sie tatsächlich halten. Der Recommend-Endpunkt liefert sinnvolle inklusive Winkelbereiche nach Verwendung – etwa 12–17° für Rasiermesser, 20–30° für japanische Küchenmesser, 30–40° für westliche Kochmesser und EDC, 40–50° für Outdoor und harte Nutzung, 45–65° für Äxte – und konvertiert jeden gewählten inklusiven Winkel in Winkel pro Seite und zurück. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Messer-, Küchen-, EDC-, Bushcraft-, Holzverarbeitungs- und Schärf-Apps, Schärfvorrichtungen und Kantengeometrie-Werkzeugen sowie Maker-Software. Reine lokale Berechnung – kein API-Key, kein Drittanbieterdienst, sofort. Symmetrisches V-Kanten-Modell, mm und Grad. Live, nichts wird gespeichert. 3 Compute-Endpunkte.

#knife #sharpening #bevel
P von PremiumApi
Uptime
100.0%
Latenz
80ms
Subs
3,532
Server-geprüft 12 Probes/24h

api.oanor.com/knifesharp-api

Schweißeinstellungen-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 Gewicht pro Zoll = (π/4 · d²) × 0,284 lb/in³ für Stahl, also 0,035-Zoll-Draht bei 300 in/min ergibt etwa 4,9 lb/h zugeführt, 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 35 CFH leert 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, für Kostenkalkulations- und Verbrauchsplanungstools sowie für Schweißausbildungssoftware. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Maschineneinstellungen, nicht Verbindungsfestigkeit. Live, nichts gespeichert. 3 Compute-Endpunkte.

#welding #fabrication #metalwork
P von PremiumApi
Uptime
100.0%
Latenz
76ms
Subs
4,220
Server-geprüft 12 Probes/24h

api.oanor.com/welding-api

Screen Printing API

Screen-printing-Mathematik als API, lokal und deterministisch berechnet – die Tintenverbrauchs- und Kostenwerte, die ein Bekleidungsdrucker oder eine Druckerei für einen Auftrag kalkuliert. Alles dreht sich um die „Tintenlaufleistung“, die bedruckte Fläche, die eine Tinteneinheit abdeckt – in² pro Pfund, bei Plastisol üblicherweise 12.000–18.000, abhängig von Sieb und Auftrag. Der Ink-Endpunkt berechnet den Bedarf für eine Auflage: Tinte = (Druckfläche × Drucke) ÷ Laufleistung, also benötigt ein 100 in² großes Design, 150 Mal gedruckt, bei 15.000 in²/lb genau ein Pfund (454 g, etwa 3 g pro Druck); übergeben Sie das Design als Fläche oder als Breite × Höhe. Der Prints-Endpunkt rechnet umgekehrt – wie viele Shirts ein Tinteneimer schafft: Drucke = (Tintengewicht × Laufleistung) ÷ Druckfläche, also deckt ein Pfund Plastisol 15.000 in² ab, etwa 150 Drucke dieses Designs vor Abfall, und es akzeptiert Pfund, Kilogramm oder Gramm. Der Cost-Endpunkt berechnet den Preis: Tintenpfund × Preis pro Pfund ergibt die Tintenkosten der Auflage und den Preis pro Druck, normalerweise nur ein paar Cent – nur Tinte, ohne Siebe, Kleidungsstücke und Arbeit. Alles wird lokal und deterministisch berechnet, daher sofort und privat. Ideal für Entwickler von Screen-Printing-, Bekleidungsveredelungs-, Druckerei- und Merch-Apps, Angebots- und Auftragskalkulationstools sowie Produktionsplanungssoftware. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Nur Tinte; fügen Sie Siebe, Kleidungsstücke und Arbeit für ein vollständiges Angebot hinzu.

#screen-printing #apparel #printing
P von PremiumApi
Uptime
100.0%
Latenz
79ms
Subs
3,682
Server-geprüft 12 Probes/24h

api.oanor.com/screenprint-api

Leathercraft API

Lederverarbeitungs-Mathematik als API, lokal und deterministisch berechnet – die Gewichts-, Flächen- und Riemenzahlen, nach denen ein Lederarbeiter, Sattler oder Hersteller ein Projekt zuschneidet. Der Endpunkt für die Dicke behandelt die Besonderheit, dass das „Gewicht“ von Leder eigentlich eine Dicke ist: Eine Unze entspricht einem Vierundsechzigstel Zoll oder 0,397 mm, also ist 8 oz Leder 3,18 mm – und er rechnet in beide Richtungen zwischen Unzen, Millimetern und Zoll um und schlägt typische Verwendungen vor, von 2–3 oz Futter und Geldbörsen bis zu 9 oz und mehr Gürteln und Sattlerwaren. Der Flächenendpunkt rechnet die Hautfläche zwischen dem US-amerikanischen Quadratfuß, dem europäischen Quadratdezimeter (1 ft² = 9,29 dm²) und Quadratmetern um und dimensioniert ein Projekt: Gegeben das benötigte Leder für ein Projekt und einen Verschnittzuschlag – 25–40 % sind normal, da Häute unregelmäßige Kanten und Fehler aufweisen – gibt er die nutzbare Fläche und die Anzahl der zu kaufenden Häute zurück. Der Riemenendpunkt zählt die aus einem rechteckigen Stück geschnittenen Riemen (Anzahl = ⌊Breite ÷ Riemenbreite⌋, jeder so lang wie das Stück) oder die durch einen Spiralschnitt aus einer Fläche gewonnene durchgehende Schnürsenkellänge (Länge = Fläche ÷ Breite). Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Lederverarbeitungs-, Sattlerei-, Handwerks-, Taschenherstellungs- und Maker-App-Entwickler, Projektschätzungs- und Materialkosten-Tools sowie Werkstattsoftware. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Live, nichts wird gespeichert. 3 Compute-Endpunkte.

#leather #leathercraft #saddlery
P von PremiumApi
Uptime
100.0%
Latenz
72ms
Subs
4,545
Server-geprüft 12 Probes/24h

api.oanor.com/leather-api

Klettergrad-API

Klettergrad-Umrechnung als API, lokal und deterministisch berechnet – die systemübergreifenden Gradübersetzungen, die eine Kletter-App, Kletterhalle oder ein Führerbuch benötigt, wenn dieselbe Route in jedem Land anders bewertet wird. Der Route-Endpunkt akzeptiert einen Seilklettergrad in jedem gängigen System – dem amerikanischen Yosemite Decimal System (5.5 bis 5.15d), den französischen Sportgraden (4b bis 9c+), der in Mitteleuropa verwendeten UIAA-Skala (IV bis XIII-) oder den australischen/neuseeländischen Ewbank-Zahlen (12 bis 40) – und gibt die Äquivalente in allen Systemen zurück, sodass eine 5.11a eine französische 6c, eine UIAA VII+ und eine Ewbank 22 ist. Der Boulder-Endpunkt rechnet zwischen der amerikanischen V-Skala (VB und V0 bis V17) und der französischen Fontainebleau-Skala (3 bis 9A) um, sodass ein V5 Font 6C und ein Problem mit 7A etwa V6 ist. Sie können einen Grad in jedem unterstützten System übergeben, und es findet die Zeile und gibt den Rest aus – praktisch zum Synchronisieren einer Tickliste über Regionen hinweg oder um einem Kletterer einen Grad zu zeigen, den er kennt. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Entwickler von Kletter-, Boulder-, Hallen-, Führerbuch- und Outdoor-Sport-Apps, Ticklisten- und Routendatenbank-Tools sowie Trainingslog-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Diagramm-Äquivalente – Grade sind systemübergreifend von Natur aus ungefähr. Live, nichts wird gespeichert. 2 Konvertierungsendpunkte.

#climbing #bouldering #grades
P von PremiumApi
Uptime
100.0%
Latenz
76ms
Subs
3,760
Server-geprüft 9 Probes/24h

api.oanor.com/climbgrade-api

Speichenlängen- & Rad-API

Fahrrad-Laufradbau-Mathematik als API, lokal und deterministisch berechnet – die Speichenlängen- und Spannungszahlen, nach denen ein Laufradbauer ein Rad einspeicht. Der Speichen-Endpunkt führt die klassische Speichenlängenformel aus Naben- und Felgengeometrie aus: L = √(R² + r² + f² − 2·R·r·cos θ) − Loch ÷ 2, wobei R der halbe effektive Felgendurchmesser (ERD), r der halbe Nabenschenkeldurchmesser, f der Mitten-zu-Schenkel-Versatz und θ = Kreuzungen × 720° ÷ Speichen ist – also eine 602 mm ERD-Felge auf einem 45 mm Schenkel bei 35 mm Versatz, 32 Speichen 3-fach gekreuzt (ein 67,5° Kreuzungswinkel), benötigt eine 293,9 mm Speiche. Es verarbeitet radiale (0-Kreuzungs-) Aufbauten und berechnet die Antriebs- und Nicht-Antriebsseite getrennt aus ihren eigenen Versätzen, da sich die beiden Seiten eines nach innen gewölbten Rades unterscheiden. Der Stütz-Endpunkt gibt für jede Seite den Stützwinkel = atan(Versatz ÷ (ERD/2)) – den Hebel, der Seitenkräften widersteht – und das resultierende Spannungsverhältnis, weil die Seite mit dem kleineren Versatz eine höhere Spannung tragen muss, weshalb die Nicht-Antriebsspeichen eines Hinterrads (oft nur etwa die Hälfte der Antriebsseitenspannung) zuerst locker werden. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Fahrradladen-, Laufradbau-, Radsport- und Bike-Fit-App-Entwickler, Speichenrechner- und Bausatz-Tools sowie Komponentendatenbank-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Millimeter. Live, nichts gespeichert. 2 Compute-Endpunkte. Für Gangzoll oder Übersetzung verwenden Sie eine Fahrrad-Getriebe-API.

#cycling #wheelbuilding #spoke
P von PremiumApi
Uptime
100.0%
Latenz
79ms
Subs
4,173
Server-geprüft 9 Probes/24h

api.oanor.com/spokelength-api

Resin & Epoxy API

Gieß- und Epoxidharz-Mathematik als API, lokal und deterministisch berechnet – die Misch-, Deckungs- und Formvolumen-Zahlen, nach denen ein Harzkünstler, Handwerker oder Maker ein Projekt gießt. Der Mix-Endpunkt teilt ein Zweikomponentenharz nach seinem Etikettenverhältnis auf: Harz = Gesamt × A/(A+B), Härter = Gesamt × B/(A+B), ausgehend von der Menge, die Sie kennen – der Gesamtmenge, dem Harz oder dem Härter – also ein 2:1 Epoxid für 300 ml ergibt 200 + 100, und ein 100:45 nach Gewicht-System für 100 g Harz benötigt 45 g Härter; es behält Ihre Einheit (ml, Gramm, fl oz) und erinnert Sie daran, dass einige Harze nach Volumen und andere nach Gewicht gemischt werden. Der Coverage-Endpunkt dimensioniert eine Flut- oder Versiegelungsschicht: Volumen = Fläche × Dicke, in metrischen oder US-Einheiten, zurückgegeben in Millilitern, Flüssigunzen und Gallonen plus der Masse – entsprechend der bekannten Kunstharz-Regel von etwa einer Gallone pro 12 ft² bei einem Achtel Zoll. Der Moldfill-Endpunkt berechnet das Volumen einer Box-, Zylinder-, Kugel- oder Kegelform (eine 10×10×5 cm Box ergibt 500 ml, 550 g bei Epoxid-Dichte von ~1,1 g/cm³) und subtrahiert die Verdrängung von eingebetteten Gegenständen, sodass Sie nie über- oder untergießen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Harzkunst-, Handwerks-, Schmuck-, Modellbau-, River-Table- und Maker-Apps, Projektkalkulations- und Materialkosten-Tools sowie Studio-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofort. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Für Topfzeit und Aushärtung folgen Sie dem Produktdatenblatt.

#resin #epoxy #casting
P von PremiumApi
Uptime
100.0%
Latenz
74ms
Subs
4,314
Server-geprüft 12 Probes/24h

api.oanor.com/resin-api

Home Canning API

Home-Canning-Mathematik als API, lokal und deterministisch berechnet – die Höhenanpassungen, die eine Charge Konserven sicher halten, die Zahlen, die ein Einkocher, Selbstversorger oder Rezept-App pro Glas verarbeitet. Denn Wasser kocht in größerer Höhe kühler, jedes getestete Meereshöhen-Rezept muss länger oder heißer laufen, und diese API führt diese Arithmetik durch. Der Waterbath-Endpunkt wendet die USDA-Regel für kochendes Wasserbad und Dampfeinkocher an: für eine Basisverarbeitungszeit von 20 Minuten oder weniger werden 5, 10, 15 oder 20 Minuten nach Höhenband hinzugefügt, und für mehr als 20 Minuten werden 10, 20, 30 oder 40 hinzugefügt – ein 15-minütiges Gurkenrezept auf 4.000 Fuß verarbeitet also 25 Minuten, und ein 30-minütiges läuft 50 Minuten. Der Pressure-Endpunkt passt den Einkocher an: ein Manometer gewinnt 1 psi pro 2.000 Fuß, wodurch ein 11-psi-Rezept zu 12, 13, 14 oder 15 wird, während ein Gewichtsmanometer einfach von 10 psi bis 1.000 Fuß auf 15 psi darüber springt, da es nur 5/10/15-Einstellungen hat. Der Boilingpoint-Endpunkt liefert den zugrundeliegenden Grund – Wasser kocht etwa 1,84 °F niedriger pro 1.000 Fuß, also kocht es auf 5.000 Fuß bei 202,8 °F statt 212. Alles wird lokal und deterministisch berechnet, also ist es sofort und privat. Ideal für Entwickler von Einkoch-, Lebensmittelkonservierungs-, Selbstversorger-, Rezept- und Küchen-Apps, Konservenrechner- und Vorratskammer-Tools sowie Kochkurs-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. USDA-Tabellen – immer einem getesteten Rezept folgen. Live, nichts gespeichert. 3 Compute-Endpunkte.

#canning #food-preservation #homesteading
P von PremiumApi
Uptime
100.0%
Latenz
83ms
Subs
4,575
Server-geprüft 12 Probes/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 vermisst. 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 Verjüngungszugabe, 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, wie 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 Holzbewertungstools sowie Waldgrundstücksrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Imperiale Forsteinheiten. Live, nichts gespeichert. 2 Compute-Endpunkte. Für gesägte Brettfuß verwenden Sie eine Lumber-API.

#forestry #logging #sawmill
P von PremiumApi
Uptime
100.0%
Latenz
86ms
Subs
4,210
Server-geprüft 9 Probes/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 standardmäßige veterinärmedizinische Formel: 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 ÷ die 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-, Veterinär-, Tierfutter-, Hunde- und Katzen-Apps, Futterrechner- und Haustiergesundheits-Tools sowie Züchter-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofort. Bildungsbezogene Schätzungen, keine tierärztliche Beratung. Live, nichts wird gespeichert. 3 Berechnungs-Endpunkte. Für die Umrechnung des Hundealters verwenden Sie eine andere API.

#pet #dog #cat
P von PremiumApi
Uptime
100.0%
Latenz
74ms
Subs
4,208
Server-geprüft 12 Probes/24h

api.oanor.com/petfood-api

Alcohol & ABV API

Alkohol- und Cocktail-Mathematik als API, lokal und deterministisch berechnet – die ABV-, Verdünnungs- und Standardgetränke-Zahlen, die ein Barkeeper, Brauer oder eine Getränke-App hinter der Bar ermittelt. Der abv-Endpunkt mischt ein Getränk: Übergeben Sie die Zutaten als Liste von Volumen:ABV und er gibt den endgültigen Alkoholgehalt in Volumenprozent zurück = (Summe von Volumen × ABV) ÷ Gesamtvolumen, sodass ein Negroni-artiges Getränk mit 2 Teilen zu 40 %, 1 Teil zu 20 % und 1 Mixer zu 0 % bei 25 % ABV (50 US Proof) landet, wobei Mixer das Ergebnis verdünnen. Der dilution-Endpunkt modelliert Eisschmelze und Rühren, die Wasser hinzufügen und die Stärke senken: Endvolumen = Volumen × (1 + Verdünnung) und ABV fällt um denselben Faktor, während der Alkohol selbst unverändert bleibt, sodass ein 4 oz gerührtes Getränk mit 25 % und 25 % Verdünnung zu 5 oz mit 20 % wird – gerührte Getränke nehmen etwa 20–25 % auf, geschüttelte etwas mehr. Der standard-Endpunkt zählt die Dosis: Reinalkohol = Volumen × ABV, dann ist ein US-Standardgetränk 14 Gramm (0,6 fl oz) und eine UK-Einheit 10 ml Reinalkohol, sodass ein 12 fl oz Bier mit 5 % ein Standardgetränk (14 g, 1,77 UK-Einheiten) ist und ein 5 fl oz Glas Wein mit 12 % ebenfalls eines. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Entwickler von Barkeeper-, Brau-, Getränke-, Gastgewerbe- und verantwortungsvollen Trink-Apps, Cocktail-Builder- und Getränke-Tracker-Tools sowie Bar-Menü-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Live, nichts gespeichert. 3 Compute-Endpunkte. Für Getränkerezepte verwenden Sie eine Cocktail-Datenbank-API.

#abv #cocktail #alcohol
P von PremiumApi
Uptime
100.0%
Latenz
77ms
Subs
4,305
Server-geprüft 12 Probes/24h

api.oanor.com/abv-api

Segel- & Rumpfdesign-API

Segel- und schiffsarchitektonische Mathematik als API, lokal und deterministisch berechnet – die Rumpfgeschwindigkeits- und Designverhältniszahlen, mit denen ein Segler, Bootskäufer oder Yachtdesigner ein Boot dimensioniert. Der Hullspeed-Endpunkt gibt die theoretische Verdrängungsgeschwindigkeitsgrenze aus der Wasserlinie: Rumpfgeschwindigkeit = 1,34 × √LWL (Fuß) in Knoten, sodass eine 25-Fuß-Wasserlinie bei etwa 6,7 Knoten (7,7 mph, 12,4 km/h) endet – mit einem einstellbaren Koeffizienten von bis zu etwa 1,5 für leichte, leicht anzutreibende Rümpfe, da Gleitboote die Formel vollständig hinter sich lassen. Der Ratios-Endpunkt berechnet die beiden klassischen Leistungskennzahlen: das Segelflächen-/Verdrängungsverhältnis, SA/D = Segelfläche ÷ (verdrängtes Volumen in ft³)^⅔ unter Verwendung von verdrängtem Volumen = Verdrängung ÷ 64 lb/ft³ für Meerwasser – etwa 16–18 ist ein typischer Cruiser und 20+ ist sportlich – und das Verdrängungs-/Längenverhältnis, DLR = (Verdrängung in long tons) ÷ (0,01 × LWL)³, wobei unter 200 leicht und über 300 schwer ist, jeweils mit einer Klassenbezeichnung zurückgegeben. Der Ballast-Endpunkt gibt das Ballastverhältnis = Ballast ÷ Verdrängung × 100, ein grober Indikator für Steifigkeit und Segeltragekraft, das die meisten Cruiser bei etwa 35–45 % erreichen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Segel-, Boots-, Schifffahrts-, Yachtmakler- und Bootsdesign-App-Entwickler, Bootsvergleichs- und Rig-Größen-Tools sowie schiffsarchitektonische Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Imperiale Einheiten. Live, nichts gespeichert. 3 Compute-Endpunkte. Designverhältnis-Schätzungen, kein Geschwindigkeitsvorhersageprogramm.

#sailing #boating #marine
P von PremiumApi
Uptime
100.0%
Latenz
72ms
Subs
4,058
Server-geprüft 12 Probes/24h

api.oanor.com/sailing-api

Archery & Arrow API

Bogenschießen- und Pfeilmathematik als API, lokal und deterministisch berechnet – die FOC-, Energie- und Pfeilgewichtszahlen, mit denen ein Bogenschütze oder Bogenjäger einen Aufbau abstimmt. Der FOC-Endpunkt findet die Front-of-Center-Balance, den Anteil des Pfeilgewichts, der vor der Mitte liegt: FOC = ((Balancepunkt − Länge ÷ 2) ÷ Länge) × 100, gemessen von der Nocke aus, sodass ein 28-Zoll-Pfeil, der bei 16 Zoll balanciert, 7,1 % ergibt – und er gibt das Ergebnis in Bändern an, da Zielbogenschützen etwa 7–12 % erreichen, während Jäger für Durchschlagskraft und Fehlertoleranz 12–19 % anstreben. Der Energie-Endpunkt wandelt Pfeilgewicht und Geschwindigkeit in Endballistik um: kinetische Energie (ft-lb) = grains × fps² ÷ 450.240 und Impuls (slug-fps) = grains × fps ÷ 225.218, sodass ein 400-Grain-Pfeil bei 280 fps etwa 69,7 ft-lb und 0,50 slug-fps trägt, mit einer vorgeschlagenen Wildklasse – Impuls, nicht KE, ist der bessere Penetrationsprädiktor für schwere Pfeile. Der Gewichts-Endpunkt summiert einen fertigen Pfeil aus seinen Teilen – Schaft (grains-per-inch × Länge) plus Spitze, Insert, Nocke und Befiederung – und teilt durch das Zuggewicht für grains-per-pound, wobei das 5-GPP-Minimum markiert wird, das den Bogen schützt. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps für Bogenschießen, Bogenjagd, traditionelles Bogenschießen und Outdoor-Sport, Pfeilbau- und Bogenabstimmungswerkzeuge sowie Profi-Shop-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Imperiale Bogenschießeinheiten. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Für Visiermarken oder Bogenabstimmung verwenden Sie eine andere API.

#archery #bowhunting #arrow
P von PremiumApi
Uptime
100.0%
Latenz
75ms
Subs
3,709
Server-geprüft 12 Probes/24h

api.oanor.com/archery-api

Pottery & Ceramics API

Töpferei- und Keramik-Mathematik als API, lokal und deterministisch berechnet – die Schrumpfungs-, Glasurbatch- und Brennzahlen, die ein Töpfer an der Scheibe und am Ofen ermittelt. Der Schrumpfungs-Endpunkt behandelt die Tatsache, dass Ton von nass über knochentrocken bis gebrannt schrumpft: bei einer typischen linearen Schrumpfung von 12 % schrumpft ein 100 mm Rand auf 88 mm gebrannt, und umgekehrt sagt er Ihnen, ein Stück größer zu werfen, um eine Zielgröße zu erreichen – machen Sie es 100 mm nass, um bei 88 mm zu enden – und meldet die Volumenschrumpfung, die der Kubus des linearen Faktors ist (etwa 32 %). Der Glasur-Endpunkt skaliert ein prozentuales Rezept auf einen realen Batch: übergeben Sie die Zutaten als Name:Prozent-Liste und ein Trockenbatch-Gewicht, und er gibt die Gramm jeder Zutat zurück, dividiert durch die eigene Prozentsumme des Rezepts, sodass Rezepte, die über 100 % summieren (eine Basis 100 plus Farbstoff- und Trübungszusätze), immer noch korrekt skaliert werden, plus das Wasser zum Tauchen. Der Kegel-Endpunkt gibt die ungefähre Brenntemperatur für einen selbsttragenden Orton-Kegel bei der standardmäßigen Rampe von 108 °F/Stunde an – Kegel 06 etwa 1828 °F (998 °C) für Schrühbrand, Kegel 6 etwa 2232 °F (1222 °C) und Kegel 10 etwa 2345 °F (1285 °C) für Steinzeug – und erinnert daran, dass ein Kegel die Hitzearbeit misst, nicht nur die Temperatur. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Keramik-, Töpferei-, Maker- und Handwerks-App-Entwickler, Ofenprotokoll- und Glasurrechner-Tools sowie Studio-Management-Software. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofortig. Live, nichts gespeichert. 3 Compute-Endpunkte. Für Ofen-Element-Leistung verwenden Sie eine andere API.

#pottery #ceramics #glaze
P von PremiumApi
Uptime
100.0%
Latenz
97ms
Subs
4,807
Server-geprüft 12 Probes/24h

api.oanor.com/pottery-api

Deck Builder API

Deck-Building-Mathematik als API, lokal und deterministisch berechnet – die Anzahl an Brettern, Balken und Befestigungselementen, die ein Hausbesitzer oder Bauunternehmer benötigt, um eine rechteckige Terrasse zu materialisieren. Der Boards-Endpunkt verwandelt die Terrassengröße in eine echte Einkaufsliste: Reihen = Terrassenbreite ÷ (Brettbreite + Lücke), aufgerundet, also benötigt eine 16 ft × 12 ft Terrasse mit einer 5,5-Zoll-Brettfläche (ein 5/4×6) und einer 1/8-Zoll-Lücke 26 Reihen; Bretter verlaufen in der Länge, jede Reihe benötigt ein 16-ft-Brett, und ein 10 % Verschnittzuschlag ergibt 29 Bretter plus die laufenden Meter und die Terrassenfläche. Der Joists-Endpunkt rahmt es ein: Balken werden entlang der Länge verteilt, also Anzahl = ⌊Länge ÷ Abstand⌋ + 1 – dreizehn Balken im 16-Zoll-Abstand (siebzehn im 12-Zoll-Abstand für stärkere oder diagonale Dielen), jeder spannt über die Breite, plus zwei Randbalken und ein Schwellbalken als gesamte Rahmenlaufmeter. Der Fasteners-Endpunkt zählt die Schrauben: Jede Dielenreihe kreuzt jeden Balken einmal und wird dort mit zwei sichtbaren Schrauben befestigt, also benötigt eine 16×12 Terrasse 26 × 13 × 2 = 676 Schrauben, etwa 744 mit Verschnitt – oder einen verdeckten Clip pro Kreuzung. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Bau-, Auftragnehmer-, Heimwerker-, Baustoff- und Renovierungs-App-Entwickler, Terrassenschätzer- und Mengenermittlungstools sowie Holzlagerrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. US-Einheiten (Fuß/Zoll). Live, nichts gespeichert. 3 Compute-Endpunkte. Rechteckige Terrassen; für Innenbodenfläche eine Flooring-API verwenden.

#deck #construction #contractor
P von PremiumApi
Uptime
100.0%
Latenz
77ms
Subs
4,490
Server-geprüft 12 Probes/24h

api.oanor.com/deck-api

Propane & LPG Tank API

Propane- und LPG-Tank-Mathematik als API, lokal und deterministisch berechnet – die nutzbaren Füll-, Energie- und Brenndauerzahlen, die ein Hausbesitzer, Wohnmobilfahrer, Grillmeister oder HVAC-Techniker am Tank ermittelt. Der Tank-Endpunkt wandelt eine Tankgröße in reale Zahlen um: Flüssigpropan wiegt 4,24 lb pro Gallone und enthält 91.452 BTU pro Gallone (etwa 21.569 BTU pro Pfund), daher fasst ein 20-lb-Grillzylinder etwa 4,7 Gallonen und 431.000 BTU. Er kennt die beiden Arten, wie Tanks dimensioniert werden – ein tragbarer Zylinder (20, 30, 40 lb) wird nach dem Propangewicht bewertet, das er enthält, während ein Großtank (100, 250, 500, 1000 gal) nur zu 80 % seiner Wasserkapazität befüllt wird, um Platz für Ausdehnung zu lassen, sodass ein 500-Gallonen-Tank tatsächlich 400 Gallonen Propan und etwa 36,6 Millionen BTU enthält. Der Brenndauer-Endpunkt teilt diese Energie durch die BTU-pro-Stunde-Eingangsleistung eines Geräts, um die Laufzeit zu ermitteln: Derselbe 20-lb-Zylinder betreibt einen 30.000-BTU/h-Terrassenheizer etwa 14 Stunden, und eine optionale Stunden-pro-Tag-Angabe wandelt dies in Tage um. Der Nachfüll-Endpunkt berechnet eine Befüllung aus einem Preis pro Gallone, gibt die Kosten pro 100.000 BTU an, sodass Sie Propan mit Erdgas oder Strom vergleichen können, und – mit einer Geräteleistung – die Betriebskosten pro Stunde. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für App-Entwickler im Bereich Hausenergie, HVAC, Wohnmobile, netzunabhängige Systeme, Grillen und Outdoor-Leben, für Treibstoffkosten- und Tanküberwachungstools sowie für Propangaslieferungsrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. US-Einheiten. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Für Fahrzeugkraftstoffverbrauch oder das ideale Gasgesetz verwenden Sie eine andere API.

#propane #lpg #energy
P von PremiumApi
Uptime
100.0%
Latenz
80ms
Subs
4,756
Server-geprüft 12 Probes/24h

api.oanor.com/propane-api

Barbell & Lifting API

Barbell- und Gewichtheber-Mathematik als API, lokal und deterministisch berechnet – die Scheibenbeladungs- und Prozentzahlen, die ein Lifter, Trainer oder eine Fitness-App an der Hantelbank ausrechnet. Der Plates-Endpunkt löst das alltägliche Rätsel im Fitnessstudio, welche Scheiben auf jede Seite für ein Zielgewicht kommen: 100 kg auf einer Standard-20-kg-Stange bedeuten 40 kg pro Seite, zuerst mit den schwersten beladen als 25er und 15er; 102,5 kg fügt die 1,25-Mikroplatte hinzu; und wenn ein Ziel mit den vorhandenen Scheiben nicht erreichbar ist, lädt es die nächstmögliche 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 Scheibensatz. Der Percent-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 Warmup-Endpunkt baut eine Rampe von der leeren Stange bis zum Arbeitssatz bei etwa 40, 55, 70 und 85 %, jede auf einen belastbaren Schritt gerundet, wobei die Wiederholungszahl sinkt, wenn die Stange schwer wird. Alles wird lokal und deterministisch berechnet, also ist es sofort und privat. Ideal für Entwickler von Fitnessstudio-, Krafttrainings-, Powerlifting- und Fitness-Apps, Workout-Logger- und Coaching-Tools sowie für Entwickler von Smart-Rack- und Plattenrechnern. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Exakte Mathematik, keine Simulation. Live, nichts gespeichert. 3 Compute-Endpunkte. Für die One-Rep-Max-Schätzung aus einem Satz verwenden Sie eine Strength-API.

#barbell #weightlifting #gym
P von PremiumApi
Uptime
100.0%
Latenz
80ms
Subs
4,560
Server-geprüft 12 Probes/24h

api.oanor.com/barbell-api

Dice Probability API

Tabletop-Würfelwahrscheinlichkeitsmathematik als API, lokal und deterministisch und exakt berechnet – die Chancen hinter den Würfen, nicht die Würfe selbst. Der Advantage-Endpunkt gibt die D&D-artigen Wahrscheinlichkeiten, ein Ziel auf einem d20 (oder einem beliebigen Würfel) normal, mit Vorteil (zweimal würfeln, das höhere behalten) oder mit Nachteil (das niedrigere behalten) zu schlagen: Eine 11+ zu benötigen ist 50 % normal, 75 % mit Vorteil und 25 % mit Nachteil, und er meldet den durchschnittlichen Wurf – Vorteil hebt einen d20 von 10,5 auf etwa 13,8. Der Pool-Endpunkt behandelt Erfolgszählsysteme (World of Darkness, Shadowrun): Für einen Pool von Würfeln, die bei einer Augenzahl ab einem Schwellenwert erfolgreich sind, gibt er die Wahrscheinlichkeit pro Würfel, die erwartete Anzahl von Erfolgen und die exakte Binomialwahrscheinlichkeit, genau oder mindestens eine Zielanzahl zu erreichen – sechs d10, die bei 7+ erfolgreich sind, ergeben durchschnittlich 2,4 Erfolge mit einer 45,6 % Chance auf drei oder mehr. Der Exploding-Endpunkt gibt den Mittelwert eines explodierenden („acing“, offenen) Würfels, der bei seiner maximalen Augenzahl neu gewürfelt und addiert wird – ein d6 ergibt durchschnittlich 4,2 statt 3,5. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Tabletop-, Virtual-Tabletop-, Spieledesign- und TTRPG-App-Entwickler, Chancen-und-Wahrscheinlichkeits-Helfer und Spielleiter-Werkzeuge. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Exakte Mathematik, keine Simulation. Live, nichts gespeichert. 3 Compute-Endpunkte. Für zufällige Würfe eine Dice-Roller-API verwenden.

#dice #probability #ttrpg
P von PremiumApi
Uptime
100.0%
Latenz
74ms
Subs
3,594
Server-geprüft 12 Probes/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 Appetithäppchen pro Person und eineinhalb Brötchen – also benötigen 50 Gäste bei einem Standard-Dinner mit drei Beilagen 25 Pfund Fleisch, 300 Appetithäppchen 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 Sie kaufen – Bier im Kasten (24) und im Fass (ca. 165 Portionen), Wein in der Flasche (~5 Gläser), Spirituosen in der 750-ml-Flasche (~16 Shots) – plus das Eis (ca. 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 sofort 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, sofort. US-Einheiten; Faustregeln – aufrunden. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Passen Sie es an die Menge und die Jahreszeit an.

#catering #party-planning #event
P von PremiumApi
Uptime
100.0%
Latenz
78ms
Subs
4,088
Server-geprüft 9 Probes/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 von PremiumApi
Uptime
100.0%
Latenz
74ms
Subs
3,707
Server-geprüft 12 Probes/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 Vollfeld-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 Drei-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 Drei-Dart-Durchschnitt – Gesamtpunktzahl ÷ Darts × 3 – also 501 in 15 Darts ergibt einen Durchschnitt von 100,2; ein Durchschnitt ü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 standardmäßige 20-Segment-Board.

#darts #checkout #x01
P von PremiumApi
Uptime
100.0%
Latenz
76ms
Subs
4,296
Server-geprüft 9 Probes/24h

api.oanor.com/darts-api

Golf Scoring API

Golf-Scoring und Handicap-Berechnung als API, lokal und deterministisch berechnet – das World Handicap System und Stableford-Zahlen, mit denen ein Golfer, Club oder eine Scoring-App arbeitet. Der Handicap-Endpunkt berechnet das Course Handicap aus einem Handicap-Index: Course Handicap = Index × (Slope Rating ÷ 113) + (Course Rating − Par), gerundet, sodass ein 14,5-Index auf einem 130-Slope-, 71,5-Rating-Par-72-Platz mit 16 spielt; er wendet auch den Format-Nachlass (z. B. 95 % für Stroke Play) an, um das Playing Handicap zu ermitteln. Der Stableford-Endpunkt bewertet ein Loch auf der Standardskala: Netto-Par ergibt 2 Punkte, jeder Schlag besser addiert einen (Birdie 3, Eagle 4) und jeder schlechtere subtrahiert einen (Bogey 1), wobei Netto-Doppelbogey oder schlechter 0 Punkte ergibt, wobei der Nettoscore der Bruttoscore abzüglich der auf diesem Loch erhaltenen Schläge ist. Der Netto-Endpunkt gibt den Nettoscore der Runde – Bruttosumme abzüglich des Course Handicaps – im Vergleich zu Par aus. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Golf-, Club-Management-, Scoring- und Sport-App-Entwickler, Handicap- und Stableford-Tools sowie Golfausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Slope standardmäßig neutral 113. Live, nichts gespeichert. 3 Compute-Endpunkte. Eine Scoring-Hilfe, kein offizieller Handicap-Nachweis.

#golf #handicap #stableford
P von PremiumApi
Uptime
100.0%
Latenz
78ms
Subs
4,634
Server-geprüft 12 Probes/24h

api.oanor.com/golf-api