API marketplace

Type-K thermocouple temperature/voltage conversion as an API, computed locally and deterministically from the official NIST ITS-90 reference functions. The voltage endpoint converts a junction temperature in °C to the thermo-electromotive force in millivolts using the NIST type-K direct polynomial (with its Gaussian correction term above 0 °C), and performs cold-junction compensation by subtracting the reference-junction EMF, so a hot junction at 200 °C against a 25 °C terminal block gives the EMF your meter actually reads; a type-K junction produces 4.096 mV at 100 °C and 41.276 mV at 1000 °C against a 0 °C reference. The temperature endpoint does the inverse: it takes the measured EMF in millivolts and the reference-junction temperature, refers the reading back to 0 °C by adding the cold-junction EMF, and returns the hot-junction temperature in °C and K — obtained by numerically inverting the same monotonic forward polynomial, so it is exactly consistent with the forward conversion. Type K (chromel–alumel) covers −270 to 1372 °C. Everything is computed locally and deterministically, so it is instant and private. Ideal for industrial-automation, process-control, data-acquisition, IoT-sensor, furnace and lab-instrument app developers, sensor-linearization and cold-junction-compensation tools, and embedded firmware. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This is the type-K thermocouple; for resistance-temperature detectors use an RTD/PT100 API.

Uptime

100.0%

Latency

81ms

Subs

3,133

First-order RC and RL passive-filter design as an API, computed locally and deterministically. The lowpass and highpass endpoints take a resistor and capacitor (RC) or a resistor and inductor (RL) and return the −3 dB cutoff frequency (fc = 1/(2πRC) for RC, R/(2πL) for RL), the time constant (τ = RC or L/R) and the angular cutoff; pass a frequency as well and they add the magnitude response as a linear gain and in decibels and the phase shift in degrees — a 1 kΩ / 1 µF low-pass has fc ≈ 159.15 Hz, and right at the cutoff the gain is −3.01 dB with −45° phase for a low-pass or +45° for a high-pass. The component endpoint solves the missing one of fc, R and C from the other two (fc = 1/(2πRC)), so you can size a resistor or capacitor for a target cutoff. All quantities are SI: ohms, farads, henries and hertz. Everything is computed locally and deterministically, so it is instant and private. Ideal for electronics, audio, embedded, signal-processing and EE-education app developers, filter-design and circuit-sizing tools, and maker software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is first-order single-pole filter design; for full RLC impedance and resonance use an impedance API and for stored capacitor energy a capacitor API.

Uptime

100.0%

Latency

82ms

Subs

4,175

Isotropic elastic-constant mechanics as an API, computed locally and deterministically. The convert endpoint takes any two of the five linear-elastic constants — Young’s modulus E, shear modulus G, bulk modulus K, Poisson’s ratio ν and the first Lamé parameter λ — and returns all five, using the standard isotropic relations (G = E/(2(1+ν)), K = E/(3(1−2ν)), λ = Eν/((1+ν)(1−2ν)) and their inversions for the pairs E+ν, G+ν, K+ν, E+G, E+K, K+G, G+λ, K+λ and λ+ν); steel given E = 200 GPa and ν = 0.3 comes back as G ≈ 76.92 GPa, K ≈ 166.67 GPa and λ ≈ 115.38 GPa. The wave-speeds endpoint computes the longitudinal (P) and shear (S) elastic wave speeds from two moduli and the density, vp = √((K + 4G/3)/ρ) and vs = √(G/ρ), together with the vp/vs ratio used in seismology and ultrasonic testing — steel comes out at about 5860 m/s for P-waves and 3130 m/s for S-waves. Moduli convert in whatever consistent unit you supply (the wave-speed endpoint expects strict SI: pascals and kg/m³ for metres per second). Everything is computed locally and deterministically, so it is instant and private. Ideal for materials-science, mechanical-engineering, geophysics, seismology, ultrasonic-NDT and FEA app developers, material-property and rock-physics tools, and simulation software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This interconverts elastic constants; for Young’s modulus from a stress/strain tensile test use a Young’s-modulus API.

Uptime

100.0%

Latency

80ms

Subs

3,086

Rigid-body rotational-inertia mechanics as an API, computed locally and deterministically. The shape endpoint returns the mass moment of inertia and the radius of gyration k = √(I/m) for a named standard body about its characteristic axis — a solid sphere (I = 2/5·m·r²), thin spherical shell (2/3·m·r²), solid cylinder or disk (1/2·m·r²), annular/hollow cylinder (1/2·m·(r1²+r2²)), thin ring (m·r²), thin rod about its centre (1/12·m·l²) or about one end (1/3·m·l²), rectangular plate or cuboid (1/12·m·(a²+b²)), solid cone (3/10·m·r²) and point mass (m·r²) — so a 2 kg solid sphere of radius 0.5 m has I = 0.2 kg·m². The parallel-axis endpoint applies the Steiner theorem I = I_cm + m·d² to shift a moment of inertia from the centre-of-mass axis to any parallel axis a distance d away. The shapes endpoint lists the whole catalog with its formulas. All quantities are SI (kg, m → kg·m²). Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical-engineering, robotics, CAD/CAE, rotating-machinery, structural-dynamics and physics-education app developers, flywheel-and-shaft design tools, and simulation software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is rotational inertia; for stored rotational energy and flywheel sizing use a flywheel API and for torque and angular acceleration a torque API.

Uptime

100.0%

Latency

80ms

Subs

4,271

Optical-prism geometry as an API, computed locally and deterministically. The deviation endpoint computes the minimum deviation angle of a light ray passing through a prism of apex angle A and refractive index n, δ_min = 2·arcsin(n·sin(A/2)) − A, together with the symmetric angle of incidence and the internal refraction angle A/2 on each face — an equilateral prism (A = 60°) of crown glass (n = 1.5) deviates light by about 37.2°. The refractive-index endpoint inverts the spectrometer formula n = sin((A + δ_min)/2) / sin(A/2), the standard way a refractive index is measured from a prism’s apex angle and its measured minimum deviation. The dispersion endpoint computes the angular dispersion between two wavelengths from their refractive indices and the apex angle, and, given the three Fraunhofer indices n_F, n_C and n_D, the dispersive power ω = (n_F − n_C)/(n_D − 1) and the Abbe number V = 1/ω that quantify how strongly a glass spreads colours — crown glass has ω ≈ 0.017 and V ≈ 59. All angles are in degrees. Everything is computed locally and deterministically, so it is instant and private. Ideal for optics, spectroscopy, refractometry, photonics and physics-education app developers, lens-and-prism design tools, and lab software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is prism geometry; for a single flat-surface refraction use a Snell’s-law API and for thin lenses a lens API.

Uptime

100.0%

Latency

85ms

Subs

4,478

Vapor-pressure thermodynamics as an API, computed locally and deterministically. The clausius-clapeyron endpoint predicts the vapor pressure of a substance at a new temperature from a known reference point and the molar enthalpy of vaporization, using ln(P2/P1) = -ΔHvap/R·(1/T2 - 1/T1) with temperatures in kelvin — so from water boiling at 101.325 kPa at 373.15 K and ΔHvap ≈ 40.66 kJ/mol it returns about 42.6 kPa at 350 K. The enthalpy endpoint inverts the same relation: given two pressure/temperature points it solves for the molar enthalpy of vaporization, ΔHvap = -R·ln(P2/P1)/(1/T2 - 1/T1), in J/mol and kJ/mol. The antoine endpoint evaluates the Antoine equation log10(P) = A - B/(C + T) both ways — supply a temperature to get the vapor pressure, or a pressure to get the boiling temperature — defaulting to the water constants (°C and mmHg, so water reads 760 mmHg at 100 °C) but accepting any A, B, C for other substances. The gas constant R = 8.314462618 J/(mol·K). Everything is computed locally and deterministically, so it is instant and private. Ideal for chemical-engineering, process-simulation, distillation, HVAC, meteorology and chemistry-education app developers, boiling-point and phase-equilibrium tools, and lab software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is vapor pressure and boiling point; for humidity and dew point use a psychrometric API and for ideal-gas state use a gas-law API.

Uptime

100.0%

Latency

79ms

Subs

3,271

Biorhythm calculation as an API, computed locally and deterministically — a fun, for-entertainment model of three sine-wave cycles that supposedly run from the day you are born: a 23-day physical cycle, a 28-day emotional cycle and a 33-day intellectual cycle, each given by sin(2π·days/period). The cycles endpoint computes the three percentages and their phase (rising, falling or a critical zero-crossing where the cycle changes sign) for a given date, plus the average. The range endpoint returns the daily values over a window of up to 60 days from a start date, ready to plot as three sine waves. The compatibility endpoint compares two birthdates and gives, for each cycle, a defined heuristic compatibility score (1 + cos(2π·Δdays/period))/2 — 100 % when two people's cycles are perfectly in phase and 0 % when exactly opposite — and an overall score. Dates are in YYYY-MM-DD form. Biorhythms have no scientific basis; this is purely an entertainment tool. Everything is computed locally and deterministically, so it is instant and private. Ideal for lifestyle, horoscope, wellness, game and novelty app developers, daily-widget and compatibility tools, and fun dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is the entertainment biorhythm; for name and birthdate numerology use a numerology API and for star signs a zodiac API.

Uptime

100.0%

Latency

78ms

Subs

3,768

Light-travel-time astronomy maths as an API, computed locally and deterministically. The travel-time endpoint computes how long light takes to cross a distance, t = d/c with c = 299,792,458 m/s exactly, accepting the distance in metres, kilometres, miles, astronomical units, light-years, parsecs or light-seconds/minutes and returning the time in seconds, minutes, hours, days and years — light from the Sun reaches Earth in about 8.3 minutes and the nearest star is about 4.2 light-years away. The distance endpoint inverts the relation, d = c·t, to give how far light travels in a time, returning the distance in metres, kilometres, astronomical units, light-years and parsecs — one light-year is about 9.461×10¹⁵ m. The round-trip endpoint computes the one-way and round-trip communication delay to a target, d/c and 2·d/c, the light-speed latency that makes distant spacecraft control so slow and Mars rovers largely autonomous. Distance units include light-second and light-minute and time units run from seconds to years. Everything is computed locally and deterministically, so it is instant and private. Ideal for astronomy, space-mission, education, science-communication and simulation app developers, communication-delay and cosmic-distance tools, and physics teaching. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is light travel time; for an object's angular size use an angular-size API and for sidereal time a sidereal API.

Uptime

100.0%

Latency

82ms

Subs

4,804

Black-hole general-relativity maths as an API, computed locally and deterministically. The radius endpoint computes the Schwarzschild radius r_s = 2GM/c² — the event horizon of a non-rotating black hole — from a mass given in kilograms or solar masses, together with the photon sphere at 1.5·r_s and the innermost stable circular orbit (ISCO) at 3·r_s; the Sun would have an event horizon about 2.95 km across and the Earth about 9 mm. The time-dilation endpoint computes the gravitational time-dilation factor √(1 − r_s/r) at a distance r from a mass — a clock deep in a gravity well ticks slower than a far-away clock, and at the horizon time appears to stop. The hawking endpoint computes the Hawking temperature T = ħc³/(8πGMk_B), which is higher for smaller black holes, and the evaporation time, which scales as the cube of the mass — a solar-mass black hole would take about 10^67 years to evaporate. Masses are in kilograms or solar masses and distances in metres, using G, c, ħ and the Boltzmann constant. Everything is computed locally and deterministically, so it is instant and private. Ideal for astrophysics, cosmology, science-communication, simulation and education app developers, black-hole and relativity tools, and physics teaching. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is general-relativity black-hole physics; for special relativity (Lorentz factor, E=mc²) use a relativity API.

Uptime

100.0%

Latency

80ms

Subs

4,656

Tidal-physics and gravitational-dominance astrophysics as an API, computed locally and deterministically. The tidal-force endpoint computes the tidal (differential) acceleration that stretches a body, a = 2·G·M·r/d³, from the primary mass, the radius (half-size) of the affected body and the centre-to-centre distance — and the force if a body mass is given; tidal effects fall off as the inverse cube of distance, far faster than gravity's inverse square, which is why they matter only close in. The roche-limit endpoint computes the Roche limit, the distance inside which tidal forces tear a satellite apart, for both rigid bodies, d = R·(2·ρM/ρm)^(1/3), and fluid bodies, d = 2.44·R·(ρM/ρm)^(1/3), from the primary radius and the two densities — Saturn's rings sit inside its Roche limit. The hill-sphere endpoint computes the Hill-sphere radius, r_H ≈ a·(1−e)·(m/3M)^(1/3), the region where a body's own gravity dominates so it can keep moons, from the orbital distance, eccentricity and the two masses. Masses are in kilograms, distances and radii in metres and densities in kg/m³, with G = 6.674×10⁻¹¹. Everything is computed locally and deterministically, so it is instant and private. Ideal for astronomy, astrophysics, planetary-science, simulation and education app developers, ring-system and moon-stability tools, and physics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is tidal and gravitational-dominance physics; for Newtonian gravity use a gravitation API and for orbital periods an orbital-mechanics API.

Uptime

100.0%

Latency

81ms

Subs

4,022

Chebyshev Type I filter-design maths as an API, computed locally and deterministically. The order endpoint computes the minimum filter order to meet a specification, n = ⌈acosh(√((10^(As/10)−1)/(10^(Ap/10)−1))) / acosh(fs/fp)⌉, from the passband edge frequency and its ripple and the stopband edge and its required attenuation — a Chebyshev filter usually needs a lower order than a Butterworth for the same specification, trading a flat passband for equiripple. The response endpoint computes the equiripple magnitude response, |H| = 1/√(1 + ε²·Tₙ²(f/fc)) with the ripple factor ε = √(10^(Ap/10) − 1) and the Chebyshev polynomial Tₙ, in linear and decibel form — in the passband the magnitude ripples between 0 and −Ap dB and reaches exactly −Ap dB at the cutoff, then rolls off faster than a Butterworth. The ripple endpoint converts between the passband ripple in decibels and the ripple factor ε, with the passband maximum and minimum. Frequencies are in hertz, ripple and attenuation in decibels and the order a positive integer. Everything is computed locally and deterministically, so it is instant and private. Ideal for DSP, audio, RF, communications and instrumentation app developers, filter-design and selectivity tools, and signal-processing education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is the Chebyshev Type I filter; for the maximally-flat Butterworth use a Butterworth API.

Uptime

100.0%

Latency

76ms

Subs

3,326

Butterworth-filter design maths as an API, computed locally and deterministically. The order endpoint computes the minimum filter order needed to meet a specification — from the passband edge frequency and its allowed ripple and the stopband edge frequency and its required attenuation it returns the exact and rounded-up order, n = ⌈log10((10^(As/10)−1)/(10^(Ap/10)−1)) / (2·log10(fs/fp))⌉, where each extra order adds 20 dB per decade of roll-off. The response endpoint computes the maximally-flat magnitude response of an n-th order Butterworth filter at a frequency, |H| = 1/√(1 + (f/fc)^(2n)), in linear and decibel form with the attenuation and the asymptotic roll-off — the response is exactly −3.01 dB at the cutoff for any order. The poles endpoint gives the s-plane pole locations, equally spaced on a circle of radius ωc in the left half-plane at angles π·(2k+n−1)/(2n), all stable. Frequencies are in hertz (or any consistent unit), ripple and attenuation in decibels and the order a positive integer. Everything is computed locally and deterministically, so it is instant and private. Ideal for DSP, audio, RF, instrumentation and embedded app developers, anti-aliasing and filter-design tools, and signal-processing education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is the Butterworth filter; for a single-pole RC cutoff and resonance use a resonance API and for AC impedance an impedance API.

Uptime

100.0%

Latency

74ms

Subs

3,767

Zener-diode voltage-regulator electronics maths as an API, computed locally and deterministically. The series-resistor endpoint sizes the series (dropping) resistor for a shunt Zener regulator, Rs = (Vin − Vz)/(Iz + Il), from the input voltage, the Zener voltage, the load current and the desired Zener (knee) current, and gives the power the resistor and the Zener must dissipate — the core design step so the diode stays in regulation at maximum load. The regulator endpoint analyses an existing regulator: from the input voltage, the Zener voltage, the series resistor and the load (as a current or a resistance) it computes the total current, the Zener current Iz = (Vin − Vz)/Rs − Il, the load current, the output voltage and whether the regulator is still regulating (Iz > 0) or has dropped out under heavy load. The power endpoint computes the Zener power dissipation P = Vz·Iz and the maximum safe current Iz_max = Pz_max/Vz from the diode's power rating. Voltages are in volts, currents in amperes, resistances in ohms and power in watts. Everything is computed locally and deterministically, so it is instant and private. Ideal for electronics, power-supply, hobbyist and embedded app developers, regulator-design and reference-voltage tools, and electronics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is the Zener shunt regulator; for BJT biasing use a transistor API and for an LED series resistor an LED-resistor API.

Uptime

100.0%

Latency

77ms

Subs

4,754

Bipolar-junction-transistor (BJT) circuit maths as an API, computed locally and deterministically. The currents endpoint relates the three terminal currents through the DC current gain β (hFE): the collector current Ic = β·Ib, the emitter current Ie = (β+1)·Ib and the common-base gain α = β/(β+1) ≈ 1, from β and any one current. The bias endpoint analyses the operating point of the classic voltage-divider bias network — from the supply voltage, the two divider resistors, the collector and emitter resistors, β and the base-emitter drop it computes the Thévenin equivalent (Vth = Vcc·R2/(R1+R2), Rth = R1‖R2), the base current Ib = (Vth − Vbe)/(Rth + (β+1)·Re), the collector and emitter currents, the collector-emitter voltage Vce and the node voltages, and classifies the operating region as cutoff, active or saturation. The power endpoint computes the transistor's power dissipation, Pd ≈ Vce·Ic (plus Vbe·Ib), to check it against the rated maximum. Currents are in amperes, resistances in ohms and voltages in volts, with Vbe defaulting to 0.7 V for silicon. Everything is computed locally and deterministically, so it is instant and private. Ideal for electronics, amplifier-design, embedded and hobbyist app developers, biasing and operating-point tools, and electronics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is BJT biasing; for op-amp circuits use an op-amp API and for an LED series resistor an LED-resistor API.

Uptime

100.0%

Latency

78ms

Subs

4,994

Angular-size astronomy and optics maths as an API, computed locally and deterministically. The angular-size endpoint computes the angular diameter an object subtends, δ = 2·arctan(d/(2D)), from its physical size and its distance, returning the angle in radians, degrees, arcminutes and arcseconds, along with the small-angle approximation δ ≈ d/D — the Sun and Moon are each about half a degree (31 arcminutes) across. The distance endpoint inverts the relation, D = d/(2·tan(δ/2)), to give an object's distance from its known true size and its measured angular size, the basis of the standard-ruler distance method. The object-size endpoint computes an object's physical diameter, d = 2·D·tan(δ/2), from its distance and angular size. Size and distance use any one consistent unit, and angles may be given in radians, degrees, arcminutes or arcseconds. Everything is computed locally and deterministically, so it is instant and private. Ideal for astronomy, telescope, astrophotography, surveying and optics app developers, field-of-view and rangefinding tools, and physics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is angular size; for stellar magnitude and parallax distance use a star-magnitude API and for sidereal time a sidereal API.

Uptime

100.0%

Latency

80ms

Subs

4,090

Faraday-law electrolysis maths as an API, computed locally and deterministically. The mass endpoint applies Faraday's first law of electrolysis, m = (Q·M)/(n·F) = (I·t·M)/(n·F), to give the mass of a substance deposited at a cathode or dissolved at an anode from the charge passed — or the current and time — the molar mass and the valence (electrons transferred per ion), with the Faraday constant 96485 C/mol. The charge endpoint inverts it to give the charge Q = (m·n·F)/M and, with a current, the plating time needed to deposit a target mass — the core sizing calculation for electroplating and anodising. The gas-volume endpoint computes the volume of gas evolved during electrolysis, moles = Q/(n·F) and volume = moles × 22.414 L/mol at STP, using the electrons per gas molecule (two for hydrogen, four for oxygen in water electrolysis). Molar mass is in g/mol, current in amperes, time in seconds, charge in coulombs and mass in grams. Everything is computed locally and deterministically, so it is instant and private. Ideal for electroplating, anodising, battery, hydrogen-production and chemistry-education app developers, plating-time and gas-yield tools, and electrochemistry teaching. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is electrolysis (Faraday's laws); for cell potential and the Nernst equation use an electrochemistry Nernst API.

Uptime

100.0%

Latency

78ms

Subs

3,971

Gematria and isopsephy as an API, computed locally and deterministically — turning words into the numeric sums of their letters. The hebrew endpoint computes Hebrew gematria: the standard value (Mispar Hechrachi) that adds the base value of each letter (alef 1, bet 2 … tav 400), the gadol value that counts the five final letters as 500–900, and the reduced digital root; for example שלום (shalom) is 376. The greek endpoint computes Greek isopsephy with the Milesian numeral system (alpha 1 … omega 800, plus the archaic stigma 6, koppa 90 and sampi 900), case-insensitively; for example λογος (logos) is 373. The english endpoint computes English gematria three ways — the ordinal or simple value (a 1 … z 26), the Pythagorean value that reduces each letter to a single digit 1–9, and the Sumerian value (ordinal × 6) — with the digital root; for example HELLO is 52 ordinal. Non-letter characters are ignored and unrecognised letters are listed. Everything is computed locally and deterministically, so it is instant and private. Ideal for word-game, puzzle, esoteric, study and language app developers, name-numerology and text-analysis tools, and Bible and classics study. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is letter-value gematria; for Roman numerals use a Roman-numeral API and for general number bases a base-conversion API.

Uptime

100.0%

Latency

77ms

Subs

4,418

Roller-chain power-transmission maths as an API, computed locally and deterministically. The ratio endpoint computes a chain drive's speed ratio (driven ÷ driver teeth), the output rpm and torque multiplier, the chain (line) velocity v = N·p·rpm/60 and the pitch diameter of each sprocket, PD = p/sin(π/N), from the driver and driven tooth counts, the input speed and the chain pitch. The length endpoint computes the chain length in pitches and then rounds it up to an even number of links — links must come in pairs — using L = 2C/p + (N1+N2)/2 + ((N2−N1)/2π)²·p/C from the tooth counts, the centre distance and the pitch. The center-distance endpoint inverts that relation to give the exact centre distance for a chosen even link count, C = (p/8)·[(2L−N1−N2) + √((2L−N1−N2)² − 8·((N2−N1)/2π)²)]. Tooth counts are integers, pitch and centre distance in metres (the default pitch 0.0127 m is ANSI 40, ½ inch) and speeds in rpm. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical, machine-design, conveyor, motorcycle and industrial-equipment app developers, sprocket-sizing and chain-selection tools, and engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is industrial roller-chain drives; for bicycle gearing use a bike-gear API and for belt or gear ratios a gear-ratio API.

Uptime

100.0%

Latency

84ms

Subs

3,801

Stormwater-runoff civil-engineering maths as an API, computed locally and deterministically. The rational endpoint computes the peak runoff from a catchment with the Rational Method, Q = C·i·A — in metric form Q(m³/s) = C·i·A/360 with rainfall intensity i in mm/h and area A in hectares, or in US form Q(cfs) = C·i·A with intensity in in/h and area in acres — where the runoff coefficient C is the fraction of rain that runs off (about 0.9 for paving and 0.2 for lawns). The time-of-concentration endpoint computes how long water takes to flow from the most remote point of the catchment to the outlet with the Kirpich formula, tc = 0.0195·L^0.77·S^(−0.385) minutes, from the flow-path length and slope; this sets the design-storm duration. The detention endpoint gives a first-order estimate of the detention-pond storage needed to throttle a peak inflow down to an allowable outflow over a storm duration, (Q_in − Q_out)·duration. Coefficients are dimensionless, intensities in mm/h or in/h, areas in ha or acres, lengths in m and flows in m³/s. Everything is computed locally and deterministically, so it is instant and private. Ideal for civil-engineering, drainage, urban-planning, landscape and flood-risk app developers, sewer-sizing and detention tools, and hydrology education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is stormwater runoff; for open-channel flow use a Manning API and for pipe friction a Darcy API.

Uptime

100.0%

Latency

79ms

Subs

4,516

Sidereal-time astronomy as an API, computed locally and deterministically. The gmst endpoint computes the Greenwich Mean Sidereal Time for a UT date and time, GMST = 18.697374558 + 24.06570982441908·(JD − 2451545.0) hours modulo 24, returning it in hours, degrees and hours-minutes-seconds together with the Julian Day — sidereal time tracks the stars rather than the sun and gains about three minutes and fifty-six seconds each day. The lst endpoint adds the observer's longitude to give the Local Sidereal Time, LST = GMST + longitude/15 (east positive), which equals the right ascension of any star currently crossing the local meridian. The hour-angle endpoint computes the hour angle of a celestial object, HA = LST − RA, from its right ascension and the local sidereal time (or a date, time and longitude): an hour angle of zero means the object is on the meridian at its highest point, a positive hour angle means it is west of the meridian and setting, and a negative one means it is east and rising. Dates are YYYY-MM-DD and times HH:MM:SS in UT, longitude in degrees and right ascension in hours. Everything is computed locally and deterministically, so it is instant and private. Ideal for astronomy, telescope-control, planetarium, observatory and astrophotography app developers, star-pointing and transit tools, and astronomy education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is sidereal time; for the sun's position use a solar-position API and for sunrise and sunset times a sunrise API.

Uptime

100.0%

Latency

80ms

Subs

3,133

Vehicle-braking physics as an API, computed locally and deterministically. The stopping-distance endpoint computes the total distance to stop a vehicle as the sum of the reaction distance the vehicle travels during the driver's reaction time, v·t, and the braking distance v²/(2·μ·g) — which grows with the square of speed, so doubling the speed quadruples the braking distance — from the speed, the tyre-road friction coefficient, the reaction time and the road grade, along with the deceleration and the time to stop. The braking-force endpoint computes the braking force F = m·a and the deceleration of a vehicle, either from a stop-in-a-given-distance (a = v²/2d) or from the friction coefficient (a = μ·g), with the kinetic energy that must be dissipated as heat. The skid-speed endpoint reconstructs the speed at the start of a skid from the skid-mark length, v = √(2·μ·g·d), a lower-bound estimate used in accident reconstruction. Speed is in km/h by default (also m/s or mph), mass in kg and distances in m; dry asphalt has μ ≈ 0.7, wet ≈ 0.4 and ice ≈ 0.1. Everything is computed locally and deterministically, so it is instant and private. Ideal for automotive, driving-safety, fleet, telematics and accident-reconstruction app developers, stopping-distance and forensic tools, and physics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is vehicle braking; for general kinematics use a kinematics API and for an object on a slope an inclined-plane API.

Uptime

100.0%

Latency

73ms

Subs

3,774

Thin-walled pressure-vessel engineering maths as an API, computed locally and deterministically. The thin-wall endpoint computes the wall stresses in a cylindrical or spherical vessel under internal pressure: for a cylinder the hoop (circumferential) stress σ_h = p·r/t and the longitudinal stress σ_l = p·r/(2t), which is half the hoop — so cylinders tend to split along their length — together with the von Mises equivalent stress, and for a sphere the single biaxial stress σ = p·r/(2t); it also reports the radius-to-thickness ratio and whether the thin-wall assumption (r/t ≳ 10) holds. The thickness endpoint computes the wall thickness required to keep the hoop stress within an allowable value, t = p·r/(σ_allow·E), with a weld-joint efficiency factor. The burst endpoint computes the theoretical burst pressure of a pipe from Barlow's formula, p = 2·S·t/OD, using the ultimate tensile strength. Pressures and stresses are in pascals (megapascals also returned) and dimensions in metres. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical, chemical-plant, piping, boiler and tank-design app developers, ASME-style sizing and safety tools, and engineering education; for code work consult the applicable standards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is thin-walled vessel stress; for general stress transformation use a Mohr-circle API and for fatigue a fatigue API.

Uptime

100.0%

Latency

79ms

Subs

3,466

MAC-address (EUI-48) tooling as an API, computed locally and deterministically. The parse endpoint validates a MAC address given in any common notation — colon, hyphen, Cisco dotted or a bare run of 12 hex digits — and returns it in every standard format, split into its OUI (the first three bytes, assigned to a hardware vendor) and its NIC (the last three, device-specific) parts, plus the 48-bit integer value. The analyze endpoint reads the control bits of the first octet: the least-significant bit is the I/G bit that marks a unicast or multicast address, and the next bit is the U/L bit that marks a universally (vendor-assigned) or locally administered address, and it flags the broadcast address ff:ff:ff:ff:ff:ff. The eui64 endpoint derives the modified EUI-64 interface identifier — flipping the U/L bit and inserting FF:FE in the middle — and the resulting IPv6 link-local address (fe80::/64) used by stateless address autoconfiguration. Vendor name lookup needs the IEEE OUI registry and is not included. Everything is computed locally and deterministically, so it is instant and private. Ideal for networking, IoT, device-management, monitoring and security app developers, MAC-normalisation and IPv6 tools, and networking education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is MAC-address tooling; for IPv4 subnetting use a subnet API and for DNS records a DNS API.

Uptime

100.0%

Latency

80ms

Subs

4,116

PID-controller-tuning maths as an API, computed locally and deterministically. The ziegler-nichols endpoint computes controller gains with the closed-loop (ultimate-gain) method: from the ultimate gain Ku at which the loop sustains oscillation and its period Tu it returns the proportional, integral and derivative gains for a P, PI, PD or PID controller using the classic table (PID: Kp = 0.6·Ku, Ti = 0.5·Tu, Td = 0.125·Tu), in both the standard (Ti, Td) and parallel (Ki, Kd) parameters. The reaction-curve endpoint computes gains with the open-loop method from a step-response process model — the process gain K, the dead time L and the time constant T — using the Ziegler-Nichols reaction-curve table (PID: Kp = 1.2·T/(K·L), Ti = 2L, Td = 0.5L). The convert endpoint translates between the parallel form (Kp, Ki, Kd) and the standard form (Kp, Ti, Td) using Ki = Kp/Ti and Kd = Kp·Td. Everything is computed locally and deterministically, so it is instant and private. Ideal for industrial-automation, robotics, process-control, motor-control and IoT app developers, controller-tuning and loop-design tools, and control-systems education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is PID controller tuning; for op-amp circuits use an op-amp API and for resonance and reactance a resonance API.

Uptime

100.0%

Latency

76ms

Subs

4,305