Versioning
How API versions work, what is in v2, and how deprecations are announced.
Versions Live in the Path
Every endpoint starts with its version: /v1/… or /v2/…. There is no version header and no account-wide version setting.
v1 is the main API — almost every endpoint exists only in v1. A /v2/ endpoint exists only where an operation needed a
change that would have broken v1 callers, and the v1 original keeps working next to it. You can mix versions freely in one integration.
New fields, endpoints and optional parameters are added within a version, so build clients that ignore response fields they don't recognise.
v2 Endpoints
POST /v2/builds queues parts and whole SKUs, each with its own quantity, parameters and materials. It replaces POST /v1/builds, which is deprecated: it still accepts requests from existing integrations but is no longer listed in this reference. Use v2 for anything new.GET /v2/print-history returns the same records and filters as v1, but always as a paginated { data, meta } envelope (no meta=true needed), 100 per page, newest first. v1 returns a bare array unless you ask for meta, up to 1000 records in no particular order.Deprecations
A deprecated endpoint is marked "deprecated": true in the OpenAPI spec, shown with a
Deprecated banner in this reference. It keeps working until it is removed.
Responses carry no Deprecation or Sunset headers, so check the spec for the flag when you update your integration.
Currently deprecated: