Outputs: drawings, labels, PDFs

The include array narrows the response and adds ready-made files to it.

The include array

Three kinds of token. NARROWING (cutPlan, offcuts): omit the field entirely to get both; a present array keeps only the narrowing tokens it lists (an empty array drops both). ADDITIVE EXPORT (svg, csv, dxf): each adds an inline export STRING to the response (svg a standalone 2D layout — 2D only, a warning is returned for 1D/wood; dxf an R12/AC1009 drawing; csv a cut list, RFC 4180 quoted (a part name with a comma or a quote stays one field) and formula-injection-guarded (a name beginning with =, +, -, @, TAB or CR is prefixed with an apostrophe so a spreadsheet reads it as text, not a formula — CWE-1236). 2D DATA (labels, planHash, pdf, labelsPdf): labels adds per-piece label data (labels[], see Label2D), planHash a 64-hex fingerprint of the plan (the same plan always gives the same hash), pdf the cutting-plan PDF and labelsPdf the label PDF, both base64-encoded and drawn by the same code as the CutOptim app. These four are 2D only: a 1D or wood request returns a warnings entry instead. pdf renders at most 500 parts (total quantity); a larger 2D request with pdf is a 413 too_large with details.path: "include". Export and data tokens do not affect narrowing, so ["svg"] adds svg and — listing no narrowing token — drops cutPlan/offcuts; use ["cutPlan","offcuts","svg"] to keep everything.

Every field these tokens add — svg, csv, dxf, labels, planHash, pdf, labelsPdf — is in the 2D response tables of the 2D guide, including the labels[] table. On nesting, include takes svg and dxf (see the nesting guide).

Decoding the PDFs

pdf and labelsPdf are base64 strings inside the JSON. Decode them to bytes and save them as .pdf:

curl -s https://api.cutoptim.com/v1/optimize/2d \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"parts":[{"w":600,"h":400,"qty":4}],"stock":[{"w":2440,"h":1220}],"include":["pdf"]}' \
  | jq -r .pdf | base64 -d > plan.pdf