Sari la conținutul principal
PENTRU DEZVOLTATORI

CutOptim Engine API

Un motor determinist de optimizare a tăierii, apelabil prin HTTP: aceeași cerere returnează întotdeauna același plan de tăiere — așa că îl poți audita, poți oferta pe baza lui, poți rezolva o dispută cu el și poți rerula comanda de anul trecut pentru a obține planul de anul trecut. Este același motor care alimentează CutOptim, cu cele trei moduri dreptunghiulare (plăci 2D, 1D liniar și lemn cu potrivirea secțiunii), plus nesting true-shape pentru piese poligonale neregulate — POST /v1/optimize/nest, pentru lucrări cu laser, plasmă și jet de apă. Trimiți piesele și materialul de bază și primești înapoi layoutul complet, planul de tăiere și utilizarea — gata de integrat într-un ERP, într-o aplicație de ofertare sau în software-ul propriu al unei mașini.

Vezi benchmarkul complet → · Măsurat, nu pretins

Citește documentația API →

De ce să construiești pe el

DETERMINIST

Aceeași intrare returnează întotdeauna același rezultat — fără aleatoriu, fără ceas în algoritm. Poți pune rezultatele în cache și le poți compara în teste.

UN PLAN DE TĂIERE REAL

Nu doar dreptunghiuri: secvența de tăiere ghilotină, linii de tăiere față de treceri de ferăstrău, lungimea tăiată și un indicator care îți spune dacă poate fi produs pe un ferăstrău pentru panouri.

PENTRU FERĂSTRAIE DE PANOURI

Kerf, tolerance, tăiere de margine pe fiecare latură, mod cost, grupuri de fibră, număr maxim de etape de tăiere, minimizarea rotirii — aceleași opțiuni pe care le oferă și aplicația.

Ce face API-ul

Patru moduri de tăiere

Câte un apel pentru panouri 2D, material liniar 1D, lemn cu potrivire de secțiune și nesting true-shape al poligoanelor neregulate — POST /v1/optimize/2d, /1d, /wood și /nest.

Nesting true-shape

POST /v1/optimize/nest împachetează poligoane arbitrare (cu holes) pe plăci fixe, întrepătrunzând piesele în buzunarele concave ale celorlalte — 6 sheets acolo unde aceleași piese după bounding box au nevoie de 9. Pentru laser, plasmă și jet de apă. Zonele de excludere per placă (un defect, o clemă) vin la pachet.

Conștient de material

Etichetează piesele și stocul cu un material, iar optimizatorul împarte lucrarea: fiecare material este tăiat doar din propriul stoc. Pe fiecare mod; se întoarce un rezumat pe material.

Aplicare cant

Denumește un tip de cant per muchie (2D), iar răspunsul totalizează metrii liniari pe tip — pe piesă și pe comandă. Metadate: nu mută niciodată o piesă.

Export inline (SVG · DXF · CSV)

Cere include:["svg","csv","dxf"], iar răspunsul poartă layoutul ca fișier gata făcut, inline — un desen SVG 2D de sine stătător, un DXF R12/AC1009 sau o listă de tăiere CSV. Fără stocare, fără un al doilea apel.

Transmiterea metadatelor

Atașează un obiect meta — numărul de articol din ERP-ul tău, id-ul liniei de comandă, referința clientului — oricărei piese sau oricărui rând de material, iar el revine identic pe fiecare piesă plasată și pe fiecare placă/bară, astfel încât planul să se reconcilieze cu sistemul tău.

Validare gratuită

POST /v1/validate/{2d,1d,wood} validează schema aceluiași corp fără să-l rezolve — fără cheie, fără cotă. Verifică dacă un payload nu va fi respins și primește avertismente de fezabilitate înainte de a consuma un apel.

Cost sau deșeu

minimizeCost ordonează după factura totală cea mai mică între dimensiunile de stoc cu preț, amestecând formatele; implicit se minimizează materialul. Ambele rulează același algoritm guillotine.

Prioritate de stoc și stoc limitat

Marchează stocul care se consumă primul, tratează cantitățile ca plafon strict cu respectStock și marchează piesele obligatoriu de tăiat, care câștigă spațiul pe placă atunci când materialul este insuficient.

Un plan de tăiere real

Nu doar dreptunghiuri: secvența de tăiere guillotine cu pozițiile opritorului pe fiecare pas, linii de tăiere față de treceri de ferăstrău, lungimea tăiată și un indicator de fabricabilitate pe ferăstrău pentru panouri.

Parametri de ferăstrău pentru panouri

kerf, tăiere de margine pe fiecare latură, toleranță, grain groups, maxCutStages și minimizarea rotirii — aceleași opțiuni pe care le oferă aplicația.

Determinist & OpenAPI

Aceeași intrare returnează întotdeauna același rezultat — pune-l în cache și compară-l. O versiune de motor fixabilă și un document OpenAPI 3.1 descriu întregul contract.

Piese din fișiere CAD

Trimite un SVG sau un DXF în loc de coordonate: parts[].source citește conturul și găurile din desen, iar POST /v1/import/nest împarte întâi un fișier cu mai multe piese. Nimic nu se stochează — fișierul este prelucrat în memorie și dispare odată cu răspunsul.

Care motor deservește care mod

Endpointul către care faci POST alege modul; parametrul engine alege algoritmul. Motorul implicit heuristic deservește 2D, 1D și lemnul; balanced și motorul asincron max sunt doar 2D; iar nestingul true-shape rulează pe propriul motor lbf. Același motor ca în aplicație, prin HTTP.

Mod · endpointMotor · algoritmPanouri 2D/v1/optimize/2dLiniar 1D/v1/optimize/1dLemn · secțiune transversală/v1/optimize/woodNesting true-shape/v1/optimize/nestheuristicimplicit · sincronbalancedopțional · doar 2Dmaxasincron · doar 2Dlbfnesting · sparrow planificatPe 1D și lemn, balanced este pur și simplu un alias pentru heuristic (răspunsul o spune).
  • heuristic — Implicit — un packer guillotine cu strategii multiple. Randament maxim, fiecare layout poate fi tăiat cu ferăstrăul și returnează întotdeauna un plan de tăiere. Deservește 2D, 1D și lemnul.
  • balanced — Un free-nester MaxRects opțional pentru 2D. Mult mai rapid pe lucrări foarte mari, cu un randament ușor mai mic, dar layouturile lui adesea nu pot fi tăiate cu ferăstrăul dintr-o margine în alta, așa că nu poartă niciun plan de tăiere.
  • max — O căutare arborescentă asincronă pentru 2D. Atinge optimul demonstrat pe mult mai multe lucrări, în câteva secunde până la un minut per rezolvare — trimiți lucrarea și interoghezi GET /v1/jobs/{id} pentru rezultat. Rămâne determinist și tăiabil cu ferăstrăul.
  • lbf — Motorul de nesting true-shape. Împachetează poligoane neregulate în buzunarele unora în ale altora, pentru laser, plasmă și jet de apă; este planificat un build sparrow cu densitate mai mare.

Care endpoint pentru care material: plăci plane — placaj, MDF, sticlă, acril, tablă — merg la /v1/optimize/2d; bare, tuburi, țevi și profile la /v1/optimize/1d; lemn structural (un 50×150 doar dintr-un 50×150) la /v1/optimize/wood; poligoane neregulate pentru laser, plasmă și jet de apă la /v1/optimize/nest.

Un singur apel, un plan complet

curl https://api.cutoptim.com/v1/optimize/2d \
  -H "Authorization: Bearer co_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "parts": [
      { "name": "Door",    "w": 600, "h": 400, "qty": 4 },
      { "name": "Shelf",   "w": 800, "h": 300, "qty": 6 }
    ],
    "stock":   [{ "w": 2440, "h": 1220, "price": 42 }],
    "options": { "kerf": 3, "effort": "balanced" },
    "engine":  "heuristic"
  }'

Răspunsul primit:

{
  "metrics": { "sheetCount": 1, "yieldPct": 80.62, "placed": 10, "total": 10,
               "cutLines": 10, "sawPasses": 13, "cutLength": 10720, "totalPrice": 42 },
  "sheets":  [ … ],
  "cutPlan": [{ "sheet": 0, "step": 1, "axis": "h", "pos": 400, "length": 2440, "stage": 1 }, … ],
  "guillotineValid": true,
  "engineVersion": "1.0.0+10e0c941",
  "deterministic": true
}

Structura completă a cererii și a răspunsului, fiecare opțiune, toate codurile de eroare și toate cele trei motoare:Documentația API →

Fast sau dens? Alege cu o singură opțiune

Opțiunea effort echilibrează timpul de calcul cu utilizarea. Iată acest compromis, măsurat pe o lucrare solicitantă — fiecare cifră provine din packerul real.

Comutatorul effort: utilizarea materialului vs timpul de calculComutatorul effort: utilizarea materialului vs timpul de calcul. fast: 350 plăci · 76.2% · ≈1.9 s. balanced: 330 plăci · 80.8% · ≈4.8 s. max: rezervat — mai dens = căutare mai lentă. La majoritatea lucrărilor (mai mici) cele două sunt identice; diferența apare doar la lucrările mari ca aceasta. balanced este valoarea implicită și nu este niciodată mai dens decât poate atinge fast.Comutatorul effort: utilizarea materialului vs timpul de calculO lucrare solicitantă — circa 1.550 de piese pe o placă de 2,07 × 5,6 m. Fiecare cifră măsurată pe packerul real.74%76%78%80%82%84%02 s4 s6 stimp de calcul · mai rapid →utilizarea materialului · mai dens ↑⇄ comutatorul effort+4,6 pp utilizare · −20 plăci−5,7% material · ≈2,5× mai lentfast350 plăci · 76.2% · ≈1.9 s★ balanced · implicit330 plăci · 80.8% · ≈4.8 smaxrezervatmai dens =căutare mai lentă
La majoritatea lucrărilor (mai mici) cele două sunt identice; diferența apare doar la lucrările mari ca aceasta. balanced este valoarea implicită și nu este niciodată mai dens decât poate atinge fast.

Și oricum este rapid: chiar și cele mai mari lucrări de producție — 2.000 de piese și mai mult — se rezolvă în câteva secunde pe motorul implicit, confortabil în bugetul de timp al API-ului.

Prețuri

€49/lună
10,000 cereri / lună — plafon strict, fără depășiri, fără facturi surpriză
Perioadă de probă de 14 zile · facturare în EUR · odată atins plafonul, apelurile returnează 402 până la începutul lunii următoare

Volume mai mari. Cele 10,000 cereri pe lună sunt planul standard, nu un plafon al a ceea ce putem rula. Dacă ai nevoie de mai mult — volum mai mare, chei separate pentru staging și producție sau o înțelegere dedicată — spune-ne cifrele tale și îl tarifăm individual. Spune-ne volumul tău →

Planurile obișnuite CutOptim (Gratuit / Pro / Atelier) nu au legătură cu API-ul — optimizatorul din aplicație rămâne inclus în ele. Vezi prețurile aplicației →

Solutions by industry

The same engine, positioned for the way one trade cuts. Each page shows the endpoint, a request and a response, and the fields that matter for that material.

Resursă descărcabilă
Engine API one-pager

The why, what and how of the CutOptim Engine API on two pages — the three modes, a request and response, determinism and pricing. Print-ready, with a QR back to this page.

PDF2 pagesFree
Descarcă PDF-ul

Întrebări frecvente

Are CutOptim un API?
Da — API-ul CutOptim Engine expune același motor de debitare prin HTTP, pentru un ERP, un instrument de ofertare sau software de mașină, în toate cele trei moduri ale aplicației: panouri 2D, liniar 1D și lemn cu potrivire de secțiune.
Există un API pentru tăiere cu laser, plasmă sau jet de apă?
Da — nesting-ul true-shape al poligoanelor neregulate este al patrulea mod al API-ului Engine, POST /v1/optimize/nest. Trimiți fiecare piesă ca un contur poligonal (cu găuri opționale) împreună cu plăcile din stoc; motorul îmbină piesele în buzunarele concave ale celorlalte și returnează amplasarea fiecărei copii, astfel încât o lucrare cu laser, plasmă sau jet de apă se cuibărește mult mai strâns decât un dreptunghi de încadrare — pe o lucrare reprezentativă de 272 de piese, 6 plăci acolo unde aceleași piese după dreptunghiul de încadrare au nevoie de 9. Zone de excludere pe placă (un defect, o menghină) și rotație continuă sunt incluse. Funcționează astăzi prin API-ul Engine; aplicația în sine taie în continuare dreptunghiuri.
Este API-ul Engine determinist?
Da. Aceeași intrare returnează aceeași ieșire, deci răspunsurile sunt cache-abile și testabile, iar versiunea motorului poate fi fixată pentru rezultate reproductibile.
Ce conține un răspuns de optimizare?
Aranjamentul complet, un plan de debitare ghilotină cu poziții de oprire pe pas și metricile (număr de plăci, randament, linii de tăiere, treceri de fierăstrău, lungime tăiată). Endpointul 2D returnează și metrii de cant pe tip, iar fiecare endpoint acceptă o etichetă de material și returnează un sumar pe material. Poți cere aranjamentul și ca SVG, DXF sau CSV inline și poți atașa un obiect meta la piese și la stoc, returnat identic.
Poate API-ul să îmi dea un desen, nu doar coordonate?
Da. Adaugă include:["svg","csv","dxf"] la o cerere de optimizare, iar răspunsul poartă aranjamentul ca fișier gata făcut, inline: un desen SVG 2D autonom, un DXF R12/AC1009 sau o listă de debitare CSV. Fără stocare și fără un al doilea apel. SVG este doar 2D; o cerere 1D sau lemn returnează în schimb un avertisment.
Pot atașa propriile ID-uri la piese și să le citesc înapoi?
Da. Orice rând de piesă sau de stoc poate purta un obiect meta — numărul tău de articol ERP, id-ul liniei de comandă sau referința clientului —, și revine identic pe fiecare piesă plasată și fiecare placă sau bară, astfel încât planul de debitare se reconciliază cu propriul tău sistem. Nu afectează niciodată aranjamentul.
Pot verifica o cerere fără să consum un apel?
Da. POST /v1/validate/2d, /1d sau /wood validează după schemă același corp pe care îl acceptă endpointul de optimizare corespunzător, fără a rezolva — fără cheie și fără cotă. Un 400 numește exact câmpul greșit, iar tu primești avertismente de fezabilitate (o piesă care nu încape în niciun stoc) înainte să consumi un apel real.
Există SDK-uri, webhook-uri sau job-uri asincrone?
Nu există SDK-uri și nici webhook-uri — dar există o specificație OpenAPI 3.1 către care poți îndrepta un generator de cod pentru un client tipizat. Majoritatea apelurilor de optimizare sunt HTTP sincron simplu care returnează direct planul finalizat. Singura excepție este motorul asincron max (doar 2D): POST /v1/optimize/2d cu engine:"max" returnează 202 Accepted cu un jobId, iar tu interoghezi GET /v1/jobs/{id} până se termină — pentru când atingerea optimului dovedit merită de la câteva secunde la un minut de calcul.
Care sunt limitele cererii?
Până la 2.000 de piese, 50 de rânduri de stoc și un corp al cererii de 1 MB per apel. Chiar și cele mai mari lucrări se rezolvă în câteva secunde, confortabil în bugetul de timp.
Gestionează cheile API