Timber & Structural Wood Cutting API

Yes — there is an API for cutting structural timber to length. Cutting joists, rafters, studs, battens and boards to length is a 1D cutting-stock problem with an extra rule that plain linear cutting ignores: the cross-section has to match. A 50×150 part cannot come out of a 50×100 bar. The CutOptim Engine API solves it over HTTP at POST /v1/optimize/wood — your ERP, estimating or timber-yard software sends the cut list and the available stock as JSON and gets back the optimized cut plan, matched and solved per cross-section, with the bar count and the yield.

This is a distinct mode, not a wrapper over /v1/optimize/1d: linear 1D treats every bar as interchangeable, whereas timber has an identity — the section must match. Sending N grouped 1D requests instead costs N calls for one job, moves the stock matching to you, and yields a total that does not agree with what the app shows. This endpoint does the matching and returns the whole job in one call, per section and job-wide.

{
  "parts": [
    { "name": "Rafter", "sw": 50, "sh": 150, "length": 3200, "qty": 8 },
    { "name": "Noggin", "sw": 50, "sh": 100, "length": 600, "qty": 24,
      "meta": { "ref": "C24-50x100" } }
  ],
  "stock": [
    { "name": "C24 50x150", "sw": 50, "sh": 150, "length": 4800, "qty": 20, "price": 18.4 },
    { "name": "C24 50x100", "sw": 50, "sh": 100, "length": 4800, "qty": 30, "price": 12.5 }
  ],
  "options": { "kerf": 3 }
}

• Live today on POST /v1/optimize/wood — the same engine as the app, cross-section aware.
• Sections matched and solved independently: a 50×150 part is only cut from 50×150 stock.
• sections[] carries per-section rods, totals and cut plan; unmatched reports demand with no stock at all.
• Deterministic and version-pinned — reproduce a cutting quote for an audit or a repeat order.
• The reported off-cut is the usable remainder — the freeing kerf is already deducted (per bar).
• Free validation: POST /v1/validate/wood checks a job with no key and no quota.

Why carpenters and timber merchants need it

Structural timber is bought in long lengths and cut to many parts, and cutting in list order leaves a short offcut on almost every length. A cross-section-aware optimizer rearranges the cuts within each section so each one needs as few lengths as it can find. Inside an estimating, ERP or point-of-sale workflow the API does it on every job automatically — a builder’s merchant can price and plan a cutting service straight from the order, and the plan reconciles with what the yard actually cuts.

Cross-section matching — the part of the problem 1D drops

Each part and each stock row carries two cross-section sides, sw and sh, in either order (50×150 and 150×50 are the same bar turned over). The engine partitions the job by cross-section, matches each part only to stock of a compatible section, and solves every section independently. The response comes back as sections[], each with its own rods, its own totals and its own cut plan, plus job-wide metrics — and demand whose cross-section has no stock at all is reported separately in unmatched, distinct from parts that had stock and simply did not fit, because the fix differs.

Deterministic — reproducible for quotes and audits

The same request always returns the same cut plan: no randomness, no clock in the algorithm. A cutting quote built from an API call can be reproduced months later for an audit or a repeat order, and results can be cached and diffed in tests. The reported off-cut on each bar is the usable remainder — the freeing kerf is already deducted — and any meta object you attach (an article number, an order line) comes back on every placed cut so the plan reconciles with your system.

Woodworking use case (app) · Benchmarks