Build path: product to print-ready PDF

Create a product, define print sides, save a design and generate a print-ready PDF.

The sequence

text
POST /account            -> JWT
POST /stores             -> sid, secret, unauth_token
POST /products           -> product
POST /sides              -> printable surface (design area, bleed, safe zone)
   or POST /products/{id}/sides/import-from-template
POST /images             -> upload artwork (or POST /multipart/create for large files)
POST /designs            -> saved design (creates a project implicitly)
POST /projects           -> order (or reuse the implicit one)
POST /designs/{id}/generate/print-pdf -> print-ready PDF
POST /webhooks           -> get notified when things change

Each step is documented with request and response schemas in the API reference. Authentication for each call is covered in Authentication.

Sides carry print-readiness

A product on its own is not printable. The side carries the geometry:

Response fieldMeaning
design_area{width, height, top, left}: the printable rectangle
cut_line_margin{x, y}: bleed, left and right and top and bottom
safe_zone_margin{x, y}: the keep-clear margin inside the trim
side_image_size{width, height}: the mockup image size
scalepixels per dimension_unit, which turns canvas coordinates into physical size

Geometry is submitted in the same grouped form, not as flat columns. Units come from the product's dimension_unit, which is inch, cm or px.

GET /products/{product}/production-readiness reports what is still missing before a product can produce output. It is a useful onboarding pre-flight.

Designs

POST /designs takes either multipart/form-data with a design_file, or JSON that references a design_image_id you uploaded earlier. Send exactly one of side_id or product_id, and exactly one of the two file inputs.

layers, the canvas document, is submitted as a JSON-encoded string and returned as JSON. Each design snapshots the side geometry into original_side, so editing the side later does not change how an existing design renders.

Output

EndpointProduces
POST /designs/{design}/generate/print-pdfA print-ready CMYK PDF with TrimBox and BleedBox and marks. For a canvas product, the full print sheet with a cut line
POST /designs/{design}/generate/pdfA plain RGB page at the design-area size, with no bleed, marks or boxes. Not a press file
POST /designs/{design}/generate/preview-pdfA low-resolution proof. Do not send it to press
POST /designs/{design}/generate/pngA raster image for thumbnails and emails

The PDF endpoints cache their result: repeat calls return the same file until you pass {"reset": true}. The PNG endpoint takes no body. Rendering is synchronous and can take several seconds.

Projects are orders

When a store is connected to a platform such as WooCommerce, Shopify or Wix, one platform order becomes one project. Commercial fields on a project, such as customer email, totals and currency, are derived from the order data the platform integration wrote.

A project you create directly through the API does not have that order data, so those fields are empty. Keep your own order record as the source of truth for commerce and use the project id as the join key.

GET /projects/{project} returns everything needed to produce an order. It is the only response that embeds project_items, and those items embed their designs.

Related