Aller au contenu principal
POUR LES DÉVELOPPEURS

CutOptim Engine API

Une API d’optimisation de découpe : envoyez les pièces et le stock — panneaux 2D, barres 1D, bois ou imbrication à forme réelle de pièces irrégulières — et récupérez la disposition, le plan de découpe et le rendement. Par défaut, la même requête renvoie toujours le même plan.

Voir le benchmark complet → · Mesuré, pas revendiqué

POST /v1/optimize/nest
{
  "parts": [
    { "name": "bracket", "polygon": […], "qty": 12, … },
    { "name": "gusset", "polygon": […], "qty": 14, … },
    { "name": "plate", "polygon": […], "holes": […], "qty": 12, … },
    { "name": "flange", "source": { … }, "qty": 10, … }
  ],
  "stock": [{ "w": 2500, "h": 1250, "exclusions": […], … }],
  "options": { "minSeparation": 5, "edgeClearance": 10 }
}
200 sheets[0] · 2500 × 1250
1 sheetCount48/48 placed0.5632 density110 pierces
Un vrai appel à POST /v1/optimize/nest : la requête et la tôle renvoyée, dessinée à partir des coordonnées de la réponse.

Pourquoi construire dessus

DÉTERMINISTE

Une même entrée renvoie toujours le même résultat — aucun aléatoire, aucune horloge dans l'algorithme. Vous pouvez mettre les résultats en cache et les comparer dans vos tests. L'unique exception facultative, la recherche max d'imbrication limitée dans le temps, le déclare dans chaque réponse (deterministic: false).

UN VRAI PLAN DE DÉCOUPE

Pas seulement des rectangles : la séquence de coupes guillotine, les lignes de coupe face aux passes de scie, la longueur sciée, et un indicateur qui dit si le plan est réalisable sur une scie à panneaux.

PENSÉ POUR LA SCIE À PANNEAUX

Trait de scie, délignage par côté, tolérance, mode coût, sens du fil et correspondance du grain, nombre maximal de phases de coupe, minimisation des rotations — les mêmes options que celles de l'application.

Le développer, ou l'appeler

Un optimiseur de découpe ressemble à un projet de week-end, puis se transforme en une longue traîne de cas particuliers : arithmétique du trait de scie et du délignage, stock qui s'épuise, règles de rotation et de grain, dispositions qui doivent être sciables de bord à bord, polygones avec des trous — et une suite de régression qui prouve qu'un changement ne dégrade jamais un plan. L'Engine API, c'est ce travail, déjà fait et mesuré.

CE QUE VOUS ÉVITEZ

Écrire et valider quatre optimiseurs — panneaux 2D guillotine, stock 1D linéaire, bois par section et imbrication à forme réelle — et les maintenir corrects à mesure que vos besoins évoluent. Votre équipe intègre un seul contrat HTTP à la place.

CE QUE VOUS POUVEZ VÉRIFIER

La qualité des plans est publiée, pas seulement affirmée : le benchmark ouvert exécute le moteur sur des jeux d'instances académiques publics et des travaux générés, avec la méthode et les résultats bruts téléchargeables. Exécutez les mêmes instances sur tout autre outil que vous envisagez.

CE QU'IL FAUT POUR DÉMARRER

Un prix affiché sur la page, un essai de 14 jours et une clé depuis votre tableau de bord — aucun appel commercial, aucune négociation de licence avant de pouvoir tester. Les endpoints validate ne nécessitent même aucune clé.

CE QUI RESTE À VOUS

Votre modèle de données, votre interface et vos règles de tarification. Les appels synchrones ne stockent rien ; un travail asynchrone max ne conserve son résultat que pendant une courte fenêtre de rétention, le temps de l'interroger. Un objet meta sur une pièce ou un panneau revient à l'identique, pour que le plan se réconcilie avec vos registres.

Voir le benchmark complet →

Besoin d’un écran de commande prêt à l’emploi plutôt que de le développer ?

CutOptim Configurator fonctionne sur ce moteur →Relier votre boutique ou ERP →

Tarifs

Studio
€49/mois
3,000 requêtes / mois — plafond strict, aucun dépassement, aucune facture surprise
Essai de 14 jours · facturation en EUR · une fois le plafond atteint, les appels renvoient 402 jusqu'au passage au mois suivant
Scale
€149/mois
10,000 requêtes / mois — plafond strict, aucun dépassement, aucune facture surprise
Sans essai · facturation en EUR · changement d'offre depuis le tableau de bord

Chaque requête compte de la même façon — imbrication comprise · Nous vous écrivons à 90 % du quota, puis lorsqu'il est épuisé.

Essayez gratuitement : une clé de démo publique dans la documentation de l'API, et des clés de test de 1,000 requêtes par mois, jamais facturées

Volumes plus importants. 10,000 requêtes par mois correspondent à l'offre standard, ce n'est pas un plafond de ce que nous pouvons faire tourner. S'il vous faut davantage — un volume plus élevé, des clés distinctes pour la préproduction et la production, ou un accord dédié —, indiquez-nous vos chiffres et nous tarifons au cas par cas. Indiquez-nous votre volume →

En vous abonnant, vous acceptez : Engine API Service Terms (en anglais).

Les offres CutOptim habituelles (Gratuit / Pro / Atelier) n'ont aucun lien avec l'API — l'optimiseur intégré à l'application y reste inclus. Voir les tarifs de l'application →

Ce qui entre, ce qui sort

Un vrai travail par mode : en haut le corps de la requête, en dessous le plan renvoyé, dessiné directement à partir de la réponse.

EntrePOST /v1/optimize/2d
{
  "parts": [
    { "name": "Side", "w": 720, "h": 560, "qty": 6 },
    { "name": "Bottom", "w": 764, "h": 560, "qty": 3 },
    { "name": "Top", "w": 764, "h": 560, "qty": 3 },
    { "name": "Shelf", "w": 762, "h": 520, "qty": 3 },
    { "name": "Rail", "w": 764, "h": 100, "qty": 6 },
    { "name": "Plinth", "w": 764, "h": 120, "qty": 6 },
    { "name": "Door", "w": 397, "h": 716, "qty": 6, "rotatable": false },
    { "name": "Drawer front", "w": 796, "h": 176, "qty": 3 }
  ],
  "stock": [
    { "w": 2800, "h": 2070, "qty": 5, "price": 38.5 }
  ],
  "options": { "kerf": 4, "trim": { "left": 10, "right": 10, "top": 10, "bottom": 10 } }
}
Utilise une clé de démo publique — limitée, petits travaux uniquement, jamais facturée.
Sort200 · sheets[].parts
Panneaux
2
sheetCount
Rendement
80,31 %
yieldPct
Pièces placées
36 / 36
placed
Lignes de coupe
39
cutLines
Coût matière
77
totalPrice

Une rangée de meubles bas en aggloméré standard. Les portes gardent leur fil (rotatable: false) ; toutes les autres pièces peuvent tourner.

L'image directement depuis l'API ? En 2D et en nesting, ajoutez "svg" à include et la réponse contient le dessin.

Chaque dessin est tracé à partir des coordonnées de la réponse — rien n'est placé à la main. Les quatre travaux sont résolus par le même moteur que l'API, et notre suite de tests les résout à nouveau pour que les chiffres restent exacts.

Ce que fait l'API

Quatre modes de découpe

Un appel pour chacun : panneaux 2D, barres 1D, bois avec correspondance de section, et imbrication à forme réelle de polygones irréguliers — POST /v1/optimize/2d, /1d, /wood et /nest.

Imbrication à forme réelle

POST /v1/optimize/nest place des polygones arbitraires (avec trous) sur des feuilles fixes, en imbriquant les pièces dans les poches concaves les unes des autres — 6 feuilles là où les mêmes pièces en rectangle englobant en exigent 9. Pour le laser, le plasma et le jet d'eau. Avec, en prime, des zones d'exclusion par feuille (un défaut, une bride).

Conscient du matériau

Étiquetez les pièces et le stock avec un material et l'optimiseur partitionne le travail : chaque material n'est découpé que dans son propre stock. Sur chaque mode ; un récapitulatif par material est renvoyé.

Placage de chant

Nommez un type de chant par arête (2D) et la réponse totalise les mètres linéaires par type — par pièce et par commande. Métadonnée : cela ne déplace jamais une pièce.

Correspondance du grain

Nommez les pièces dont le motif doit se prolonger — une façade de tiroir au-dessus de deux portes — dans un ensemble assorti (matchedSets, 2D), et elles sont découpées côte à côte dans une même planche, à un trait de scie d'écart. Chaque membre revient avec son ensemble et sa position, et les exports CSV, SVG et DXF les marquent aussi.

Export en ligne (SVG · DXF · CSV)

Demandez include:["svg","csv","dxf"] et la réponse porte la disposition sous forme de fichier prêt à l'emploi, en ligne — un dessin SVG 2D autonome, un DXF R12/AC1009 ou une liste de coupe CSV. Aucun stockage, aucun second appel.

Transfert de métadonnées

Attachez un objet meta — votre numéro d'article ERP, un identifiant de ligne de commande, une référence client — à toute pièce ou ligne de stock, et il revient à l'identique sur chaque pièce placée et chaque panneau/barre, pour que le plan se réconcilie avec votre système.

Validation gratuite

POST /v1/validate/{2d,1d,wood} valide le schéma du même corps sans le résoudre — sans clé, sans quota. Vérifiez qu'une charge utile ne sera pas rejetée et obtenez des avertissements de faisabilité avant de dépenser un appel.

Coût ou chute

minimizeCost classe selon la facture totale la plus basse sur les formats de stock tarifés, en les mélangeant ; par défaut, c'est le matériau qui est minimisé. Les deux exécutent le même algorithme guillotine.

Priorité de stock et stock limité

Marquez le stock à épuiser en premier, traitez les quantités comme un plafond strict avec respectStock, et signalez les pièces à découper impérativement, qui gagnent la place sur la plaque quand le matériau manque.

Un vrai plan de découpe

Pas seulement des rectangles : la séquence de coupes guillotine avec les positions de butée par étape, les lignes de coupe face aux passes de scie, la longueur sciée, et un indicateur de faisabilité sur scie à panneaux.

Paramètres de scie à panneaux

kerf, délignage par côté, tolérance, sens du fil, matched sets, maxCutStages et minimisation des rotations — les mêmes options que celles de l'application.

Déterministe & OpenAPI

Une même entrée renvoie toujours le même résultat — mettez-le en cache et comparez-le (la recherche max d'imbrication, facultative et limitée dans le temps, indique deterministic: false). Une version de moteur épinglable et un document OpenAPI 3.1 décrivent tout le contrat.

Des pièces depuis des fichiers CAO

Envoyez un SVG ou un DXF au lieu de coordonnées : parts[].source lit le contour et ses trous dans le dessin, et POST /v1/import/nest découpe d'abord un fichier multi-pièces. Rien n'est conservé — le fichier est analysé en mémoire et disparaît avec la réponse.

Serveur MCP pour assistants IA

Claude Code, Cursor, VS Code et Claude Desktop appellent le moteur comme des outils via https://api.cutoptim.com/mcp, avec la même clé d'API et le même quota que REST. Il tourne aussi en local avec le paquet npm @cutoptim/mcp.

Guide MCP →EN

Deux vitesses : devis immédiat, économie de matériau plus tard

La plupart des intégrations ont besoin des deux — une réponse pendant que le client attend, et un plan plus serré quand le travail part sur la machine. Vous choisissez par appel.

INSTANTANÉ

Les moteurs synchrones — heuristic pour le 2D, le 1D et le bois, lbf pour l'imbrication — répondent à l'intérieur de la requête HTTP, de façon déterministe, si bien que le plan derrière un devis est le plan derrière la commande.

MAX

Envoyez le travail avec engine: "max" et interrogez GET /v1/jobs/{id} pour obtenir le résultat. Sur les panneaux 2D, il recherche l'optimum prouvé ; sur l'imbrication à forme réelle, il consacre un budget de temps (options.timeBudgetMs) à chercher moins de feuilles, sans jamais en renvoyer davantage que la réponse instantanée.

La réponse a la même structure dans les deux cas. En 2D, le moteur max accepte un ensemble d'options plus restreint que heuristic (la documentation les liste), et un travail d'imbrication avec des zones d'exclusion reste servi par lbf.

Quel moteur sert quel mode

L'endpoint que vous appelez en POST choisit le mode ; le paramètre engine choisit l'algorithme. Le moteur heuristic par défaut sert le 2D, le 1D et le bois ; balanced est réservé au 2D ; le moteur asynchrone max sert les panneaux 2D et l'imbrication à forme réelle ; et l'imbrication a pour moteur par défaut son propre moteur lbf. Le même moteur que l'application, en HTTP.

Mode · endpointMoteur · algorithmePanneaux 2D/v1/optimize/2d1D linéaire/v1/optimize/1dBois · section/v1/optimize/woodImbrication à forme réelle/v1/optimize/nestheuristicpar défaut · synchronebalancedsur option · 2D uniquementmaxasynchrone · 2D + nestlbfimbrication · par défautEn 1D et en bois, balanced est simplement un alias de heuristic (la réponse le précise).
  • heuristic — Le moteur par défaut — un packer guillotine multi-stratégies. Rendement maximal, chaque disposition est sciable, et il renvoie toujours un plan de découpe. Il sert le 2D, le 1D et le bois.
  • balanced — Un free-nester MaxRects en option pour le 2D. Bien plus rapide sur les très gros travaux pour un rendement légèrement moindre, mais ses dispositions ne peuvent souvent pas être sciées de bord à bord, elles ne portent donc aucun plan de découpe.
  • max — Le palier asynchrone : vous soumettez le travail et interrogez GET /v1/jobs/{id} pour le résultat. En 2D, c'est une recherche arborescente qui atteint l'optimum prouvé sur bien plus de travaux, en quelques secondes à une minute par résolution — toujours déterministe et sciable. Sur l'imbrication à forme réelle, il exécute d'abord lbf, puis consacre un budget de temps à chercher une disposition avec moins de feuilles, sans jamais en renvoyer davantage ; cette recherche est limitée dans le temps, ses imbrications indiquent donc deterministic: false.
  • lbf — Le moteur par défaut de l'imbrication à forme réelle. Il imbrique des polygones irréguliers dans les poches les uns des autres pour le laser, le plasma et le jet d'eau — instantanément et de façon déterministe. max (ci-dessus) peut ensuite chercher une version du même travail avec moins de feuilles.

Quel endpoint pour quel matériau : les panneaux plats — contreplaqué, MDF, verre, acrylique, tôle — vont vers /v1/optimize/2d ; les barres, tubes, tuyaux et profilés vers /v1/optimize/1d ; le bois de structure (un 50×150 uniquement depuis un 50×150) vers /v1/optimize/wood ; les polygones irréguliers pour le laser, le plasma et le jet d'eau vers /v1/optimize/nest.

Un appel, 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éponse renvoyée :

{
  "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
}

Structure complète de la requête et de la réponse, toutes les options, tous les codes d'erreur et tous les moteurs :Documentation de l'API → · Guide d'intégration →

Fast ou dense ? Choisissez avec une seule option

L'option effort arbitre entre le temps de calcul et l'utilisation. Voici ce compromis, mesuré sur un travail exigeant — chaque chiffre provient du vrai packer.

Sélecteur effort : utilisation matière vs temps de calculSélecteur effort : utilisation matière vs temps de calcul. fast: 350 panneaux · 76.2% · ≈1.9 s. balanced: 330 panneaux · 80.8% · ≈4.8 s. max: réservé — plus dense = recherche plus lente. Sur la plupart des travaux (plus petits), les deux sont identiques ; l'écart ne se creuse que sur les gros travaux comme celui-ci. balanced est la valeur par défaut et n'est jamais plus dense que ce que fast peut atteindre.Sélecteur effort : utilisation matière vs temps de calculUn travail exigeant — environ 1 550 pièces sur un panneau de 2,07 × 5,6 m. Chaque chiffre mesuré sur le vrai packer.74%76%78%80%82%84%02 s4 s6 stemps de calcul · plus rapide →utilisation matière · plus dense ↑⇄ le sélecteur effort+4,6 pts utilisation · −20 panneaux−5,7 % matière · ≈2,5× plus lentfast350 panneaux · 76.2% · ≈1.9 s★ balanced · par défaut330 panneaux · 80.8% · ≈4.8 smaxréservéplus dense =recherche pluslente
Sur la plupart des travaux (plus petits), les deux sont identiques ; l'écart ne se creuse que sur les gros travaux comme celui-ci. balanced est la valeur par défaut et n'est jamais plus dense que ce que fast peut atteindre.

Et c'est rapide dans tous les cas : même les plus gros travaux de production — 2 000 pièces et plus — se résolvent en quelques secondes avec le moteur par défaut, largement dans le budget de temps de l'API.

Solutions par secteur

Le même moteur, présenté pour la façon dont un métier découpe. Chaque page montre l'endpoint, une requête et une réponse, ainsi que les champs qui comptent pour ce matériau.

Le moteur travaille sur de la géométrie, pas sur un catalogue de matériaux : tôle et plaque, panneaux à base de bois, verre, plastiques et acrylique, composites, mousse, carton et papier passent tous par les mêmes endpoints. Le matériau ne change que les nombres que vous envoyez — trait de scie ou espacement entre pièces, dégagement de bord, tailles de stock.

Ressource à télécharger
Engine API one-pager

The why, what and how of the CutOptim Engine API on two pages — the four modes, a real request and its plan, how to try it free, and the two plans. Print-ready, with a QR back to this page.

PDF2 pagesFree
Télécharger le PDF

Questions fréquentes

CutOptim propose-t-il une API ?
Oui — l’API CutOptim Engine expose le même moteur de coupe via HTTP, pour un ERP, un outil de chiffrage ou un logiciel machine, dans les trois modes de l’application : panneaux 2D, linéaire 1D, et bois avec correspondance de section.
Existe-t-il une API pour la découpe laser, plasma ou jet d’eau ?
Oui — l’imbrication true-shape de polygones irréguliers est le quatrième mode de l’API Engine, POST /v1/optimize/nest. Vous envoyez chaque pièce sous forme de contour polygonal (avec trous optionnels) et les tôles en stock ; le moteur imbrique les pièces dans les poches concaves des autres et renvoie le placement de chaque exemplaire, de sorte qu’un travail laser, plasma ou jet d’eau s’imbrique bien plus serré qu’un rectangle englobant — sur un travail représentatif de 272 pièces, 6 tôles là où les mêmes pièces par boîte englobante en demandent 9. Des zones d’exclusion par tôle (un défaut, une bride) et la rotation continue sont incluses ; l’espacement entre les pièces (minSeparation) et l’espace au bord de la tôle (edgeClearance) se règlent séparément, et la réponse totalise les tôles utilisées par taille de stock — en mélangeant les tailles quand c’est plus économique — et indique la longueur de coupe et le nombre de perçages de chaque tôle, ainsi que sa largeur et sa hauteur utilisées depuis le coin de la tôle (pour facturer une partie de tôle ; la tôle la moins remplie est compactée vers ce coin). L’application dispose de la même imbrication, dans son propre mode Nesting.
L’API Engine est-elle déterministe ?
Oui. La même entrée renvoie la même sortie, donc les réponses sont cachables et testables, et la version du moteur peut être figée pour des résultats reproductibles. L'unique exception facultative est le moteur max d'imbrication : sa recherche est limitée dans le temps, il indique donc deterministic: false dans chaque réponse.
Que contient une réponse d’optimisation ?
La disposition complète, un plan de coupe guillotine avec positions d’arrêt par étape, et les métriques (nombre de panneaux, rendement, lignes de coupe, passes de scie, longueur sciée). L’endpoint 2D renvoie aussi les mètres de chant par type, et chaque endpoint accepte une étiquette matière et renvoie un récapitulatif par matière. Vous pouvez aussi demander la disposition en SVG, DXF ou CSV inline, et attacher un objet meta aux pièces et au stock, restitué à l’identique.
L’API peut-elle fournir un dessin, pas seulement des coordonnées ?
Oui. Ajoutez include:["svg","csv","dxf"] à une requête d’optimisation et la réponse porte la disposition sous forme de fichier prêt à l’emploi, inline : un dessin SVG 2D autonome, un DXF R12/AC1009 ou une liste de coupe CSV. Aucun stockage et aucun second appel. Le SVG est en 2D uniquement ; une requête 1D ou bois renvoie plutôt un avertissement.
Puis-je attacher mes propres identifiants aux pièces et les relire ?
Oui. Toute ligne de pièce ou de stock peut porter un objet meta — votre numéro d’article ERP, votre identifiant de ligne de commande ou votre référence client —, et il revient à l’identique sur chaque pièce placée et chaque panneau ou barre, de sorte que le plan de coupe se réconcilie avec votre propre système. Il n’affecte jamais la disposition.
Puis-je vérifier une requête sans consommer un appel ?
Oui. POST /v1/validate/2d, /1d ou /wood valide selon le schéma le même corps que l’endpoint d’optimisation correspondant, sans résoudre — sans clé et sans quota. Un 400 nomme le champ exact en erreur, et vous obtenez des avertissements de faisabilité (une pièce qui ne tient dans aucun stock) avant de consommer un appel réel.
Y a-t-il des SDK, des webhooks ou des jobs asynchrones ?
Oui. Des SDK officiels pour TypeScript (npm @cutoptim/engine), Python (PyPI cutoptim) et PHP (Composer cutoptim/engine) sont open source sur github.com/cutoptim, générés à partir de la spécification OpenAPI 3.1 — pour tout autre langage, un générateur de code peut lire le même document. La plupart des appels d’optimisation sont du HTTP synchrone simple qui renvoie directement le plan terminé. La seule exception est le moteur asynchrone max, pour les panneaux 2D et pour l'imbrication à forme réelle : POST /v1/optimize/2d ou /v1/optimize/nest avec engine:"max" renvoie 202 Accepted avec un jobId, et vous interrogez GET /v1/jobs/{id} jusqu’à la fin — lorsqu'un meilleur plan vaut de quelques secondes à quelques minutes de calcul. Au lieu d’interroger, enregistrez un webhook sur votre tableau de bord : il envoie un POST signé à la fin du job.
Quelles sont les limites de requête ?
Jusqu’à 2 000 pièces, 50 lignes de stock et un corps de requête de 1 Mo par appel. Même les plus gros travaux se résolvent en quelques secondes, largement dans le budget de temps.
Gérer les clés API