#crafts

Fuse-bead maths as an API, computed locally and deterministically — the bead-count, pegboard and colour numbers a Perler, Hama or melty-bead crafter plans a pixel design with. The grid endpoint turns a width × height pixel pattern into the real build: total beads = width × height, pegboards = ⌈width ÷ board⌉ × ⌈height ÷ board⌉ (a 29-peg square board for midi beads), and the finished size = beads × the bead pitch — so a 58 × 58 midi design is 3,364 beads, four pegboards and about 29 × 29 cm, in millimetres, centimetres and inches, with midi at 5 mm, mini at 2.6 mm and biggie at 9–10 mm. The palette endpoint splits the beads by colour: give it the total and a list of colour percentages and it returns the count per colour (normalised by the percent sum, so it works even when they don’t add to exactly 100) and the bags to buy at about a thousand beads each, or pass raw counts to bag them directly. Everything is computed locally and deterministically, so it is instant and private. Ideal for fuse-bead, pixel-art, kids-craft and maker app developers, pattern-to-shopping-list and project-estimator tools, and craft software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. For cross-stitch fabric counts use a different API.

api.oanor.com/fusebead-api

Paracord-craft maths as an API, computed locally and deterministically — the cord-length numbers a paracord crafter cuts a project to. The bracelet endpoint sizes the cord from the finished length and the weave using the well-known rule of thumb — about a foot of cord per inch of work for a cobra (Solomon) bar, double that for a king cobra, less for a fishtail — so an 8-inch cobra bracelet takes around 9 feet of cord including a foot of waste for the tails; give it a wrist measurement instead and it adds the fit ease and the buckle to get the finished length first, so a 7-inch wrist comes out near 10 feet. The weave endpoint generalises it to any project — lanyards, belts, dog leashes — as cord = finished length × cord-per-inch × the number of working strands, with the weave factors built in or your own cord-per-inch, and answers in inches, feet and metres. Everything is computed locally and deterministically, so it is instant and private. Ideal for paracord, survival-gear, scouting, craft and maker app developers, project-estimator and cut-list tools, and DIY software. Pure local computation — no key, no third-party service, instant. Rules of thumb — cut long and trim. Live, nothing stored. 2 compute endpoints.

api.oanor.com/paracord-api

Chainmaille maths as an API, computed locally and deterministically — the aspect-ratio and ring numbers a maille artist weaves to. The aspect endpoint computes the all-important Aspect Ratio = inner diameter ÷ wire diameter, and solves for whichever of the three you are missing, then lists the weaves that ring will make: AR, not absolute size, decides everything — too low and the rings won’t close through each other, too high and the weave goes floppy, so a 6.4 mm ID on 1.6 mm wire is AR 4.0, good for European 4-in-1, Byzantine, box chain and more. The ring endpoint does the material maths: wire per ring ≈ π × (inner diameter + wire diameter) — the mean-diameter circumference — so those AR-4 rings take about 25 mm of wire each and weigh roughly 0.4 g in steel; pass a wire length to get how many rings it yields, or a ring count to get the total wire and weight, in any of nine metals from aluminium to silver. Everything is computed locally and deterministically, so it is instant and private. Ideal for chainmaille, jewelry, cosplay-armour and maker app developers, ring-buying and project-estimator tools, and craft software. Pure local computation — no key, no third-party service, instant. Dimensions in mm. Live, nothing stored. 2 compute endpoints. For wire-gauge ↔ mm use a wire-gauge API.

api.oanor.com/chainmaille-api

Leathercraft maths as an API, computed locally and deterministically — the weight, area and strap numbers a leatherworker, saddler or maker cuts a project by. The thickness endpoint handles the quirk that leather “weight” is really a thickness: one ounce equals one sixty-fourth of an inch, or 0.397 mm, so 8 oz leather is 3.18 mm — and it converts in either direction between ounces, millimetres and inches and suggests typical uses, from 2–3 oz linings and wallets up to 9 oz-plus belts and saddlery. The area endpoint converts hide area between the US square foot, the European square decimetre (1 ft² = 9.29 dm²) and square metres, and sizes a project: given the leather a project needs and a waste allowance — 25–40 % is normal because hides have irregular edges and flaws — it returns the usable area and how many hides to buy. The strap endpoint counts straps cut from a rectangular piece (count = ⌊width ÷ strap width⌋, each as long as the piece) or the continuous lace length a spiral cut yields from an area (length = area ÷ width). Everything is computed locally and deterministically, so it is instant and private. Ideal for leatherwork, saddlery, crafting, bag-making and maker app developers, project-estimator and material-cost tools, and workshop software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints.

api.oanor.com/leather-api

Casting and epoxy-resin maths as an API, computed locally and deterministically — the mix, coverage and mould-volume numbers a resin artist, crafter or maker pours a project by. The mix endpoint splits a two-part resin by its label ratio: resin = total × A/(A+B), hardener = total × B/(A+B), from whichever quantity you know — the total, the resin or the hardener — so a 2:1 epoxy for 300 ml is 200 + 100, and a 100:45 by-weight system for 100 g of resin needs 45 g of hardener; it keeps your unit (ml, grams, fl oz) and reminds you that some resins mix by volume and others by weight. The coverage endpoint sizes a flood or seal coat: volume = area × thickness, in metric or US units, returned in millilitres, fluid ounces and gallons plus the mass — matching the familiar art-resin rule of about a gallon per 12 ft² at an eighth of an inch. The moldfill endpoint computes the volume of a box, cylinder, sphere or cone mould (a 10×10×5 cm box is 500 ml, 550 g at epoxy’s ~1.1 g/cm³) and subtracts the displacement of anything you embed, so you never over- or under-pour. Everything is computed locally and deterministically, so it is instant and private. Ideal for resin-art, craft, jewelry, model-making, river-table and maker app developers, project-estimator and material-cost tools, and studio software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For pot life and cure follow the product data sheet.

api.oanor.com/resin-api

Pottery and ceramics maths as an API, computed locally and deterministically — the shrinkage, glaze-batch and firing numbers a potter works out at the wheel and the kiln. The shrinkage endpoint handles the fact that clay shrinks from wet to bone-dry to fired: with a typical 12 % linear shrinkage a 100 mm rim fires down to 88 mm, and run in reverse it tells you to throw a piece larger to land on a target size — make it 100 mm wet to finish at 88 mm — and reports the volume shrinkage, which is the cube of the linear factor (about 32 %). The glaze endpoint scales a percentage recipe to a real batch: pass the ingredients as a name:percent list and a dry batch weight and it returns the grams of each, dividing by the recipe’s own percent sum so recipes that total over 100 % (a base 100 plus colorant and opacifier additions) still scale correctly, plus the water to add for dipping. The cone endpoint gives the approximate firing temperature for an Orton self-supporting cone at the standard 108 °F/hour ramp — cone 06 is about 1828 °F (998 °C) for bisque, cone 6 about 2232 °F (1222 °C) and cone 10 about 2345 °F (1285 °C) for stoneware — and reminds you that a cone measures heat-work, not just temperature. Everything is computed locally and deterministically, so it is instant and private. Ideal for ceramics, pottery-studio, maker and craft app developers, kiln-log and glaze-calculator tools, and studio-management software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For kiln-element power use a different API.

api.oanor.com/pottery-api

Knitting and crochet gauge maths as an API, computed locally and deterministically. The stitches endpoint turns a gauge — the standard stitches and rows per 10 cm measured from a tension swatch — into the number of stitches to cast on for a target width and the number of rows for a target length; at 22 stitches and 30 rows per 10 cm, a 50 cm wide by 60 cm long piece needs 110 stitches and 180 rows. The gauge endpoint works backwards from a measured swatch, converting a count over a measured distance into stitches (or rows) per 10 cm, per centimetre and per inch — 33 stitches over 15 cm is a gauge of 22 per 10 cm. The convert-pattern endpoint re-scales a pattern written for one gauge to your own gauge so the finished garment keeps its intended size: your count = pattern count · (your gauge / pattern gauge), so a 100-stitch cast-on at a 20-per-10 cm pattern becomes 110 at your 22-per-10 cm tension. Dimensions are in centimetres. Everything is computed locally and deterministically, so it is instant and private. Ideal for knitting, crochet, pattern-design, craft-marketplace and maker app developers, gauge and tension calculators, and yarn-shop tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is gauge and stitch maths; works for crochet too by using your stitch gauge.

api.oanor.com/knitting-api