Parts from SVG and DXF

A drawing instead of coordinates — inline on a part, or imported first.

Parts from a file (SVG · DXF)

A part does not have to arrive as coordinates. Put an SVG or DXF document in parts[].source and the server reads the outline — and its holes — out of it with the same parser the CutOptim app uses when you drop a drawing on its Nesting mode. The file replaces ONLY the geometry: qty, material, allowedRotations, minQuality, priority and meta behave exactly as they do on a polygon part, so a part library that already exists as CAD files needs no path-and-arc flattener of your own.

One source describes ONE part; a drawing holding several separate components is a 400 that points you at the import endpoint below. The response then carries an imported block saying how many rows came from a file, how many vertices they produced, and which units those files declared — reported, never applied, because this API converts nothing.

Nothing is stored. The bytes exist only as the request body, are parsed in memory, and are gone when the response is written: no disk, no database, no temporary file, no log line. There is nothing to delete afterwards and nothing retained — the same statelessness every other endpoint keeps.

POST /v1/optimize/nest

{
  "parts": [
    {
      "source": {
        "content": "<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 400 200\">\n  <path d=\"M0 0 H120 V80 H0 Z\"/>\n  <path d=\"M40 30 H80 V50 H40 Z\"/>\n</svg>",
        "filename": "washer-plate.svg"
      },
      "qty": 4,
      "meta": { "erpId": "ART-8891" }
    }
  ],
  "stock": [{ "w": 2440, "h": 1220 }]
}

Field names and types are the contract, so the tables below stay in English in every language — a translated field name would document an API that does not exist.

{
  "imported": { "parts": 1, "vertices": 8, "units": [] },
  "parts_after_import": [
    {
      "name": "washer-plate",
      "polygon": [[0, 0], [120, 0], [120, 80], [0, 80]],
      "holes": [[[40, 30], [80, 30], [80, 50], [40, 50]]],
      "qty": 4,
      "meta": { "erpId": "ART-8891" }
    }
  ]
}

POST /v1/import/nest — one file, every outline

When a single drawing holds several different parts, import it first: this endpoint returns every closed outline it contains, largest first, in exactly the shape a parts[] row wants. Paste in the ones you need, add your own qty and material, and post that to /v1/optimize/nest. It is also how you see what is in a file before spending a solve on it.

It needs a key — flattening arbitrary geometry is real CPU work, and anonymous CPU is a bad trade — but it reserves nothing: your quota is untouched and no rate-limit headers come back, exactly like polling a job.

POST /v1/import/nest
Authorization: Bearer co_live_…

{
  "content": "<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 400 200\">\n  <path d=\"M0 0 H120 V80 H0 Z\"/>\n  <path d=\"M40 30 H80 V50 H40 Z\"/>\n</svg>",
  "filename": "washer-plate.svg"
}

{
  "format": "svg",
  "parts": [
    {
      "name": "washer-plate",
      "polygon": [[0, 0], [120, 0], [120, 80], [0, 80]],
      "holes": [[[40, 30], [80, 30], [80, 50], [40, 50]]]
    }
  ],
  "vertices": 8,
  "warnings": [],
  "engineEnabled": true,
  "contractVersion": "1"
}