Vista previa del mercado

Mercado API

Descubra e integre APIs a través de la puerta de enlace segura y secreta de oanor.

313–336 de 1117 API

API de Tejido

Matemáticas de tejido y telar como una API, calculadas local y determinísticamente: los números de urdimbre, trama y densidad que un tejedor manual utiliza para urdir un telar. El endpoint de urdimbre calcula el total de hilos y el hilo de urdimbre para un proyecto: hilos = ancho de urdimbre × EPI (hilos por pulgada, la densidad), y la longitud de urdimbre por hilo = la longitud de la tela ajustada por contracción (~10 %) más el desperdicio de telar (~24 pulgadas de flecos), así que una pieza de 20 pulgadas de ancho a 12 EPI tejida a 60 pulgadas necesita 240 hilos y 600 yardas de urdimbre. El endpoint de trama calcula el hilo de trama a partir de las pasadas por pulgada, el ancho y la longitud tejida: pasadas = PPI × longitud tejida, cada una cruzando el ancho más la contracción. El endpoint de densidad convierte las vueltas por pulgada de un hilo en los hilos por pulgada para urdir: un ligamento tafetán equilibrado es la mitad de las WPI, el sarga dos tercios, el satén tres cuartos — así que un hilo que da 24 vueltas por pulgada se urde a 12 EPI para tafetán. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de tejido, fibras textiles, artesanía textil, calculadoras de urdimbre y herramientas de planificación de proyectos, y educación en tejido. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. Pulgadas imperiales de entrada; yardas de salida. En vivo, nada se almacena. 3 endpoints de cómputo. La contracción, el encogimiento y el desperdicio de telar tienen valores predeterminados sensatos — mide tu propio telar.

#weaving #loom #warp
P por PremiumApi
Disponibilidad
100.0%
Latencia
75ms
Suscriptores
4,475
Verificado por servidor 12 sondas/24h

api.oanor.com/weaving-api

API de Punto de Cruz

Matemáticas de punto de cruz e hilo contado como una API, calculadas local y determinísticamente: los números de tamaño de diseño y de hilo que un bordador planifica para un patrón. El endpoint de diseño convierte un recuento de puntadas en un tamaño terminado sobre una tela de cuenta determinada: tamaño del diseño = recuento de puntadas ÷ cuenta de la tela (puntadas por pulgada), así que un gráfico de 140×98 puntadas sobre Aida de cuenta 14 se borda en 10×7 pulgadas (25.4×17.8 cm); añade la tela a cortar con un margen (≈3 pulgadas por lado para el bastidor y el acabado), reporta el total de puntadas y convierte el mismo gráfico a otra cuenta — ese diseño de 140×98 se reduce a 7.8×5.4 pulgadas sobre cuenta 18. El endpoint de hilo estima las madejas de hilo: madejas ≈ ceil(puntadas ÷ puntadas-por-madeja), donde aproximadamente 1,200 puntadas de cruz completas por madeja es típico para dos hebras sobre cuenta 14, y se asegura de que compres al menos una madeja por color. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de punto de cruz, bordado, costura y patrones de manualidades, herramientas de patrones y kits y telas, y educación en bordado. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. La cuenta de la tela es puntadas por pulgada; tamaños en pulgadas y centímetros. En vivo, nada se almacena. 2 endpoints de compute. Las cifras de hilo/madejas son estimaciones — compra un poco extra.

#cross-stitch #embroidery #needlework
P por PremiumApi
Disponibilidad
100.0%
Latencia
78ms
Suscriptores
3,192
Verificado por servidor 9 sondas/24h

api.oanor.com/crossstitch-api

API de Enmarcado de Cuadros

Matemáticas de enmarcado de cuadros como una API, calculadas local y determinísticamente: los números de corte de paspartú y moldura que un enmarcador o artista mide para un trabajo. El endpoint de paspartú dimensiona la tabla de paspartú alrededor de una obra de arte: la abertura de la ventana es el arte menos una pequeña superposición en cada borde (≈ 0.25 pulgadas para que el paspartú sostenga la impresión), y el paspartú exterior es la ventana más los anchos del borde — proporcione un borde o bordes por lado, con un fondo más pesado para un paspartú equilibrado con peso en la parte inferior, así que una impresión de 8×10 con un borde de 2 pulgadas tiene una ventana de 7.5×9.5 y un paspartú de 11.5×13.5. El endpoint de moldura calcula la tira de marco necesaria: longitud = perímetro interior + 8 × el ancho de la moldura, porque cada una de las cuatro esquinas ingleteadas a 45 grados agrega un ancho de moldura — un marco de 11.5×13.5 con moldura de 1.5 pulgadas necesita 62.5 pulgadas, más cualquier margen de desperdicio. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de enmarcado de cuadros, enmarcado personalizado, galerías de arte y bricolaje, herramientas de estimación de corte de paspartú y moldura, y educación en enmarcado. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. Pulgadas imperiales de entrada; longitudes en pulgadas y pies. En vivo, nada almacenado. 2 endpoints de cómputo. Una ayuda de planificación — mide dos veces, corta una vez.

#framing #mat-board #moulding
P por PremiumApi
Disponibilidad
100.0%
Latencia
82ms
Suscriptores
4,231
Verificado por servidor 9 sondas/24h

api.oanor.com/framing-api

API de Costura y Telas

Matemáticas de costura y estimación de telas como una API, calculadas local y determinísticamente: las cantidades de yardas con las que un costurero, acolchador o cortinero trabaja un proyecto. El endpoint de yardas coloca piezas cortadas en un rollo: piezas por fila = piso(ancho de tela ÷ ancho de pieza), filas = techo(cantidad ÷ por fila), y la longitud de tela = filas × altura de pieza más un margen de desperdicio — seis piezas de 18×22 pulgadas de algodón para acolchar de 44 pulgadas necesitan aproximadamente 2 yardas. El endpoint de cortinas dimensiona la tapicería para fruncido: caídas = techo(ancho de ventana × fruncido ÷ ancho de tela), donde 2× es un fruncido estándar y 2.5–3× es lujoso, y cada caída es la longitud terminada más los dobladillos superior e inferior (redondeado al patrón de repetición) — una ventana de 60 pulgadas con fruncido 2.5× en tela de 54 pulgadas requiere tres caídas y aproximadamente 8.3 yardas. El endpoint de ribete dimensiona el ribete de acolchado: longitud = perímetro + superposición para esquinas y uniones, tiras = techo(longitud ÷ ancho de tela) cortadas al ancho de la tira. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de costura, acolchado, decoración del hogar, tapicería y manualidades, herramientas de calculadora de telas y planificación de proyectos, y educación en costura. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Pulgadas imperiales de entrada; yardas y metros de salida. En vivo, nada almacenado. 3 endpoints de cómputo. Agregue margen de repetición de patrón para estampados; una ayuda de planificación.

#sewing #fabric #quilting
P por PremiumApi
Disponibilidad
100.0%
Latencia
77ms
Suscriptores
3,991
Verificado por servidor 12 sondas/24h

api.oanor.com/sewing-api

API de encuadernación

Matemáticas de encuadernación y producción de impresión como una API, calculadas local y determinísticamente: los números de ancho de lomo e imposición que un diseñador de libros, impresor o autoeditor necesita para diseñar un título. El endpoint de lomo calcula el ancho del lomo a partir del número de páginas y el grosor del papel: lomo = número de páginas ÷ páginas por pulgada (la especificación del papel del impresor, típicamente ~400–500 para papel de libro), o pliegos × calibre de la hoja, más las tapas — así que un libro de 250 páginas en papel de 400 PPI tiene un lomo de 0.625 pulgadas (15.9 mm). El endpoint de imposición calcula el diseño de encuadernación: para grapado al lomo redondea el número de páginas al siguiente múltiplo de cuatro (una hoja doblada son cuatro páginas) e informa los espacios en blanco para rellenar y las hojas; para libros cosidos o encuadernados en rústica agrupa las páginas en pliegos de 8, 16 o 32 e informa el número de pliegos, el total de páginas requerido y las páginas en blanco. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para autoedición, impresión bajo demanda, diseño de libros, preprensa y desarrolladores de aplicaciones de impresión, herramientas de lomo y cubierta e imposición, y educación en diseño gráfico. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. El número de páginas cuenta ambos lados; PPI es la especificación del papel. En vivo, nada se almacena. 2 endpoints de cómputo. Para el peso del papel use una API de papel y para DPI/resolución una API de resolución.

#bookbinding #print #spine-width
P por PremiumApi
Disponibilidad
100.0%
Latencia
81ms
Suscriptores
3,687
Verificado por servidor 9 sondas/24h

api.oanor.com/bookbinding-api

API de Rotación de Agua

Matemáticas de rotación y circulación de agua como API, calculadas local y determinísticamente: los números de caudal que un técnico de piscinas o acuarista usa para dimensionar una bomba. El endpoint de rotación relaciona el volumen de un cuerpo de agua con su caudal: tiempo de rotación = volumen ÷ caudal, y rotaciones por día = 24 ÷ tiempo de rotación, así que una piscina de 50,000 litros circulada a 10,000 L/h se renueva en 5 horas, casi 5 veces al día (las piscinas suelen apuntar a una rotación de 8–12 horas, 2–4 al día); si se da un tiempo de rotación objetivo, devuelve el caudal para dimensionar la bomba. El endpoint de acuario considera la pérdida de carga real que resta caudal a una bomba: caudal efectivo = caudal nominal × (1 − pérdida de carga), así que una bomba de 1,500 L/h con un 40% de pérdida realmente mueve 900 L/h, aproximadamente 4.5 veces un tanque de 200 litros por hora; si se da un objetivo de rotaciones por hora (agua dulce 4–6×, plantado 5–10×, arrecife 10×+), devuelve la bomba nominal a comprar para que las pérdidas aún dejen suficiente caudal. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de servicio de piscinas, acuarios, hidroponía, fuentes y estanques, herramientas de dimensionamiento de bombas y circulación, y educación sobre equipos. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Usa unidades de volumen y caudal consistentes. En vivo, nada se almacena. 2 endpoints de cómputo. Para potencia de bomba y pérdida de carga usa una API de bombas; para química de piscinas, una API de química de piscinas.

#turnover #circulation #pool
P por PremiumApi
Disponibilidad
100.0%
Latencia
89ms
Suscriptores
3,899
Verificado por servidor 9 sondas/24h

api.oanor.com/turnover-api

API de Apicultura

Matemáticas de apicultura y colmenar como una API, calculadas local y determinísticamente: los números de ácaros, cría y reservas de invierno con los que un apicultor maneja una colmena. El endpoint de varroa convierte un conteo de lavado con alcohol o sacudida de azúcar en la tasa de infestación: ácaros por cada 100 abejas = conteo de ácaros ÷ abejas muestreadas × 100, donde una cuchara de media taza equivale a unas 300 abejas, y señala cuando la colonia supera el umbral de tratamiento (comúnmente 3 ácaros por cada 100 abejas, o 3 %). El endpoint de cría proyecta el calendario de desarrollo desde el día en que se pone un huevo: eclosiona alrededor del día 3, la celda se sella alrededor del día 8-10 y el adulto emerge el día 16 para una reina, 21 para una obrera y 24 para un zángano — así que un huevo de obrera puesto el día 1 emerge tres semanas después. El endpoint de reservas calcula la miel de invierno: cuántos kilogramos necesita la colonia según el clima (aproximadamente 12 kg suave a 35 kg severo), los marcos profundos completos equivalentes (~2.25 kg cada uno), y el déficit y los marcos a alimentar contra las reservas actuales. La aritmética de fechas es exacta. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de apicultura, gestión de colmenares, agricultura y hogar, herramientas de inspección de colmenas y monitoreo de ácaros, y educación apícola. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Fechas como AAAA-MM-DD; pesos métricos. En vivo, nada almacenado. 3 endpoints de cómputo. Una ayuda de planificación — las condiciones locales varían.

#beekeeping #apiary #varroa
P por PremiumApi
Disponibilidad
100.0%
Latencia
81ms
Suscriptores
4,732
Verificado por servidor 12 sondas/24h

api.oanor.com/apiary-api

API de Jarabe de Arce

Matemáticas para hacer jarabe de arce como una API, calculadas local y determinísticamente: el rendimiento de savia a jarabe y los números de finalización que un productor de jarabe planifica para una temporada. El endpoint de rendimiento toma el volumen de savia y su contenido de azúcar en °Brix y devuelve el jarabe que produce a partir del balance de azúcar (jarabe = savia × °Brix de savia / °Brix final, finalizando a 66.9 °Brix), el agua que debe evaporarse, la relación savia a jarabe y la clásica Regla de Jones de 86 (86 ÷ °Brix de savia) — la regla de campo que famosamente da aproximadamente 43 litros de savia al 2 % por litro de jarabe. El endpoint de finalización da la temperatura de finalización por ebullición: el jarabe está listo aproximadamente 4 °C (7.1 °F) por encima del punto de ebullición del agua, por lo que a nivel del mar es ~104 °C / 219 °F — calibre según su propio punto de ebullición del agua, que disminuye con la altitud, y finalice esa cantidad de grados más arriba; también devuelve la densidad final (~66.9 °Brix, SG ≈ 1.337). Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para productores de jarabe de arce, desarrolladores de aplicaciones para hogares, alimentos artesanales y granjas, herramientas de evaporación y planificación de rendimiento, y educación sobre la producción de jarabe. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Unidades de volumen consistentes; temperaturas en °C o °F. En vivo, nada se almacena. 2 endpoints de cómputo. Una ayuda de planificación — un hidrómetro o refractómetro confirma la finalización.

#maple #syrup #sugaring
P por PremiumApi
Disponibilidad
100.0%
Latencia
76ms
Suscriptores
4,388
Verificado por servidor 9 sondas/24h

api.oanor.com/maple-api

API de elaboración de queso

Matemáticas para la elaboración de queso como API, calculadas local y determinísticamente: los números de rendimiento y cuajo que un artesano o quesero casero planifica para una elaboración. El endpoint de rendimiento aplica la fórmula clásica de Van Slyke, rendimiento % de leche = [(0.93 × grasa) + (caseína − 0.1)] × 1.09 / (1 − humedad del queso), a partir de la grasa de la leche, la caseína (o proteína verdadera, ya que caseína ≈ 0.78 × proteína) y la humedad objetivo del queso — la leche entera con 3.5 % de grasa y 2.5 % de caseína para hacer un cheddar con 37 % de humedad produce aproximadamente el 9.78 % del peso de la leche, por lo que 100 litros dan aproximadamente 10 kg de queso y se necesitan aproximadamente 9.9 litros de leche por kilogramo. El endpoint de cuajo dosifica un volumen de leche para cuajar: cuajo líquido de fuerza simple a aproximadamente 0.2 ml por litro (también fuerzas doble y triple y tabletas), diluido aproximadamente 20 veces en agua fría no clorada antes de remover. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de elaboración de queso, productos lácteos, cremerías y alimentos artesanales, herramientas de planificación de hojas de producción y rendimiento, y educación en ciencia láctea. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Métrico: litros, gramos, porcentaje. En vivo, nada almacenado. 2 endpoints de cómputo. Las fuerzas del cuajo varían según el producto — confirme la IMCU de la etiqueta; una ayuda de planificación.

#cheese #cheesemaking #van-slyke
P por PremiumApi
Disponibilidad
100.0%
Latencia
85ms
Suscriptores
3,985
Verificado por servidor 9 sondas/24h

api.oanor.com/cheese-api

API de Gestación Animal

Matemáticas de fechas de gestación animal e incubación de huevos como una API, calculadas local y determinísticamente: el calendario de cría y eclosión con el que trabaja un granjero, criador o veterinario. El endpoint de gestación toma una especie y una fecha de cría y devuelve la fecha de parto esperada con el rango normal temprano-tardío: fecha de parto = fecha de cría + la gestación promedio de la especie, así que una vaca criada el 1 de enero (283 días) pare alrededor del 11 de octubre, un perro (63 días) pare nueve semanas después, una cabra 150 días, un caballo 340, un cerdo 114 — docenas de especies desde conejo hasta camello y elefante, con una opción de anulación para el promedio de su propio rebaño. Proporcione una fecha de parto objetivo y funciona hacia atrás para obtener la fecha de cría. El endpoint de incubación hace lo mismo para aves de corral y pájaros — pollo 21 días, pato 28, ganso 30, codorniz 18, avestruz 42 y más — devolviendo la fecha de eclosión, la fecha de bloqueo (dejar de girar y aumentar la humedad ~3 días antes de la eclosión) y las fechas de ovoscopía del día 7 y día 14. El cálculo de fechas es exacto, incluidos los años bisiestos. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de ganadería, cría, veterinaria, gestión de granjas y criaderos, herramientas de calculadora de gestación y calendario de cría, y educación agrícola. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. Fechas como AAAA-MM-DD. En vivo, nada almacenado. 2 endpoints de cómputo. Promedios, no una predicción veterinaria.

#gestation #breeding #livestock
P por PremiumApi
Disponibilidad
100.0%
Latencia
78ms
Suscriptores
4,515
Verificado por servidor 9 sondas/24h

api.oanor.com/gestation-api

API de Fabricación de Velas

Matemáticas para fabricación de velas como API, calculadas local y determinísticamente: los números de cera, fragancia y tiempo de combustión con los que un cerero escala un lote. El endpoint de receta dimensiona un vertido a partir del volumen de agua del recipiente: cera (g) por vela = volumen(ml) × % de llenado × densidad de la cera (soja ≈ 0.9, cera de abejas ≈ 0.96, parafina ≈ 0.9 g/ml), así que un frasco de 250 ml con un 80 % de llenado requiere 180 g de cera de soja; añade el aceite de fragancia al porcentaje de carga (comúnmente 6–10 %, nunca por encima del máximo de la cera) y multiplica todo por el número de velas para obtener la cera total, la fragancia total y el peso del lote. El endpoint de combustión estima cuánto dura una vela: tiempo de combustión ≈ gramos de cera ÷ tasa de combustión, donde una vela de recipiente típica consume aproximadamente 7–9 g de cera por hora. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de fabricación de velas, fragancias para el hogar, artesanías hechas a mano y creadores, herramientas de calculadora de lotes y recetas, y educación en cerería. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. Métrico: mililitros, gramos, porcentaje. En vivo, nada se almacena. 2 endpoints de cómputo. Una ayuda de planificación — las pruebas de vertido y tu hoja de datos de cera siempre ganan.

#candle #candle-making #wax
P por PremiumApi
Disponibilidad
100.0%
Latencia
88ms
Suscriptores
3,785
Verificado por servidor 9 sondas/24h

api.oanor.com/candle-api

API de Tostado de Café

Matemáticas de tostado de café como API, calculadas local y determinísticamente: los números del perfil de tostado que un tostador casero o especializado rastrea lote a lote. El endpoint de pérdida calcula la relación de pérdida de peso a partir de dos de los siguientes: peso verde, peso tostado y porcentaje de pérdida: % de pérdida de peso = (verde − tostado) / verde × 100, así que 1 kg de verde que baja a 840 g es una pérdida del 16 %, un objetivo del 15 % deja 850 g, y para embolsar 800 g de tostado se cargan 952 g de verde (tostado ÷ (1 − % de pérdida)). Los tostados claros pierden aproximadamente 12–14 %, medios 15–17 %, oscuros 18–20 %. El endpoint de desarrollo calcula el tiempo de desarrollo y la Relación de Tiempo de Desarrollo (DTR) a partir del tiempo total de tostado y el tiempo del primer crack — DTR = (total − primer crack) / total × 100, con la mayoría de los tostadores apuntando aproximadamente al 20–25 %; los tiempos se aceptan en segundos o mm:ss. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de tostado de café, tostadurías, café de especialidad y registro de tostados, herramientas de perfiles y lotes, y educación sobre tostado. Cálculo puramente local — sin key, sin servicio de terceros, instantáneo. Pesos en gramos, tiempos en segundos o mm:ss. En vivo, nada se almacena. 2 endpoints de cómputo. Esto son matemáticas de perfil de tostado; para relaciones de preparación use una API de preparación de café.

#coffee #roasting #weight-loss
P por PremiumApi
Disponibilidad
100.0%
Latencia
77ms
Suscriptores
4,761
Verificado por servidor 9 sondas/24h

api.oanor.com/coffeeroast-api

API de Fabricación de Jabón

Matemáticas de fabricación de jabón y saponificación como una API, calculadas local y determinísticamente: los números de la calculadora de lejía que todo jabonero de proceso en frío y en caliente necesita, con el margen de seguridad incorporado. El endpoint de lejía toma una lista de aceites como pares aceite:gramos (oliva, coco, palma, karité, ricino, manteca de cerdo, sebo y un par de docenas más, cada uno con su valor SAP estándar) y devuelve el hidróxido de sodio (NaOH) o hidróxido de potasio (KOH) para saponificarlos: lejía = Σ(gramos de aceite × SAP) × (1 − supergrasa), así que 1 kg de aceite de coco con un 5 % de supergrasa necesita 169,1 g de NaOH (o 263,6 g de KOH con pureza del 90 % para jabón líquido). Calcula el agua según la relación lejía:agua, el porcentaje de aceites o la concentración de la solución de lejía, añade la fragancia (un pequeño porcentaje de los aceites) y totaliza el peso del lote. El endpoint de molde dimensiona un lote para un molde: aceites para llenarlo ≈ volumen(cm³) × 0,40, a partir de un volumen o largo × ancho × alto. Los valores SAP son gramos de NaOH por gramo de aceite. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de fabricación de jabón, cosméticos, artesanías hechas a mano y makers, herramientas de calculadora de lejía y recetas, y educación sobre jabonería. Cálculo local puro: sin key, sin servicio de terceros, instantáneo. Métrico: gramos, cm³, porcentaje. En vivo, nada se almacena. 2 endpoints de cómputo. La lejía es cáustica: use protección y verifique dos veces una receta nueva; esto es una ayuda de planificación.

#soap #saponification #lye
P por PremiumApi
Disponibilidad
100.0%
Latencia
77ms
Suscriptores
4,002
Verificado por servidor 9 sondas/24h

api.oanor.com/soap-api

API de elaboración de vino

Matemáticas de vinificación y enología como una API, calculadas local y determinísticamente: los números de corrección de mosto, sulfito y ácido que un vinicultor casero o de lotes pequeños ajusta. El endpoint de azúcar lee el mosto como Brix o gravedad específica, da el alcohol potencial (ABV potencial = (SG − 1) × 131.25) y calcula el azúcar de chaptalización para alcanzar un ABV objetivo — azúcar (g) = volumen(L) × Δ ABV-potencial × 16.83, ya que aproximadamente 17 g/L de azúcar fermentan para producir alrededor de 1 % de alcohol. El endpoint de so2 maneja la protección con sulfito: convierte entre SO2 libre y molecular al pH del vino (SO2 molecular = libre / (1 + 10^(pH − 1.81)), apuntando al protector 0.8 mg/L molecular), muestra cómo el SO2 libre necesario se desploma a medida que el pH baja, y dosifica el metabisulfito de potasio (57.6 % SO2) y las tabletas de campden (~0.44 g cada una) para alcanzar un SO2 libre objetivo en un volumen dado. El endpoint de ácido mueve la acidez titulable a un objetivo con ácido tartárico para aumentarla (gramos = ΔAT × volumen) o bicarbonato de potasio para reducirla. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de vinificación, sidrería, hidromiel, fermentación casera y bebidas artesanales, calculadoras de mosto y herramientas de bodega, y educación en enología. Cálculo local puro — sin key, sin servicio de terceros, instantáneo. Métrico: litros, gramos, g/L, mg/L. En vivo, nada se almacena. 3 endpoints de cómputo. Una ayuda de planificación — tus números de laboratorio y paladar siempre ganan. Para ABV de cerveza a partir de gravedad, usa una API de elaboración de cerveza casera.

#winemaking #oenology #chaptalization
P por PremiumApi
Disponibilidad
100.0%
Latencia
82ms
Suscriptores
3,495
Verificado por servidor 12 sondas/24h

api.oanor.com/winemaking-api

API de Curado de Carne

Matemáticas de curado de carne y charcutería como API, calculadas local y determinísticamente: las cifras de curado, sal y nitrito con las que trabaja un charcutero o carnicero casero, con la verificación de seguridad más importante. El endpoint de curado planifica un curado seco en equilibrio a partir del peso de la carne: gramos de curado = ppm objetivo × carne ÷ (0.0625 × 1,000,000), por lo que aproximadamente 2.5 g de Cure #1 por kilogramo alcanza los clásicos 156 ppm de nitrito (muy por debajo del límite de 200 ppm), más la sal y el azúcar como porcentaje configurable de la carne, la sal que el propio curado lleva, y — con Cure #2 — el nitrato añadido para salami de maduración larga. El endpoint de salmuera dimensiona una salmuera húmeda: sal = agua × % de salinidad, con los grados salómetros (una salmuera saturada al 26.45 % es 100°), y una dosis de curado opcional que devuelve las ppm de nitrito distribuidas entre la carne y la salmuera para una salmuera en equilibrio. Cure #1 es 6.25 % de nitrito de sodio; Cure #2 añade 4 % de nitrato. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de charcutería, carnicería, ahumado, elaboración de embutidos y artesanía alimentaria, herramientas de calculadora de curado y recetas, y formación culinaria. Cálculo puramente local — sin key, sin servicio de terceros, instantáneo. Métrico: gramos, mililitros, porcentaje. En vivo, nada se almacena. 2 endpoints de cómputo. ESTO ES UNA AYUDA DE CÁLCULO — siga siempre una receta de curado probada y aprobada; el nitrito es tóxico en exceso.

#curing #charcuterie #nitrite
P por PremiumApi
Disponibilidad
100.0%
Latencia
77ms
Suscriptores
3,547
Verificado por servidor 9 sondas/24h

api.oanor.com/curing-api

API de Hidroponía

Matemáticas de hidroponía y cultivo interior como una API, calculadas local y determinísticamente: los números de fuerza de nutrientes y luz de cultivo que un cultivador ajusta cada día. El endpoint ec convierte entre conductividad eléctrica (EC en mS/cm) y la lectura de PPM/TDS en la escala que use un medidor: la escala 500 (NaCl, EE. UU.) convierte EC 2.0 en 1000 ppm, la escala 700 (KCl) en 1400 ppm y la escala 640 (UE) en 1280 — la fuente de confusión interminable entre medidores. El endpoint dli calcula el Integral de Luz Diaria, DLI = PPFD × fotoperiodo × 3600 ÷ 1,000,000, los moles totales de luz que recibe un cultivo en un día (las verduras de hoja necesitan alrededor de 12–17, los cultivos frutales 20–30+), y lo invierte para obtener el PPFD que una luminaria debe entregar para alcanzar un DLI objetivo en una duración de día determinada. El endpoint reservoir equilibra un tanque a un EC objetivo: cuánta agua pura agregar para diluir una solución demasiado concentrada (W = V × (actual/objetivo − 1)), o cuánto concentrado agregar para aumentarlo. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de hidroponía, agricultura vertical, agricultura de ambiente controlado, cuartos de cultivo y jardines inteligentes, herramientas de dosificación e iluminación, y educación en horticultura. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. EC en mS/cm, volumen en litros, PPFD en µmol/m²/s. En vivo, nada almacenado. 3 endpoints de cálculo. Indique su escala de TDS; confirme con un medidor calibrado.

#hydroponics #indoor-grow #ec-ppm
P por PremiumApi
Disponibilidad
100.0%
Latencia
74ms
Suscriptores
4,829
Verificado por servidor 12 sondas/24h

api.oanor.com/hydroponics-api

API de Química de Piscinas

Matemáticas de química del agua de piscinas como una API, calculadas local y determinísticamente: los números de dosificación y balance del agua que un técnico de servicio de piscinas o propietario ejecuta en cada visita. El endpoint de cloro calcula cuánto producto agregar para elevar el cloro libre desde el nivel actual hasta un objetivo en ppm en un volumen dado: dosis (g) = Δppm × litros / 1000 ÷ la fracción de cloro disponible del producto, con concentraciones integradas para cloro líquido (12.5 %), lejía doméstica (6 %), cal-hipo (65 %), dicloro (56 %) y tricloro (90 %), o la suya propia: elevar 50,000 litros en 2 ppm necesita 800 g de cloro líquido o 154 g de cal-hipo. El endpoint lsi calcula el Índice de Saturación de Langelier, LSI = pH + factor de temperatura + factor de calcio + factor de alcalinidad − 12.1, la medida estándar de si el agua es corrosiva (por debajo de −0.3, ataca el yeso y el metal), equilibrada (−0.3 a +0.3) o incrustante (por encima de +0.3), con una corrección por ácido cianúrico a la alcalinidad de carbonato. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de servicio de piscinas, spa, tratamiento de agua y mantenimiento del hogar, herramientas de dosificación y balance de agua, y educación sobre cuidado de piscinas. Cálculo local puro: sin clave, sin servicio de terceros, instantáneo. Métrico: litros, ppm (mg/L), °C. En vivo, nada almacenado. 2 endpoints de cálculo. Siempre confirme con un kit de prueba: esto es una ayuda, no un sustituto. Para el volumen de agua de la piscina, use una API de geometría de piscinas.

#pool #water-chemistry #chlorine
P por PremiumApi
Disponibilidad
100.0%
Latencia
80ms
Suscriptores
4,962
Verificado por servidor 9 sondas/24h

api.oanor.com/poolchem-api

API de Llenado de Conductos

Matemáticas de llenado de conductos y cajas según NEC como una API, calculadas local y determinísticamente: los cálculos del código eléctrico que un electricista o estimador realiza en cada recorrido. El endpoint de llenado de conductos toma un conjunto de conductores (como pares tamaño:cantidad, ej. 12:3,10:2) y un tamaño comercial de conducto y devuelve el área transversal del conductor, el área interna del conducto, el porcentaje de llenado y si se mantiene dentro del límite del Capítulo 9 de NEC — 53 % para un solo conductor, 31 % para dos, 40 % para tres o más — así que nueve #12 THHN llenan un EMT de media pulgada al 39 % (legal) pero diez no. El endpoint de llenado de cajas aplica NEC 314.16(B): cada conductor añade su espacio libre permitido (2.00 in³ para #14, 2.25 para #12, etc.), un yoke de dispositivo cuenta como dos, las abrazaderas internas de cable como uno, y todos los conductores de puesta a tierra juntos como uno — todo al volumen del conductor más grande — para dar el tamaño mínimo de la caja de conexiones, verificado contra un volumen de caja si se proporciona uno. Utiliza las áreas THHN/THWN y EMT del Capítulo 9 de NEC. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de contratistas eléctricos, estimación, inspección y electricistas, herramientas de dimensionamiento de conductos y cajas, y capacitación de aprendices. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. Imperial: pulgadas cuadradas y pulgadas cúbicas. En vivo, nada almacenado. 2 endpoints de cálculo. Siempre verifique contra la edición adoptada del código — esto es una ayuda de estimación, no una inspección.

#conduit-fill #box-fill #nec
P por PremiumApi
Disponibilidad
100.0%
Latencia
68ms
Suscriptores
3,256
Verificado por servidor 9 sondas/24h

api.oanor.com/conduit-api

API de Dividendos y Valoración

Fundamentos de dividendos y valoración de acciones como API, calculados local y determinísticamente: los ratios por acción que los inversores de valor e ingresos examinan. El endpoint de dividendos toma un precio de acción y un dividendo anual (por acción, o dividendos totales ÷ acciones) y devuelve el rendimiento por dividendo, y con las ganancias por acción la tasa de pago (dividendo ÷ EPS), la cobertura de dividendos (EPS ÷ dividendo) y la tasa de retención — un dividendo de $2 en una acción de $50 rinde un 4%, y con EPS de $4 es un pago del 50% cubierto dos veces. El endpoint de valoración calcula la relación precio-beneficio, el rendimiento de ganancias, la relación PEG frente a una tasa de crecimiento, la relación precio-valor contable y el número de Graham √(22.5 · EPS · valor contable) — el techo aproximado de valor razonable de Benjamin Graham. El endpoint ddm ejecuta el modelo de descuento de dividendos de Gordon, valor razonable = D1 ÷ (r − g) a partir del dividendo del próximo año, el rendimiento requerido y la tasa de crecimiento perpetuo, y frente a un precio de mercado indica si la acción parece infravalorada o sobrevalorada y el costo implícito del capital. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de inversión, corretaje, robo-advisor, filtro de dividendos y fintech, herramientas de valoración de acciones y carteras de ingresos, y educación financiera. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. En vivo, nada almacenado. 3 endpoints de cálculo. Estos son ratios de valoración a partir de sus entradas; para cotizaciones en vivo use una API de datos de mercado y para proyectos DCF/VAN una API de evaluación de inversiones.

#dividend #valuation #pe-ratio
P por PremiumApi
Disponibilidad
100.0%
Latencia
77ms
Suscriptores
4,714
Verificado por servidor 12 sondas/24h

api.oanor.com/dividend-api

API de Riesgo de Trading

Matemáticas de gestión de riesgos de trading como una API, calculadas local y determinísticamente: los números de dimensionamiento de posiciones y gestión de dinero que todo trader disciplinado calcula antes de una operación. El endpoint de tamaño de posición es independiente del instrumento: a partir de un saldo de cuenta, el porcentaje que está dispuesto a arriesgar, un punto de entrada y un stop-loss, devuelve el tamaño de la posición en unidades (acciones, contratos, lotes o monedas), el efectivo en riesgo y, con un objetivo, la recompensa potencial y la relación riesgo-recompensa — arriesgue el 1% de una cuenta de $10,000 en un stop de 50 pips y opere 0.2 lotes, perdiendo exactamente $100 si se activa el stop. El endpoint de valor de pip proporciona el valor de pip de forex para un lote o tamaño de unidad en la moneda cotizada, con una tasa de cotización a cuenta para pares que no son de cuenta — un lote estándar con un pip de 0.0001 equivale a 10 unidades de la moneda cotizada. El endpoint de Kelly calcula la fracción óptima de apuesta del criterio de Kelly f* = W − (1−W)/R a partir de una tasa de aciertos y la relación de pago ganancia/pérdida (o ganancia y pérdida promedio), más el medio-Kelly que muchos traders prefieren y la expectativa por unidad, indicando si la ventaja es positiva en absoluto. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de diarios de trading, brókeres, firmas de prop trading, backtesting y fintech, herramientas de dimensionamiento de posiciones y gestión de riesgos, y educación en trading. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. En vivo, nada almacenado. 3 endpoints de cálculo. Esto son matemáticas de riesgo y dimensionamiento de posiciones; para conversión de tipos de cambio use una API de divisas y para valoración de opciones una API de Black-Scholes.

#trading #position-sizing #forex
P por PremiumApi
Disponibilidad
100.0%
Latencia
79ms
Suscriptores
4,328
Verificado por servidor 12 sondas/24h

api.oanor.com/trading-api

API de Estimación de Albañilería

Matemáticas de estimación de albañilería como una API, calculadas local y determinísticamente: los recuentos de ladrillos, bloques y mortero que un albañil, constructor o estimador utiliza. El endpoint de ladrillos calcula cuántos ladrillos necesita una pared a partir de su área (o largo × alto en pies): ladrillos por pie cuadrado = 144 / ((largo del ladrillo + junta) × (alto del ladrillo + junta)), por lo que un ladrillo modular estándar con una junta de mortero de 3/8 de pulgada da como resultado los conocidos 6.86 ladrillos por pie cuadrado — una pared de 100 ft² son 686 ladrillos, más un margen de desperdicio y las bolsas de mortero (aproximadamente 7 por cada 1000 ladrillos). El endpoint de bloques hace lo mismo para unidades de mampostería de concreto: un CMU estándar de 16×8 pulgadas con una junta de 3/8 de pulgada equivale a 1.125 bloques por pie cuadrado, con aproximadamente 2.5 bolsas de mortero por cada 100 bloques. Ambos endpoints aceptan dimensiones personalizadas de la cara de la unidad y el grosor de la junta, agregan un porcentaje de desperdicio configurable y redondean a unidades enteras. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de construcción, contratistas de albañilería, suministros de construcción y mejoras para el hogar, herramientas de estimación de materiales y calculadoras comerciales. Cálculo puramente local — sin clave, sin servicio de terceros, instantáneo. Unidades imperiales (pulgadas y pies cuadrados). En vivo, nada almacenado. 2 endpoints de cálculo. Esto es estimación de ladrillos/bloques y mortero; para volumen de concreto vertido use una API de concreto y para paneles de yeso use una API de paneles de yeso.

#masonry #brick #block
P por PremiumApi
Disponibilidad
100.0%
Latencia
75ms
Suscriptores
3,732
Verificado por servidor 9 sondas/24h

api.oanor.com/masonry-api

API de carga y LTL

Matemáticas de carga y logística como una API, calculadas local y determinísticamente: la clase de carga LTL y los números de planificación de carga con los que trabajan un transportista, corredor o almacén. El endpoint de clase de carga calcula la densidad (peso ÷ pies cúbicos) de un envío y la asigna a la clase de carga basada en densidad NMFC, la escala de 18 bandas desde la clase 50 (más densa, más barata) hasta la 500 (más ligera), por lo que un palé de 200 lb que mide 48×40×48 pulgadas es 3.75 lb/ft³ y cae en la clase 250. El endpoint de palé paletiza una caja: toma la mejor de las dos orientaciones de huella para cajas por capa, llena la altura de apilamiento utilizable en capas y devuelve las cajas por palé limitadas por el menor del cubo y el límite de peso, con el peso de la carga y la altura de apilamiento (por defecto un palé GMA de 48×40). El endpoint de contenedor carga un contenedor high-cube de 40 pies (o cualquier dimensión que proporcione): cuántas unidades caben por apilamiento alineado a los ejes y por carga útil, cuál es el factor limitante, el peso total y la utilización del cubo. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de logística, corretaje de carga, 3PL, gestión de almacenes y cadena de suministro, herramientas de clasificación LTL y planificación de carga, y calculadoras de envío. Cálculo local puro: sin clave, sin servicio de terceros, instantáneo. Unidades imperiales (pulgadas, libras, pies cúbicos) ya que la escala NMFC es de EE. UU. En vivo, nada almacenado. 3 endpoints de cálculo. Esto son matemáticas de clase de carga y planificación de carga; para el peso de facturación de mensajería de paquetes individuales, use una API de peso dimensional.

#freight #ltl #nmfc
P por PremiumApi
Disponibilidad
100.0%
Latencia
76ms
Suscriptores
4,094
Verificado por servidor 12 sondas/24h

api.oanor.com/freight-api

API de Costo de Alimentos

Matemáticas de costeo de alimentos para restaurantes como API, calculadas local y determinísticamente: los números de ingeniería de menú y control de costos que maneja una cocina. El endpoint de receta totaliza un plato a partir de los costos de línea de sus ingredientes (o cantidades × precios unitarios), divide por el factor de rendimiento (1 − % de desperdicio) para que el recorte y la merma eleven el costo real, y lo divide entre las porciones para obtener un costo por plato — y contra un precio de menú devuelve el porcentaje de costo de alimentos y la ganancia bruta. El endpoint de plato fija el precio de un plato de dos maneras: proporcione un precio de menú y obtenga el porcentaje de costo de alimentos y el factor de margen, o proporcione un porcentaje de costo de alimentos objetivo y obtenga el precio de menú sugerido (un objetivo del 30 % es un margen de 3,33×), además de la ganancia bruta, el margen bruto y, con un costo de mano de obra, el porcentaje de costo primo. El endpoint de período convierte el movimiento de inventario en el costo de los bienes vendidos — COGS = inventario inicial + compras − inventario final — y el porcentaje de costo de alimentos o de servicio contra las ventas, el número principal en cada P&L (28–35 % para alimentos, 18–24 % para bebidas). Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de tecnología para restaurantes, POS, gestión de cocina, catering y hostelería, herramientas de ingeniería de menú y costeo de recetas, y formación en escuelas culinarias. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. En vivo, nada almacenado. 3 endpoints de cálculo. Esto son matemáticas de costo de alimentos y fijación de precios de menú; para conversión de unidades use una API de cocina y para matemáticas de margen genérico una API de precios.

#food-cost #restaurant #menu-pricing
P por PremiumApi
Disponibilidad
100.0%
Latencia
74ms
Suscriptores
4,982
Verificado por servidor 12 sondas/24h

api.oanor.com/foodcost-api

API de fabricación OEE

Efectividad General del Equipo (OEE) y matemáticas de manufactura esbelta como una API, calculadas local y determinísticamente — la métrica de productividad de piso de fábrica detrás de TPM y mejora continua. El endpoint oee toma el tiempo de producción planificado, el tiempo de inactividad, el total y la cantidad de piezas buenas y el tiempo de ciclo ideal (segundos por pieza, o una tasa ideal en piezas por minuto) y devuelve los tres factores y su producto: Disponibilidad = tiempo de ejecución / tiempo planificado, Rendimiento = tiempo ideal para las piezas fabricadas / tiempo de ejecución, Calidad = buenas / total, y OEE = Disponibilidad × Rendimiento × Calidad — el ejemplo clásico de un turno de 420 minutos con 47 minutos de inactividad, 19,271 piezas y 423 rechazos da exactamente 74.79 % (88.81 % × 86.11 % × 97.80 %). También desglosa la vista de las seis grandes pérdidas: pérdida de disponibilidad, pérdida de rendimiento (velocidad) en piezas, pérdida de calidad y el conteo de piezas totalmente productivas. El endpoint takt da el tiempo takt = tiempo disponible / demanda del cliente (el ritmo que la línea debe igualar), la tasa requerida, y — dado un tiempo de ciclo o un contenido total de trabajo — la capacidad de la línea, la utilización, si cumple con la demanda y el número mínimo de estaciones de trabajo con la eficiencia de balanceo de línea. Todo se calcula local y determinísticamente, por lo que es instantáneo y privado. Ideal para desarrolladores de aplicaciones de fabricación, fábrica inteligente, MES, paneles IoT y herramientas lean/TPM, monitoreo de líneas de producción y herramientas de mejora continua, y capacitación en ingeniería industrial. Cálculo local puro — sin clave, sin servicio de terceros, instantáneo. En vivo, nada almacenado. 2 endpoints de cómputo. Esto es matemáticas de OEE y takt; para confiabilidad de equipos/MTBF use una API de confiabilidad.

#oee #manufacturing #lean
P por PremiumApi
Disponibilidad
100.0%
Latencia
78ms
Suscriptores
4,575
Verificado por servidor 9 sondas/24h

api.oanor.com/oee-api