API-Marktplatz

Die Visual Novel Database (VNDB) als API — sauberes JSON, kein Key. Suche und rufe Visual Novels mit ihren Titeln, Veröffentlichungsdaten, Sprachen, Plattformen, Spieldauer, Bayesianischer Bewertung und Stimmenanzahl, Beschreibung, Coverbild, Entwicklern und Genre-/Themen-Tags (Spoiler-Tags herausgefiltert) auf. Suche und öffne Charaktere mit ihrem Originalnamen, Aliasnamen, Beschreibung, Geschlecht, Alter, Blutgruppe und den Visual Novels, in denen sie vorkommen, und suche und öffne Produzenten und Entwickler. Plus Live-Datenbankstatistiken. Live-Daten direkt von vndb.org, der maßgeblichen Visual-Novel-Datenbank. Ein eigenständiges Medium neben Anime und Manga — ideal für Visual-Novel-Tracker, Entdeckungs- und Empfehlungs-Apps, Wikis und Otaku-Tools. 7 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

154ms

Subs

4,012

MangaDex als API – die größte Community-Manga-Bibliothek, zurückgegeben als sauberes JSON, kein Key. Suche Manga nach Titel; öffne einen Manga für seine vollständigen Details (Titel und Alternativen, Beschreibung, Status, Jahr, Zielgruppe, Inhaltseinstufung, Genre- und Themen-Tags, Autoren, Künstler und Cover); rufe den Kapitel-Feed eines Mangas in jeder übersetzten Sprache ab; erhalte die Details eines Kapitels; und rufe die bereitgestellten Seitenbild-URLs für ein Kapitel ab – den Reader-Endpunkt, in voller und Data-Saver-Qualität. Suche einen Autor und liste jedes Genre- und Themen-Tag auf. Live-Daten direkt von MangaDex. Abgrenzung zu Anime/Manga-Metadaten-APIs: Dies ist die eigentliche Leseplattform – echte Kapitel und Seitenbilder aus Tausenden von Scanlationen – ideal für Manga-Leser, Tracker, Discovery- und Bibliotheks-Apps. 7 Daten-Endpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

281ms

Subs

4,151

Der Oberste Gerichtshof der USA als API, betrieben von Oyez — sauberes JSON, kein API-Key. Durchsuchen Sie Fälle nach Amtszeit und öffnen Sie jeden Fall für seine vollständigen Details: die Parteien, die Fakten, die Rechtsfrage, das Urteil, eine datierte Zeitleiste, das untere Gericht und die Entscheidung mit der individuellen Stimme und Meinung jedes Richters. Rufen Sie das Transkript der mündlichen Verhandlung für einen Fall ab — jede Sprecherrunde mit Start-/Stopp-Zeitstempeln und einem Link zum Audio — ideal für Analyse, Suche und Untertitelung. Listen Sie alle Richter auf und öffnen Sie das Profil eines Richters (Daten, Orte, besetzte Sitze). Live-Daten direkt von oyez.org, dem maßgeblichen Multimedia-Archiv des Obersten Gerichtshofs. Ausgezeichnete, autoritative Bürgerschaftsdaten — ideal für Legal-Tech, Forschung, Bildung, Nachrichten und Bürger-Apps. 5 Datenendpunkte. Authentifiziert mit einem x-oanor-key; faire Nutzungsratenbegrenzungen pro Plan.

Uptime

100.0%

Latenz

477ms

Subs

4,725

Lichess als API – die Open-Source-Schachplattform, zurückgegeben als sauberes JSON, kein Key. Rufen Sie das Profil jedes Spielers ab (Titel, Wertungen in Bullet, Blitz, Rapid und Classical, Spielanzahl, Land, FIDE-Wertung), seinen Wertungsverlauf pro Variante und Online-Status; holen Sie die Top-Spieler für jeden Leistungstyp; rufen Sie die letzten Spiele eines Benutzers mit Eröffnungen, Uhren, Ergebnissen und vollständigen Zuglisten ab; erhalten Sie eine Stockfish-Cloud-Bewertung jeder Position per FEN (beste Linien, Centipawn- oder Mattbewertungen); stellen Sie das tägliche Puzzle oder jedes Puzzle nach ID bereit (mit Lösung und Themen); und listen Sie aktuelle, anstehende und abgeschlossene Turniere auf. Live-Daten direkt von lichess.org. Unterscheidet sich von Chess.com-Spielerstatistiken: Lichess ist eine eigene Plattform mit Cloud-Engine-Analyse, einer Puzzle-Datenbank und Arena-Turnieren – ideal für Schach-Apps, Coaching-Tools, Analyse-Boards, Bots und Bestenlisten. 9 Datenendpunkte. Authentifiziert mit einem x-oanor-key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

765ms

Subs

4,396

Audius als API – die dezentrale Musikstreaming-Plattform, zurückgegeben als sauberes JSON, kein API-Key. Suche nach Tracks, Künstlern und Playlists; rufe Trending-Tracks nach Genre und Zeitfenster ab; suche einen Track (Genre, Stimmung, BPM, Tonart, ISRC, Play-/Favoriten-/Repost-Zähler, Artwork und eine dauerhafte Stream-URL), einen Künstler (Follower, Track- und Playlist-Zähler, Bio, Standort) nach ID oder @Handle, die eigenen Tracks eines Künstlers sowie eine Playlist oder ein Album mit vollständiger Trackliste. Jeder Track wird mit einer abspielbereiten Stream-URL und einer Vorschau-URL geliefert. Live-Daten direkt aus dem Audius-Discovery-Netzwerk. Abgrenzung zu Mainstream-Katalogen: Audius ist ein unabhängiger, creator-eigener Katalog elektronischer, Hip-Hop- und Underground-Musik mit tatsächlich streambarem Audio – ideal für Musik-Entdeckungs-Apps, Player, DJ-Tools und Web3-Musikprojekte. 8 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

632ms

Subs

3,254

Mixcloud als API – die Heimat von Langform-Audio: DJ-Mixe, Radiosendungen und Podcasts, zurückgegeben als sauberes JSON, kein Key. Durchsuchen Sie Cloudcasts, Benutzer oder Tags; rufen Sie ein Benutzerprofil ab (Follower, Hörer, Standort, Bild) und deren Sendungen; erhalten Sie die vollständigen Details eines Cloudcasts – Abspielanzahl, Favoriten, Reposts, Höreranzahl, Audiolänge, Tags und Uploader; lesen Sie die Kommentare einer Sendung; rufen Sie die trendenden Cloudcasts für jedes Tag oder jede Kategorie ab; und listen Sie die Kategorien von Mixcloud auf. Live-Daten direkt von der öffentlichen Mixcloud-API. Unterscheidet sich von trackbasierten Musik-APIs: Mixcloud besteht aus stundenlangen Mixen, Rundfunkarchiven und Sendungen – ideal für Musikentdeckungs-Apps, Radio- und DJ-Verzeichnisse, Podcast-Tools und Audio-Dashboards. 8 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

424ms

Subs

3,900

Spotify-Musik- und Podcast-Metadaten als API – kein Login, kein OAuth. Lösen Sie jeden Spotify-Track, jedes Album, jeden Künstler oder jede Playlist anhand ihrer ID, spotify:-URI oder open.spotify.com-URL auf und erhalten Sie sauberes JSON: Namen, die kanonischen Spotify-IDs und URIs, Cover-Art, Veröffentlichungsdaten, Dauern, explizite Flags und 30-Sekunden-Audiovorschauen. Alben werden mit ihrer vollständigen Titelliste zurückgegeben, Künstler mit ihren Top-Tracks und Playlists mit ihren Tracks und dem Besitzer. Ein universeller Resolve-Endpunkt erkennt automatisch den Entitätstyp aus jedem Spotify-Link, und ein oEmbed-Endpunkt gibt den Titel, das Thumbnail und das einbettbare Player-HTML für jede Spotify-URL zurück. Live-Daten direkt aus Spotifys öffentlichem Embed. Ideal zur Anreicherung Ihres Katalogs mit Spotify-IDs, zum Erstellen von „Auf Spotify hören“-Links, zum Vorschauen von Tracks und zum Abgleichen von Musik über Dienste hinweg. 6 Datenendpunkte. Authentifiziert mit einem x-oanor-key; Fair-Use-Ratenlimits pro Plan.

Uptime

100.0%

Latenz

319ms

Subs

3,488

Die offene Musik-Metadaten-Datenbank als API — Künstler, Release-Gruppen (Alben), Releases, Aufnahmen und Labels, identifiziert durch stabile MusicBrainz-IDs (MBIDs), zurückgegeben als sauberes JSON. Durchsuchen Sie jede Entität nach Name oder Lucene-Abfrage; schlagen Sie einen Künstler mit seinen externen Links und Tags nach, ein Album, ein Release mit seiner vollständigen Titelliste, eine Aufnahme mit ihren ISRCs oder ein Label; und durchstöbern Sie die vollständige Diskografie eines Künstlers. Live-Daten mit MBIDs, Disambiguierungen, Typen, Ländern, Lebensspannen, ISRCs, Barcodes, Katalognummern und Beziehungen — die kanonischen Identifikatoren, die Musikdaten über Dienste hinweg verknüpfen und deduplizieren. Ideal für Metadaten-Anreicherung und -Abgleich, Musikkataloge, Tagging- und Bibliothekswerkzeuge sowie Forschung. 11 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Tarif.

Uptime

100.0%

Latenz

376ms

Subs

4,961

Echtzeit-Pinterest-Daten als API – Pins, Boards und Benutzer, zurückgegeben als sauberes JSON. Durchsuchen Sie Pins, Boards oder Benutzer nach Stichwort; rufen Sie das Profil eines beliebigen Benutzers mit Follower-, Pin- und Board-Anzahl ab; rufen Sie die Boards eines Benutzers und deren Pins ab; rufen Sie die Details eines Pins (Repins, Kommentare, Bild, Link, Domain, Pinner) und die dazugehörigen Pins ab; und rufen Sie die Details eines Boards und dessen Pins ab. Live-Daten mit Titeln, Beschreibungen, Bild-URLs in voller Auflösung, ausgehenden Links, Repin- und Kommentaranzahlen, dominanten Farben und Erstellern. Ideal für Social Listening und Trendforschung, Content-Aggregation und -Entdeckung, E-Commerce- und visuelle Marketing-Tools sowie Dashboards. 10 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

1859ms

Subs

4,555

Echtzeit-Genius-Musikdaten als API – Songs, Künstler, Alben und vollständige Songtexte, zurückgegeben als sauberes JSON. Durchsuchen Sie Songs oder suchen Sie gleichzeitig nach Songs, Künstlern und Alben; rufen Sie einen Song, Künstler oder Album per ID ab; listen Sie die Songs eines Künstlers nach Beliebtheit sortiert auf; und holen Sie den vollständigen, bereinigten Text eines Songs per ID oder Genius-URL ab. Live-Daten mit Titeln, Haupt- und Feature-Künstlern, Seitenaufrufen, Veröffentlichungsdaten, Artwork, Follower-Zahlen und Social-Media-Handles. Der Lyrics-Endpunkt gibt den vollständigen Songtext mit Abschnittsmarkierungen ([Verse], [Chorus]) und ohne den Beitragenden-Header zurück. Ideal für Musik- und Text-Apps, Karaoke- und Mitsing-Tools, Stimmungs- und Sprachanalyse sowie Metadatenanreicherung. 7 Datenendpunkte. Authentifiziert mit einem x-oanor-key; faire Nutzungsraten pro Plan.

Uptime

100.0%

Latenz

2304ms

Subs

3,929

Echtzeit-Apple-iTunes-Katalogdaten als API — Musik, Podcasts, E-Books und Hörbücher, plus Künstler-, Album- und Podcast-Suchen, zurückgegeben als sauberes JSON. Durchsuchen Sie Songs, Alben, Podcasts, E-Books und Hörbücher oder führen Sie eine allgemeine Suche über alle Medientypen durch; suchen Sie einen beliebigen Eintrag nach seiner iTunes-ID; rufen Sie einen Künstler mit seinen Alben und Songs ab; rufen Sie ein Album mit seiner vollständigen Titelliste ab; und rufen Sie einen Podcast mit seinen aktuellen Episoden ab. Live-Daten mit Namen, Künstlern, Artwork (hochskaliert), Vorschau-URLs, Genres, Preisen, Veröffentlichungsdaten, Inhaltsbewertungen, Titeln und Podcast-Feed-URLs. Ideal für Musik- und Podcast-Apps, Medienkatalog- und Metadatenanreicherung, Entdeckungs- und Empfehlungstools sowie Forschung. 12 Datenendpunkte. Authentifiziert mit einem x-oanor-key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

188ms

Subs

3,411

Echtzeit-Deezer-Musikdaten als API – Tracks, Alben, Künstler, Playlists, Charts und Genres, zurückgegeben als sauberes JSON. Durchsuchen Sie den Katalog nach Tracks, Alben, Künstlern und Playlists; rufen Sie jeden Track, jedes Album (mit seiner Trackliste), jeden Künstler oder jede Playlist per ID ab; erhalten Sie die Top-Tracks und die vollständige Diskografie eines Künstlers; ziehen Sie die globalen Charts (Top-Tracks, Alben, Künstler und Playlists) und die Liste der Genres. Live-Daten mit Titeln, Laufzeiten, Rängen, Fan-Zahlen, Cover- und Bildkunst, 30-Sekunden-Vorschau-URLs, Veröffentlichungsdaten und Explicit-Flags. Ideal für Musik-Apps und Player, Empfehlungs- und Entdeckungstools, Metadatenanreicherung, Dashboards und Forschung. 12 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungsratenbegrenzungen pro Plan.

Uptime

100.0%

Latenz

530ms

Subs

4,864

Echtzeit-Reddit-Daten als API — Subreddits, Beiträge, Kommentare, Benutzerprofile und Suche, zurückgegeben als sauberes JSON. Rufen Sie die Informationen eines Subreddits sowie dessen heiße, neue, beste oder aufsteigende Beiträge ab; holen Sie einen Beitrag zusammen mit seinem vollständigen Kommentarbaum; schlagen Sie das Profil, Karma, Einreichungen und Kommentare eines beliebigen Benutzers nach; durchsuchen Sie Beiträge in ganz Reddit oder innerhalb eines Subreddits; und listen Sie die trendenden Beiträge und die beliebtesten Subreddits auf. Live-Daten, paginiert mit Reddit-Cursorn, mit Bewertungen, Upvote-Verhältnissen, Kommentarzahlen, Flairs, Zeitstempeln, Thumbnails und Medien-URLs. Ideal für Social Listening und Markenüberwachung, Trend- und Sentiment-Dashboards, Content-Aggregation, Forschung und Marktinformationen sowie Bots. 11 Datenendpunkte. Authentifiziert mit einem x-oanor-Key; faire Nutzungslimits pro Plan.

Uptime

100.0%

Latenz

1809ms

Subs

4,986

Geländer- und Baluster-Layout-Mathematik als API, lokal und deterministisch berechnet – die Balusteranzahl, Abstände und Pfostenanzahlen, die ein Terrassenbauer, Fertiger oder Geländerdesigner für ein Schutzgeländer verwendet. Der Balusteranzahl-Endpunkt gibt die kleinste Anzahl von Balustern, die jeden Spalt innerhalb der Sicherheitsgrenze hält: Zwischen zwei Pfosten hinterlassen n Baluster n+1 Spalten, also ist die Anzahl = ceil((Schienenlänge − max. Spalt) ÷ (Balusterbreite + max. Spalt)). Die übliche Schutzgeländergrenze ist eine 100-mm-Kugel (4 Zoll) – eine Kindersicherheitsregel – also benötigt eine 2000 mm Schiene mit 40 mm Balustern 14 davon bei gleichmäßigen 96 mm Spalten; aufrunden, denn einer weniger öffnet die Spalten über die Grenze. Der Layout-Endpunkt setzt eine bekannte Anzahl gleichmäßig aus: der Spalt = (Schienenlänge − gesamte Balusterbreite) ÷ (Anzahl + 1), der Mittelpunktabstand = Balusterbreite + Spalt, und der erste Baluster sitzt einen Spalt plus einen halben Baluster von der Pfostenfläche entfernt, also markieren Sie den ersten Mittelpunkt und schreiten den Abstand ab, wobei der letzte Spalt gleich dem ersten ist. Der Pfostenanzahl-Endpunkt dimensioniert den Rahmen: Ein Lauf benötigt einen Pfosten mehr als Spannweiten, Spannweiten = ceil(Lauf ÷ max. Pfostenabstand), Pfosten = Spannweiten + 1, gleichmäßiger Abstand = Lauf ÷ Spannweiten – ein 6 m Lauf bei einem max. 1,8 m benötigt 4 Spannweiten und 5 Pfosten bei einem sauberen 1,5 m. Alles wird lokal und deterministisch berechnet, also ist es sofort und privat. Ideal für Terrassen- und Geländerdesign-Tools, Fertigungs- und Schätzungs-Apps sowie Bau-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Verwendet die übliche 100-mm-Füllregel – bestätigen Sie Ihre örtliche Vorschrift. 3 Berechnungsendpunkte. Für Treppensteigung und -auftritt verwenden Sie eine Treppen-API; für Zaunlatten eine Zaun-API.

Uptime

100.0%

Latenz

76ms

Subs

4,589

Holzpellet-Heizungsmathematik als API, lokal und deterministisch berechnet – die Verbrauchs-, Wärmeleistungs- und Speicherzahlen, die ein Hausbesitzer, Installateur oder Heizungsplaner zur Dimensionierung eines Pelletsystems benötigt. Der Verbrauchs-Endpoint gibt die Pellets an, die einen Wärmebedarf decken = der Bedarf ÷ die nutzbare Wärme pro Kilo, wobei nutzbar = der Heizwert × der Kesselwirkungsgrad: ENplus-Holzpellets haben etwa 4,8 kWh/kg und ein moderner Pelletkessel läuft mit ~90 %, sodass jedes Kilo etwa 4,3 kWh liefert – ein jährlicher Bedarf von 10.000 kWh benötigt dann etwa 2,3 Tonnen Pellets, etwa 154 Fünfzehn-Kilo-Säcke oder eine Schüttgutlieferung. Der Wärmeleistungs-Endpoint kehrt es um: die nutzbare Wärme aus einer Masse = Masse × Heizwert × Wirkungsgrad, sodass eine Tonne ENplus-Pellets etwa 4.800 kWh brutto ergibt, von denen ein 90 %-Kessel ~4.320 kWh liefert – das Äquivalent von etwa 480 Litern Heizöl oder 432 m³ Erdgas. Der Speichervolumen-Endpoint dimensioniert den Behälter oder Silo: Speicher = die Pelletmasse ÷ die Schüttdichte, etwa 650 kg/m³ für ENplus, sodass 2,3 Tonnen etwa 3,6 m³ füllen – dimensionieren Sie den Speicher für die volle Lieferung plus Spielraum für das Einfüllrohr. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Pelletheizungs- und Installateur-Tools, Hausenergie- und Angebots-Apps sowie Rechner für erneuerbare Wärme. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofortig. Verwendet Standard-ENplus-Werte – legen Sie eigene für eine bestimmte Pelletklasse fest. 3 Berechnungs-Endpoints. Für Scheitholz verwenden Sie eine Brennholz-API; für Propan/Flüssiggas eine Propan-API.

Uptime

100.0%

Latenz

82ms

Subs

4,070

Drachenflug-Mathematik als API, lokal und deterministisch berechnet – die Leinenzug-, Höhen- und Mindestwind-Zahlen, mit denen ein Drachenflieger, Festivalorganisator oder eine Drachen-App einen Flug plant. Der Leinenzug-Endpunkt gibt die Spannung an, die ein Drachen auf die Leine ausübt ≈ ½ × Luftdichte × Windgeschwindigkeit² × Segelfläche × Kraftbeiwert (~0,8 für einen typischen Flach- oder Delta-Drachen): Da sie mit dem Quadrat des Windes steigt, vervierfacht eine Verdopplung des Windes den Zug – ein 1,5 m² großer Drachen hält etwa 47 N (fast 5 kgf) bei 8 m/s, aber das Vierfache bei einem starken Windstoß, daher müssen Leine und Griff auf die Böen ausgelegt sein, nicht auf den Durchschnitt. Der Höhen-Endpunkt gibt die Flughöhe = ausgelassene Leine × Sinus des Leinenwinkels über der Horizontalen, mit der Windabstands-Distanz aus dem Kosinus: 100 m Leine bei einem 45°-Winkel erreichen etwa 71 m Höhe und 71 m windabwärts, während ein schwerer oder unterfliegender Drachen auf einen niedrigen Winkel absackt und nie steigt. Der Min-Wind-Endpunkt gibt den leichtesten Wind an, der abhebt, wenn der aerodynamische Auftrieb gerade dem Gewicht entspricht: min Wind = √(2 × Masse × g ÷ (Luftdichte × Fläche × Auftriebsbeiwert)), also benötigt ein 200 g, 1,5 m² großer Drachen nur etwa 1,6 m/s (6 km/h) – leichtere Segel und größere Fläche senken die Schwelle. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Drachenflug- und Festival-Apps, Hobby- und MINT-Bildungswerkzeuge sowie Outdoor-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Flachdrachen-Schätzungen – kombinieren Sie mit echten Windmessungen. 3 Berechnungs-Endpunkte. Für Luftwiderstand und Endgeschwindigkeit verwenden Sie eine Luftwiderstands-API; für strukturelle Windlast eine Windlast-API.

Uptime

100.0%

Latenz

78ms

Subs

3,784

Vinyl-Record-Geometrie-Mathematik als API, lokal und deterministisch berechnet – die Spielzeit-, Rillenlängen- und Rillengeschwindigkeitszahlen, mit denen ein Schneidtechniker, eine Pressanlage oder ein Audio-Hobbyist eine Platte berechnet. Der Spielzeit-Endpunkt gibt die maximale Zeit einer Seite = die Anzahl der Rillenumdrehungen ÷ die Plattentellergeschwindigkeit, wobei die Umdrehungen = die radiale Breite des aufgezeichneten Bandes ÷ die Rillenteilung (der Abstand zwischen benachbarten Rillen): eine 12-Zoll-LP mit ~85 mm Band bei einer Teilung von 100 µm hat etwa 850 Umdrehungen, also bei 33⅓ U/min etwa 25 Minuten pro Seite – eine engere Teilung passt mehr Zeit, reduziert aber die Rillenamplitude und damit Lautstärke und Bass, der klassische Zeit-gegen-Lautstärke-Kompromiss. Der Rillenlängen-Endpunkt entrollt die Spirale: Länge ≈ Umdrehungen × der mittlere Umfang (π × der Durchschnitt von Außen- und Innendurchmesser), in der Größenordnung von 400–500 Metern für eine LP-Seite, die der Abtaster einmal abfährt. Der Rillengeschwindigkeits-Endpunkt gibt die lineare Geschwindigkeit unter dem Abtaster = 2π × U/min/60 × Radius, sodass die äußeren Rillen einer LP mit etwa 50 cm/s vorbeiziehen, die inneren jedoch nur ~20 cm/s – die Ursache für Innenrillenverzerrungen und warum Techniker leisere Tracks ans Ende setzen. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Platten-Schneide- und Mastering-Werkzeuge, HiFi- und Sammler-Apps sowie Audio-Engineering-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofortig. 3 Compute-Endpunkte. Für Musiknoten- und Tempo-Mathematik verwenden Sie eine Music-API.

Uptime

100.0%

Latenz

72ms

Subs

3,749

Sundial-Gnomonik-Mathematik als API, lokal und deterministisch berechnet – die Stundenlinien-, Gnomon- und Längenkorrekturzahlen, mit denen ein Zifferblattmacher, Uhrmacher oder Astronomie-Enthusiast eine Sonnenuhr entwirft. Der Stundenlinienwinkel-Endpunkt gibt den Winkel jeder Stundenlinie auf dem Zifferblatt an, gemessen von der Mittagslinie: Für ein horizontales Zifferblatt gilt tan(Winkel) = sin(Breitengrad) × tan(Stundenwinkel), und für ein vertikales südwärts gerichtetes Zifferblatt wird stattdessen cos(Breitengrad) verwendet, wobei der Stundenwinkel 15° pro Stunde ab Sonnenmittag beträgt. Bei 50° Breite liegt die 1-Uhr-Linie etwa 11,6° von Mittag entfernt, nicht 15° – die Linien bündeln sich nahe Mittag und spreizen sich zu den Enden hin, genau deshalb sind die Stunden einer Sonnenuhr ungleichmäßig verteilt. Der Gnomon-Endpunkt gibt den Stilwinkel an: Die schattenwerfende Kante des Gnomons muss auf den Himmelspol zeigen, daher steigt sie bei einem horizontalen Zifferblatt im Breitengradwinkel (50° bei 50° N) und bei einem vertikalen Zifferblatt um 90° − Breitengrad – wenn dies falsch ist, zeigt die Uhr nur in einer Jahreszeit die richtige Zeit an. Der Längenkorrektur-Endpunkt wandelt die lokale wahre Ortszeit der Sonnenuhr in die Uhrzeit um: 4 Minuten Zeit pro Längengrad, Korrektur = 4 × (Referenzmeridian − lokale Länge), daher zeigt eine Sonnenuhr bei 7,5° O in mitteleuropäischer Zeit 30 Minuten nach gegenüber der Uhr. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Sonnenuhr-Design- und Gnomonik-Werkzeuge, Astronomie-Bildungs- und Maker-Apps sowie Uhrmacher-Rechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofortig. Fügen Sie die Zeitgleichung für vollständige Uhrzeitgenauigkeit hinzu. 3 Berechnungsendpunkte. Für die Sonnenposition verwenden Sie eine Solarposition-API; für Sonnenaufgang und Sonnenuntergang eine Sonnenaufgangs-API.

Uptime

100.0%

Latenz

78ms

Subs

3,223

Metallguss- und Gießereimathematik als API, lokal und deterministisch berechnet – die Erstarrungszeit-, Schrumpfungs- und Schmelzgewichtszahlen, mit denen ein Gießer, Modellbauer oder Gusskonstrukteur arbeitet. Der Endpunkt für die Erstarrungszeit wendet die Chvorinov-Regel an, t = B × (V/A)², wobei V/A der Gussmodul (Volumen ÷ Kühloberfläche) und B die Formkonstante (~2–4 min/cm² für Sand) ist: Ein klobiges Teil mit wenig Oberfläche im Verhältnis zu seinem Volumen erstarrt langsam, ein dünnes schnell – und da ein Speiser länger flüssig bleiben muss als das von ihm gespeiste Gussteil, muss sein Modul größer sein, was die Zahl ist, die ihn dimensioniert. Der Endpunkt für die Musterschrumpfung macht das Modell überdimensioniert für das Metall, das beim Abkühlen schrumpft: Modell = Gussabmessung × (1 + Schrumpfung/100), die Kontraktionsregel des Modellbauers – etwa 1,0–1,6 % für Grauguss, ~2 % für Stahl und Aluminium – also benötigt ein 100 mm Stahlmerkmal ein 102 mm Modell. Der Endpunkt für das Schmelzgewicht gibt das Gussgewicht = Volumen × Metalldichte (Eisen ~7,2, Stahl ~7,85, Aluminium ~2,70 g/cm³) und das tatsächlich zu gießende Metall = Gussgewicht ÷ Gießausbeute, weil Anguss, Läufe und Speiser wiedereingeschmolzener Schrott sind – ein 7 kg Eisenguss bei 70 % Ausbeute benötigt etwa 10 kg in der Pfanne. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Gießerei- und Modellbauwerkzeuge, Gusskonstruktions- und Kalkulations-Apps sowie Metallbearbeitungsrechner. Reine lokale Berechnung – kein API-Key, kein Drittanbieterdienst, sofortig. 3 Compute-Endpunkte. Für das Gewicht eines Teils aus seinen Abmessungen verwenden Sie eine Metallgewicht-API; für Schweißverbindungen eine Schweiß-API.

Uptime

100.0%

Latenz

79ms

Subs

3,599

Basketball-Effizienzstatistik-Mathematik als API, lokal und deterministisch berechnet – die Wurfeffizienz- und Boxscore-Zahlen, mit denen ein Analyst, Trainer oder eine Sport-App eine Leistung bewertet. Der True-Shooting-Endpunkt fasst Zweier, Dreier und Freiwürfe in einer Zahl zusammen: TS% = Punkte ÷ (2 × (Feldtorversuche + 0,44 × Freiwurfversuche)) × 100, wobei die 0,44 annähert, wie viele Ballbesitze ein Freiwurfzug wirklich verbraucht – 25 Punkte bei 18 Feldtoren und 6 Freiwürfen entsprechen etwa 60,6 %, gegenüber einem Ligadurchschnitt von etwa 56–58 %. Der Effective-Field-Goal-Endpunkt bewertet einen Dreier mit 50 % mehr als einen Zweier: eFG% = (erzielte Feldtore + 0,5 × erzielte Dreier) ÷ Feldtorversuche × 100, sodass 9 Treffer inklusive 3 Dreiern bei 18 Versuchen 58,3 % gegenüber rohen 50 % ergeben, die Differenz ist der Wert des Distanzwurfs. Der Game-Score-Endpunkt berechnet John Hollingers Game Score, eine Einzelspiel-Produktivitätsbewertung, skaliert wie Punkte – PTS + 0,4·FGM − 0,7·FGA − 0,4·(FTA−FTM) + 0,7·ORB + 0,3·DRB + STL + 0,7·AST + 0,7·BLK − 0,4·PF − TOV – wobei etwa 10 ein durchschnittliches Spiel ist, 20+ ausgezeichnet und 40+ historisch, effizientes Scoring und Allround-Spiel belohnt, während Fehlwürfe und Ballverluste bestraft werden. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Basketball-Analysen und Boxscore-Tools, Fantasy- und Kommentar-Apps sowie Sportrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofortig. 3 Compute-Endpunkte. Für Baseball-Statistiken verwenden Sie eine Baseball-API; für Cricket eine Cricket-API.

Uptime

100.0%

Latenz

80ms

Subs

3,036

Cricket-Statistik-Mathematik als API, lokal und deterministisch berechnet – die Run-Rate, Strike-Rate und Chase-Zahlen, die ein Scorer, Kommentator oder eine Cricket-App Spiel für Spiel berechnet. Ein Over besteht aus sechs legalen Bällen, und Overs werden als ganze Overs plus Bälle angegeben, niemals als Dezimal-Overs – '20.3 Overs' bedeutet 20 Overs und 3 Bälle (20.5 in realen Zahlen), die klassische Cricket-Mathe-Falle, die diese API vermeidet. Der Run-Rate-Endpoint gibt die Runs pro Over = Runs ÷ (Bälle ÷ 6), also 150 Runs in 20 Overs sind 7.50 pro Over, und mit einer Ziel-Overs-Zahl wird die Innings-Punktzahl beim aktuellen Tempo prognostiziert. Der Strike-Rate-Endpoint gibt die Strike-Rate eines Batters = Runs ÷ gespielte Bälle × 100, die Runs pro 100 Bälle – 75 aus 50 ist eine Strike-Rate von 150, schnelles Scoring im Limited-Overs-Spiel; in Tests wird stattdessen eine niedrigere Strike-Rate mit einem hohen Durchschnitt geschätzt. Der Required-Rate-Endpoint behandelt eine Chase: die erforderliche Run-Rate = die noch benötigten Runs ÷ die verbleibenden Bälle × 6, also 80 Runs zum Sieg bei 10 verbleibenden Overs sind 8.00 pro Over – eine Zahl, die steil ansteigt, wenn die Bälle knapp werden, weshalb eine komfortable Chase in ein paar engen Overs kippen kann. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Cricket-Scoring- und Live-Score-Apps, Fantasy- und Kommentar-Tools sowie Sportrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. 3 Compute-Endpoints. Für Baseball-Statistiken verwenden Sie eine Baseball-API.

Uptime

100.0%

Latenz

78ms

Subs

4,390

Zeitraffer-Fotografie-Mathematik als API, lokal und deterministisch berechnet – die Clip-Länge, das Intervall und die Speicherzahlen, die ein Fotograf, Filmemacher oder eine Kamera-App für eine Sequenz plant. Der Clip-Länge-Endpunkt tauscht eine lange Aufnahme gegen einen kurzen Clip: die aufgenommenen Frames = die Aufnahmedauer ÷ das Intervall, und die Clip-Länge = diese Frames ÷ die Wiedergabebildrate – 60 Minuten Aufnahme mit einem Frame alle 5 Sekunden ergibt 720 Frames, und bei 24 fps ergibt das eine Wiedergabe von 30 Sekunden, eine 120-fache Beschleunigung. Längere Intervalle komprimieren die Zeit stärker, können aber bei schnellen Bewegungen ruckeln. Der Intervall-Endpunkt arbeitet rückwärts von einem Ziel-Clip: die benötigten Frames = die Ziel-Clip-Länge × die Bildrate, und das Intervall = die Aufnahmedauer ÷ diese Frames, also eine 60-minütige Aufnahme für einen 20-Sekunden-Clip bei 24 fps benötigt 480 Frames, einen alle 7,5 Sekunden. Der Speicher-Endpunkt dimensioniert die Karte und die Festplatte: Gesamtspeicher = die Frame-Anzahl × die Größe eines Frames, und da Zeitrafferaufnahmen in voller Auflösung (RAW ~20–30 MB pro Frame) gemacht werden, ergeben 720 RAW-Frames bei 25 MB etwa 18 GB für einen einzigen 30-Sekunden-Clip – weshalb eine lange Aufnahme schnell Karten frisst. Alles wird lokal und deterministisch berechnet, also ist es sofort und privat. Ideal für Zeitraffer- und Intervallometer-Apps, Fotografie-Planungswerkzeuge und Produktionsrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. 3 Berechnungs-Endpunkte. Für Videobitrate und Dateigröße verwenden Sie eine Bitrate-API.

Uptime

100.0%

Latenz

78ms

Subs

4,130

Jam- und Konserven-Mathematik als API, lokal und deterministisch berechnet – die Zucker-, Gelierpunkt- und Ertragszahlen, die ein Marmeladenhersteller, Konservenmacher oder Rezept-App für eine Charge benötigt. Der Zucker-Endpunkt setzt den Zucker aus dem Zucker-Frucht-Verhältnis: Eine traditionelle Vollzucker-Marmelade hat ein Verhältnis von 1:1, also 1 kg Frucht benötigt 1 kg Zucker für eine 2-kg-Charge mit 50 % Zucker, während niedrigere Verhältnisse (0,6–0,75) eine weichere, frischere, weniger süße Konserve ergeben, die zusätzliches Pektin benötigt und sich weniger gut hält – der Zucker konserviert und hilft beim Gelieren. Der Gelierpunkt-Endpunkt gibt die Geltemperatur an, angepasst an die Höhe: Marmelade geliert bei etwa 4,5 °C (8 °F) über der Temperatur, bei der Wasser kocht – 104,5 °C auf Meereshöhe – aber da Wasser in höheren Lagen niedriger kocht (etwa 1 °C pro 285 m), sinkt der Zielwert auf nahe 99 °C bei 1500 m, sodass das Kochen auf Meereshöhe in den Bergen die Charge überkocht. Der Ertrags-Endpunkt kocht die Charge auf einen Zielgehalt an löslichen Feststoffen (Brix) ein: Marmelade hält sich bei etwa 65 % Brix, das Endgewicht = die Feststoffe (Zucker plus der etwa 10 % Trockenmasse der Frucht) ÷ der Ziel-Brix, und der Rest verdampft als Wasser – 1 kg Zucker und 1 kg Frucht kochen auf etwa 1690 g Marmelade ein, wobei etwa 310 g Wasser verloren gehen. Alles wird lokal und deterministisch berechnet, also sofort und privat. Ideal für Konserven- und Rezept-Tools, Haushalts- und Küchen-Apps sowie Lebensmittelproduktionsrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Gel-Chemie, nicht Einmachsicherheit. 3 Compute-Endpunkte. Für die Höhenanpassung der Verarbeitungszeit verwenden Sie eine Einmach-API.

Uptime

100.0%

Latenz

77ms

Subs

4,167

Schwimm-Mathematik als API, lokal und deterministisch berechnet – die SWOLF-, Schwellen-Tempo- und Pro-100-m-Zahlen, mit denen ein Schwimmer, Trainer oder eine Trainings-App arbeitet. Der Swolf-Endpunkt bewertet die Schlagökonomie für eine Bahn: SWOLF (Schwimmen + Golf) = die Anzahl der Schläge plus die benötigten Sekunden, und wie beim Golf gilt: niedriger ist besser – weiter pro Schlag gleiten oder schneller schwimmen verbessert beides, sodass eine 25-m-Bahn in 18 Schlägen und 30 s einen SWOLF von 48 ergibt. Da dies von der Bahnlänge und dem Schwimmstil abhängt, wird der Wert auf 25 m normiert, sodass Bahnen in verschiedenen Becken vergleichbar sind. Der CSS-Endpunkt berechnet die Critical Swim Speed, das Schwellentempo des Schwimmers, aus zwei All-Out-Zeittests: CSS = (Distanz1 − Distanz2) ÷ (Zeit1 − Zeit2) – der klassische 400-m- und 200-m-Test, bei dem 6:00 und 2:50 etwa 1,05 m/s ergeben, eine Schwelle von 1:35 / 100 m; Trainingsgeschwindigkeiten werden dann als Abweichungen von CSS festgelegt, das Äquivalent zur Laufschwelle oder zum 2-km-Tempo auf dem Ergometer. Der Pace-Endpunkt liefert Geschwindigkeit und das Pro-100-m-Tempo, das Schwimmer tatsächlich angeben (Zeit ÷ Distanz × 100), also 100 m in 1:30 ergibt ein Tempo von 1:30 / 100 m bei 1,11 m/s. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Schwimm-Trainings- und Coaching-Tools, Bahn-Tracker- und Triathlon-Apps sowie Fitnessrechner. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. 3 Compute-Endpunkte. Für Lauftempo verwenden Sie eine Pace-API; für Indoor-Rudern eine Ruder-API.

Uptime

100.0%

Latenz

82ms

Subs

4,238