#recipe

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.

api.oanor.com/jam-api

Ice-cream and gelato batch maths as an API, computed locally and deterministically — the overrun, yield and solids numbers a gelatiere, ice-cream maker or production planner balances a mix by. The overrun endpoint measures the air whipped into the mix during freezing by the weight method: from the same container filled first with mix and then with frozen ice cream, overrun = (mix weight − frozen weight) ÷ frozen weight × 100 — a cup that drops from 1000 g to 625 g ran 60 % overrun. Dense gelato sits around 20–35 %, premium ice cream 25–50 %, soft-serve and economy tubs 50–100 %+; more air means a lighter, cheaper, faster-melting product. The yield endpoint turns a mix volume and an overrun into the frozen volume (mix × (1 + overrun/100)) and the number of scoops at a given scoop size, so 2 litres of mix at 60 % overrun yields 3.2 litres and about 53 sixty-millilitre scoops — which is why overrun is a direct cost lever. The total-solids endpoint balances a recipe: total solids (sugar + fat + milk-solids-not-fat + other) as a percent of the mix weight, with the fat, sugar, MSNF and water percentages — a typical ice cream runs 36–42 % total solids, gelato lower in fat, and balancing solids against water is what keeps the texture smooth rather than icy. Everything is computed locally and deterministically, so it is instant and private. Ideal for gelateria and creamery tools, recipe-balancing apps, and food-production calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For general cooking measure conversions use a cooking API.

api.oanor.com/icecream-api

Textile-dyeing recipe maths as an API, computed locally and deterministically — the dye, water and auxiliary numbers a dyer weighs out to mix a repeatable dye-bath, whether for a swatch or a full bolt. The dye-weight endpoint gives the dye to weigh = the weight of fabric × the depth of shade, the percentage of dye on the weight of the goods: a 2 % shade on 100 g of fabric is 2 g of dye, pale shades run under half a percent, deep blacks 4 % or more — working on-weight-of-fabric is exactly what makes a recipe scale and repeat. The liquor-ratio endpoint gives the dye-bath volume = the weight of goods in kilos × the liquor ratio, the litres of bath per kilo (a 20:1 ratio is 20 L per kg); lower ratios save water, dye and energy and exhaust deeper, higher ratios level more evenly on delicate or pale work. The auxiliary endpoint gives the salt, soda ash or levelling agent to add = the bath volume × the dosing concentration in grams per litre — salt (50–80 g/L) drives reactive and direct dyes onto cotton, soda ash (10–20 g/L) raises the pH to fix them. Everything is on-weight or per-litre, so the same recipe gives the same colour and chemistry at any scale, and it is computed locally and deterministically, so it is instant and private. Ideal for craft and studio dyers, textile and yarn shops, and dye-recipe and batch-calculator tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For knitting yardage and gauge use a knitting API; for vegetable-ferment or meat-cure salt a fermentation or curing API.

api.oanor.com/dye-api

Baking-pan maths as an API, computed locally and deterministically — the area and scale-factor numbers a baker resizes a recipe between pans with. The trick everyone gets wrong is that a recipe scales by the pan’s AREA, not its diameter, so a 10-inch round holds far more batter than a 9-inch. The area endpoint gives the surface area of any pan — round and springform as π/4·d², square as s², rectangle as length × width, and bundt or tube pans as the ring (the outer circle minus the centre hole) — so a 9-inch round is 63.6 in², an 8-inch square 64 and a 9×13 is 117; add a depth and it returns the volume in cubic inches and cups. The convert endpoint gives the scale factor to move a recipe from one pan to another, factor = target area ÷ source area: a 9-inch round to a 9×13 is ×1.84, and two 8-inch rounds really do equal one 9×13. Pass an ingredient amount and it scales it for you, with a note to keep the batter depth similar and adjust the bake time. Everything is computed locally and deterministically, so it is instant and private. Ideal for baking, recipe, meal-prep and kitchen app developers, recipe-scaling and substitution tools, and culinary software. Pure local computation — no key, no third-party service, instant. Inches. Live, nothing stored. 2 compute endpoints. For ingredient unit conversion use a cooking API.

api.oanor.com/panscale-api

Pizza and bread dough maths as an API, built on baker's percentages — where the flour is always 100% and every other ingredient is expressed as a percentage of the flour weight. The dough endpoint computes a full recipe in grams (flour, water, salt, yeast, oil and sugar) from a target quantity — either a number of dough balls and a ball weight, a total dough weight, or a flour weight — together with a hydration and salt/yeast percentages, or a built-in style preset (Neapolitan, New York, Detroit, Sicilian, focaccia, ciabatta, baguette, sandwich). The hydration endpoint converts between flour, water and hydration percentage and classifies the dough from stiff to extremely wet. The presets endpoint returns the common dough styles as baker's percentages with typical ball weights. Everything is computed locally and deterministically, so it is instant and private. The yeast figure is instant dry yeast (use roughly three times as much fresh). Ideal for recipe and baking apps, pizzeria and bakery tools, meal-planning and kitchen-scale integrations, and food blogs. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is dough formulation by baker's percentage; for ingredient volume-to-weight and oven-temperature conversion use a cooking API.

api.oanor.com/dough-api

Recipe and kitchen conversions as an API. Convert between volume units (teaspoon, tablespoon, cup, fl-oz, ml, litre, pint, quart, gallon) and between mass units (gram, kilogram, ounce, pound) — and, crucially, between volume and mass for a specific ingredient using its density, so 1 cup of all-purpose flour ≈ 125 g, 1 cup of granulated sugar ≈ 200 g and 1 cup of water ≈ 237 g. 30 common ingredients are built in (flours, sugars, butter, oils, honey, rice, oats, cocoa, cornstarch and more), each with its grams-per-cup. Perfect for recipe apps, scaling and "metric vs cups" conversion, shopping lists and meal-prep tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. Distinct from general physical unit conversion, which has no ingredient densities.

api.oanor.com/cooking-api