API marketplace

The Visual Novel Database (VNDB) as an API — clean JSON, no key. Search and look up visual novels with their titles, release dates, languages, platforms, play length, Bayesian rating and vote count, description, cover image, developers and genre/theme tags (spoiler tags filtered out). Search and open characters with their original name, aliases, description, sex, age, blood type and the visual novels they appear in, and search and open producers and developers. Plus live database statistics. Live data straight from vndb.org, the definitive visual-novel database. A distinct medium from anime and manga — ideal for visual-novel trackers, discovery and recommendation apps, wikis and otaku tools. 7 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

154ms

Subs

4,012

MangaDex as an API — the largest community manga library, returned as clean JSON, no key. Search manga by title; open a manga for its full detail (titles and alternates, description, status, year, demographic, content rating, genre and theme tags, authors, artists and cover art); pull a manga's chapter feed in any translated language; get a chapter's detail; and fetch the ready-to-render page-image URLs for a chapter — the reader endpoint, in full and data-saver quality. Look up an author and list every genre and theme tag. Live data straight from MangaDex. Distinct from anime/manga metadata APIs: this is the actual reading platform — real chapters and page images across thousands of scanlations — ideal for manga readers, trackers, discovery and library apps. 7 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

281ms

Subs

4,151

The US Supreme Court as an API, powered by Oyez — clean JSON, no key. Browse cases by term and open any case for its full detail: the parties, the facts, the legal question, the conclusion, a dated timeline, the lower court, and the decision with each justice's individual vote and opinion. Pull the oral-argument transcript for a case — every speaker turn with start/stop timestamps and a link to the audio — ideal for analysis, search and captioning. List all the justices and open a justice's profile (dates, places, seats held). Live data straight from oyez.org, the definitive multimedia archive of the Supreme Court. Distinct, authoritative civic data — ideal for legal-tech, research, education, news and civic apps. 5 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

477ms

Subs

4,725

Lichess as an API — the open-source chess platform, returned as clean JSON, no key. Look up any player's profile (titles, ratings across bullet, blitz, rapid and classical, game counts, country, FIDE rating), their rating history per variant and online status; pull the top players for any performance type; fetch a user's recent games with openings, clocks, results and full move lists; get a Stockfish cloud evaluation of any position by FEN (best lines, centipawn or mate scores); serve the daily puzzle or any puzzle by id (with solution and themes); and list current, upcoming and finished tournaments. Live data straight from lichess.org. Distinct from Chess.com player stats: Lichess is its own platform with cloud engine analysis, a puzzle database and arena tournaments — ideal for chess apps, coaching tools, analysis boards, bots and leaderboards. 9 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

765ms

Subs

4,396

Audius as an API — the decentralised music streaming platform, returned as clean JSON, no key. Search tracks, artists and playlists; pull trending tracks by genre and time window; look up a track (genre, mood, bpm, musical key, ISRC, play/favourite/repost counts, artwork and a durable stream URL), an artist (followers, track and playlist counts, bio, location) by id or @handle, an artist's own tracks, and a playlist or album with its full track list. Every track comes with a ready-to-play stream URL and a preview URL. Live data straight from the Audius discovery network. Distinct from mainstream catalogues: Audius is an independent, creator-owned catalogue of electronic, hip-hop and underground music with actual streamable audio — ideal for music-discovery apps, players, DJ tools and Web3 music projects. 8 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

632ms

Subs

3,254

Mixcloud as an API — the home of long-form audio: DJ mixes, radio shows and podcasts, returned as clean JSON, no key. Search cloudcasts, users or tags; look up a user profile (followers, listens, location, picture) and their shows; get a cloudcast's full detail — play count, favourites, reposts, listener count, audio length, tags and uploader; read a show's comments; pull the trending cloudcasts for any tag or category; and list Mixcloud's categories. Live data straight from Mixcloud's public API. Distinct from track-based music APIs: Mixcloud is hour-long mixes, broadcast archives and shows — ideal for music-discovery apps, radio and DJ directories, podcast tools and audio dashboards. 8 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

424ms

Subs

3,900

Spotify music and podcast metadata as an API — no login, no OAuth. Resolve any Spotify track, album, artist or playlist by its id, spotify: URI or open.spotify.com URL and get clean JSON: names, the canonical Spotify ids and URIs, cover art, release dates, durations, explicit flags and 30-second audio previews. Albums come back with their full track list, artists with their top tracks, and playlists with their tracks and owner. A universal resolve endpoint auto-detects the entity type from any Spotify link, and an oEmbed endpoint returns the title, thumbnail and embeddable player HTML for any Spotify URL. Live data straight from Spotify's public embed. Ideal for enriching your catalogue with Spotify ids, building "listen on Spotify" links, previewing tracks, and matching music across services. 6 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

319ms

Subs

3,488

The open music-metadata database as an API — artists, release-groups (albums), releases, recordings and labels, identified by stable MusicBrainz IDs (MBIDs), returned as clean JSON. Search any entity by name or Lucene query; look up an artist with their external links and tags, an album, a release with its full track list, a recording with its ISRCs, or a label; and browse an artist's complete discography. Live data with MBIDs, disambiguations, types, countries, life spans, ISRCs, barcodes, catalogue numbers and relations — the canonical identifiers that link and de-duplicate music data across services. Ideal for metadata enrichment and matching, music catalogues, tagging and library tools, and research. 11 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

376ms

Subs

4,961

Real-time Pinterest data as an API — pins, boards and users, returned as clean JSON. Search pins, boards or users by keyword; look up any user's profile with follower, pin and board counts; pull a user's boards and their pins; fetch a pin's details (repins, comments, image, link, domain, pinner) and its related pins; and fetch a board's details and its pins. Live data with titles, descriptions, full-resolution image URLs, outbound links, repin and comment counts, dominant colours and creators. Ideal for social listening and trend research, content aggregation and discovery, e-commerce and visual-marketing tools, and dashboards. 10 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

1859ms

Subs

4,555

Real-time Genius music data as an API — songs, artists, albums and full song lyrics, returned as clean JSON. Search songs, or search across songs, artists and albums at once; fetch a song, artist or album by id; list an artist's songs ranked by popularity; and pull the full, cleaned lyrics of any song by id or by Genius URL. Live data with titles, primary and featured artists, page views, release dates, artwork, follower counts and social handles. The lyrics endpoint returns the complete song text with section markers ([Verse], [Chorus]) and the contributor header stripped. Ideal for music and lyrics apps, karaoke and sing-along tools, sentiment and language analysis, and metadata enrichment. 7 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

2304ms

Subs

3,929

Real-time Apple iTunes catalogue data as an API — music, podcasts, ebooks and audiobooks, plus artist, album and podcast lookups, returned as clean JSON. Search songs, albums, podcasts, ebooks and audiobooks, or run a general search across any media type; look up any item by its iTunes id; fetch an artist with their albums and songs; fetch an album with its full track list; and fetch a podcast with its recent episodes. Live data with names, artists, artwork (upscaled), preview URLs, genres, prices, release dates, content ratings, track counts and podcast feed URLs. Ideal for music and podcast apps, media-catalogue and metadata enrichment, discovery and recommendation tools, and research. 12 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

188ms

Subs

3,411

Real-time Deezer music data as an API — tracks, albums, artists, playlists, charts and genres, returned as clean JSON. Search the catalogue for tracks, albums, artists and playlists; fetch any track, album (with its track list), artist or playlist by id; get an artist's top tracks and full discography; pull the global charts (top tracks, albums, artists and playlists) and the list of genres. Live data with titles, durations, ranks, fan counts, cover and picture art, 30-second preview URLs, release dates and explicit flags. Ideal for music apps and players, recommendation and discovery tools, metadata enrichment, dashboards and research. 12 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

530ms

Subs

4,864

Real-time Reddit data as an API — subreddits, posts, comments, user profiles and search, returned as clean JSON. Pull a subreddit's info and its hot, new, top or rising posts; fetch a post together with its full comment tree; look up any user's profile, karma, submissions and comments; search posts across all of Reddit or within one subreddit; and list the trending posts and the most popular subreddits. Live data, paginated with Reddit cursors, with scores, upvote ratios, comment counts, flair, timestamps, thumbnails and media URLs. Ideal for social listening and brand monitoring, trend and sentiment dashboards, content aggregation, research and market intelligence, and bots. 11 data endpoints. Authenticated with an x-oanor-key; fair-use rate limits per plan.

Uptime

100.0%

Latency

1809ms

Subs

4,986

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

Uptime

100.0%

Latency

76ms

Subs

4,589

Wood-pellet heating maths as an API, computed locally and deterministically — the consumption, heat-output and storage numbers a homeowner, installer or heating planner sizes a pellet system by. The consumption endpoint gives the pellets to meet a heat demand = the demand ÷ the usable heat per kilo, where usable = the calorific value × the boiler efficiency: ENplus wood pellets hold about 4.8 kWh/kg and a modern pellet boiler runs ~90 %, so each kilo delivers roughly 4.3 kWh — a 10,000 kWh annual demand then needs about 2.3 tonnes of pellets, around 154 fifteen-kilo bags or a bulk delivery. The heat-output endpoint inverts it: the usable heat from a mass = mass × calorific value × efficiency, so a tonne of ENplus pellets is about 4,800 kWh gross of which a 90 % boiler delivers ~4,320 kWh — the equivalent of roughly 480 litres of heating oil or 432 m³ of natural gas. The storage-volume endpoint sizes the hopper or silo: storage = the pellet mass ÷ the bulk (poured) density, about 650 kg/m³ for ENplus, so 2.3 tonnes fill roughly 3.6 m³ — size the store for the full delivery plus headroom for the fill pipe. Everything is computed locally and deterministically, so it is instant and private. Ideal for pellet-heating and installer tools, home-energy and quoting apps, and renewable-heat calculators. Pure local computation — no key, no third-party service, instant. Uses standard ENplus figures — set your own for a specific pellet grade. 3 compute endpoints. For cordwood use a firewood API; for propane/LPG a propane API.

Uptime

100.0%

Latency

82ms

Subs

4,070

Kite-flying maths as an API, computed locally and deterministically — the line-pull, altitude and minimum-wind numbers a kite flyer, festival organiser or kite app works a flight out with. The line-pull endpoint gives the tension a kite puts on the line ≈ ½ × air density × wind speed² × sail area × a force coefficient (~0.8 for a typical flat or delta kite): because it rises with the square of the wind, doubling the wind quadruples the pull — a 1.5 m² kite holds about 47 N (nearly 5 kgf) at 8 m/s but four times that in a strong blow, so the line and your grip must be sized to the gusts, not the average. The altitude endpoint gives the flying height = the line let out × the sine of the line angle above the horizontal, with the downwind distance from the cosine: 100 m of line at a 45° angle reaches about 71 m up and 71 m downwind, while a heavy or under-flown kite sags to a low angle and never climbs. The min-wind endpoint gives the lightest wind that lifts off, where the aerodynamic lift just equals the weight: min wind = √(2 × mass × g ÷ (air density × area × lift coefficient)), so a 200 g, 1.5 m² kite needs only about 1.6 m/s (6 km/h) — lighter sails and bigger area drop the threshold. Everything is computed locally and deterministically, so it is instant and private. Ideal for kite-flying and festival apps, hobby and STEM-education tools, and outdoor calculators. Pure local computation — no key, no third-party service, instant. Flat-kite estimates — combine with real wind readings. 3 compute endpoints. For drag and terminal velocity use a drag API; for structural wind load a wind-load API.

Uptime

100.0%

Latency

78ms

Subs

3,784

Vinyl-record geometry maths as an API, computed locally and deterministically — the playing-time, groove-length and groove-speed numbers a cutting engineer, pressing plant or audio hobbyist works a record out with. The playing-time endpoint gives a side's maximum time = the number of groove turns ÷ the turntable speed, where the turns = the recorded band's radial width ÷ the groove pitch (the spacing between adjacent grooves): a 12-inch LP with ~85 mm of band at a 100 µm pitch holds about 850 turns, so at 33⅓ rpm that is roughly 25 minutes a side — a tighter pitch fits more time but cuts groove amplitude and so loudness and bass, the classic time-versus-level trade. The groove-length endpoint unrolls the spiral: length ≈ turns × the mean circumference (π × the average of the outer and inner diameters), on the order of 400–500 metres for an LP side, the whole of which the stylus traces once. The groove-speed endpoint gives the linear speed under the stylus = 2π × rpm/60 × radius, so the outer grooves of an LP pass at about 50 cm/s but the inner ones only ~20 cm/s — the cause of inner-groove distortion and why engineers place quieter tracks last. Everything is computed locally and deterministically, so it is instant and private. Ideal for record-cutting and mastering tools, hi-fi and collector apps, and audio-engineering calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For musical note and tempo maths use a music API.

Uptime

100.0%

Latency

72ms

Subs

3,749

Sundial gnomonics maths as an API, computed locally and deterministically — the hour-line, gnomon and longitude-correction numbers a dial maker, horologist or astronomy hobbyist lays a sundial out with. The hour-line-angle endpoint gives the angle of each hour line on the dial plate, measured from the noon line: for a horizontal dial tan(angle) = sin(latitude) × tan(hour angle), and for a vertical south-facing dial cos(latitude) is used instead, where the hour angle is 15° per hour from solar noon. At 50° latitude the 1-o'clock line sits about 11.6° from noon rather than 15° — the lines bunch near noon and spread toward the ends, which is exactly why a sundial's hours are unevenly spaced. The gnomon endpoint gives the style angle: the gnomon's shadow-casting edge must point at the celestial pole, so it rises at the latitude angle on a horizontal dial (50° at 50° N) and at 90° − latitude on a vertical dial — get this wrong and the dial keeps correct time at only one season. The longitude-correction endpoint converts the dial's local apparent time to clock time: 4 minutes of time per degree of longitude, correction = 4 × (reference meridian − local longitude), so a dial at 7.5° E on Central European Time reads 30 minutes slow versus the clock. Everything is computed locally and deterministically, so it is instant and private. Ideal for sundial-design and gnomonics tools, astronomy-education and maker apps, and horology calculators. Pure local computation — no key, no third-party service, instant. Add the equation of time for full clock accuracy. 3 compute endpoints. For the sun's position use a solar-position API; for sunrise and sunset a sunrise API.

Uptime

100.0%

Latency

78ms

Subs

3,223

Metal-casting and foundry maths as an API, computed locally and deterministically — the solidification-time, shrinkage and melt-weight numbers a foundryman, patternmaker or casting designer works a job to. The solidification-time endpoint applies Chvorinov's rule, t = B × (V/A)², where V/A is the casting modulus (volume ÷ cooling surface area) and B is the mould constant (~2–4 min/cm² for sand): a chunky part with little surface for its volume freezes slowly, a thin one fast — and because a riser must stay molten longer than the casting it feeds, its modulus has to be larger, which is the number that sizes it. The pattern-shrinkage endpoint makes the pattern oversize for the metal that shrinks as it cools: pattern = casting dimension × (1 + shrinkage/100), the patternmaker's contraction rule — about 1.0–1.6 % for grey iron, ~2 % for steel and aluminium — so a 100 mm steel feature needs a 102 mm pattern. The melt-weight endpoint gives the casting weight = volume × metal density (iron ~7.2, steel ~7.85, aluminium ~2.70 g/cm³) and the metal to actually pour = casting weight ÷ the casting yield, because the sprue, runners and risers are remelted scrap — a 7 kg iron casting at 70 % yield needs about 10 kg in the ladle. Everything is computed locally and deterministically, so it is instant and private. Ideal for foundry and patternmaking tools, casting-design and estimating apps, and metalworking calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For a part's weight from its dimensions use a metal-weight API; for welded joints a welding API.

Uptime

100.0%

Latency

79ms

Subs

3,599

Basketball efficiency-stats maths as an API, computed locally and deterministically — the shooting-efficiency and box-score numbers an analyst, coach or sports app rates a performance by. The true-shooting endpoint folds twos, threes and free throws into one number: TS% = points ÷ (2 × (field-goal attempts + 0.44 × free-throw attempts)) × 100, where the 0.44 approximates how many possessions a free-throw trip really uses — 25 points on 18 field goals and 6 free throws is about 60.6 %, against a league average near 56–58 %. The effective-field-goal endpoint credits a three for being worth 50 % more than a two: eFG% = (field goals made + 0.5 × threes made) ÷ field-goal attempts × 100, so 9 makes including 3 threes on 18 attempts is 58.3 % versus a raw 50 %, the gap being the value of the long ball. The game-score endpoint computes John Hollinger's Game Score, a single-game productivity rating scaled like points — 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 — where about 10 is an average game, 20+ excellent and 40+ historic, rewarding efficient scoring and all-round play while docking misses and turnovers. Everything is computed locally and deterministically, so it is instant and private. Ideal for basketball analytics and box-score tools, fantasy and commentary apps, and sports calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For baseball stats use a baseball API; for cricket a cricket API.

Uptime

100.0%

Latency

80ms

Subs

3,036

Cricket statistics maths as an API, computed locally and deterministically — the run-rate, strike-rate and chase numbers a scorer, commentator or cricket app works a match by. An over is six legal balls, and overs are given as whole overs plus balls, never as decimal overs — '20.3 overs' means 20 overs and 3 balls (20.5 in real terms), the classic cricket-maths trap this API avoids. The run-rate endpoint gives the runs per over = runs ÷ (balls ÷ 6), so 150 runs off 20 overs is 7.50 an over, and with a target overs figure it projects the innings score at the current pace. The strike-rate endpoint gives a batter's strike rate = runs ÷ balls faced × 100, the runs per 100 balls — 75 off 50 is a strike rate of 150, fast scoring in the limited-overs game; in Tests a lower strike rate with a high average is prized instead. The required-rate endpoint handles a chase: the required run rate = the runs still needed ÷ the balls left × 6, so needing 80 to win with 10 overs left is 8.00 an over — a figure that climbs sharply as balls run out, which is why a comfortable chase can tip away in a couple of tight overs. Everything is computed locally and deterministically, so it is instant and private. Ideal for cricket scoring and live-score apps, fantasy and commentary tools, and sports calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For baseball stats use a baseball API.

Uptime

100.0%

Latency

78ms

Subs

4,390

Time-lapse photography maths as an API, computed locally and deterministically — the clip-length, interval and storage numbers a photographer, filmmaker or camera app plans a sequence with. The clip-length endpoint trades a long shoot for a short clip: the frames captured = the shoot duration ÷ the interval, and the clip length = those frames ÷ the playback frame rate — shooting for 60 minutes at one frame every 5 seconds gives 720 frames, and at 24 fps that plays back in 30 seconds, a 120× speed-up. Longer intervals compress time harder but can stutter on fast motion. The interval endpoint works backwards from a target clip: the frames needed = the target clip length × the frame rate, and the interval = the shoot duration ÷ those frames, so a 60-minute shoot for a 20-second clip at 24 fps needs 480 frames, one every 7.5 seconds. The storage endpoint sizes the card and disk: total storage = the frame count × the size of one frame, and because time-lapse shoots full-resolution stills (RAW ~20–30 MB each), 720 RAW frames at 25 MB is about 18 GB for a single 30-second clip — which is why a long lapse eats cards fast. Everything is computed locally and deterministically, so it is instant and private. Ideal for time-lapse and intervalometer apps, photography-planning tools, and production calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For video bitrate and file size use a bitrate API.

Uptime

100.0%

Latency

78ms

Subs

4,130

Jam and preserve maths as an API, computed locally and deterministically — the sugar, setting-point and yield numbers a jam maker, preserver or recipe app works a batch to. The sugar endpoint sets the sugar from the sugar-to-fruit ratio: a traditional full-sugar jam is 1:1, so 1 kg of fruit takes 1 kg of sugar for a 2 kg batch at 50 % sugar, while lower ratios (0.6–0.75) make a softer, fresher, less-sweet preserve that needs added pectin and keeps less well — the sugar both preserves and helps the gel. The setting-point endpoint gives the gel temperature adjusted for altitude: jam sets at about 4.5 °C (8 °F) above the temperature water boils at — 104.5 °C at sea level — but because water boils lower as you climb (roughly 1 °C per 285 m), the target falls to near 99 °C at 1500 m, so cooking to the sea-level figure up a mountain over-boils the batch. The yield endpoint boils the batch down to a target soluble-solids (Brix): jam keeps at about 65 % Brix, the finished weight = the solids (sugar plus the fruit's own ~10 % dry matter) ÷ the target Brix, and the rest evaporates as water — 1 kg sugar and 1 kg fruit boils down to about 1690 g of jam, losing roughly 310 g of water. Everything is computed locally and deterministically, so it is instant and private. Ideal for preserving and recipe tools, homestead and kitchen apps, and food-production calculators. Pure local computation — no key, no third-party service, instant. Gel chemistry, not canning safety. 3 compute endpoints. For processing-time altitude adjustment use a canning API.

Uptime

100.0%

Latency

77ms

Subs

4,167

Swimming maths as an API, computed locally and deterministically — the SWOLF, threshold-pace and per-100 m numbers a swimmer, coach or training app works a set out with. The swolf endpoint scores stroke efficiency for one length: SWOLF (swim + golf) = the strokes taken plus the seconds taken, and like golf lower is better — gliding further per stroke or swimming faster both cut it, so a 25 m length in 18 strokes and 30 s is a SWOLF of 48. Because it is pool-length and stroke dependent, the score is normalized to 25 m so lengths in different pools compare. The css endpoint computes Critical Swim Speed, the swimmer's threshold pace, from two all-out time trials: CSS = (distance1 − distance2) ÷ (time1 − time2) — the classic 400 m and 200 m test, where 6:00 and 2:50 give about 1.05 m/s, a 1:35 / 100 m threshold; training paces are then set as offsets from CSS, the swimmer's equivalent of a runner's threshold or an erg's 2 k pace. The pace endpoint gives speed and the per-100 m pace swimmers actually quote (time ÷ distance × 100), so 100 m in 1:30 is a 1:30 / 100 m pace at 1.11 m/s. Everything is computed locally and deterministically, so it is instant and private. Ideal for swim-training and coaching tools, lap-tracker and triathlon apps, and fitness calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For running pace use a pace API; for indoor rowing a rowing API.

Uptime

100.0%

Latency

82ms

Subs

4,238