Documentation · Printy3D

How it works#

Upload a file. Reserve it with POST /v1/files, send the bytes straight to storage with the presigned URL you get back, then complete it. The API checks the file and marks it ready or rejected. Uploads
Run a job. POST /v1/jobs with the file and a recipe: inspect, repair, tool or cad_check. Jobs are queued and run on a GPU (Exact Check on its own CPU workers); you poll them until they finish, or have an Exact Check job call a webhook. Jobs & polling
Download the artifacts. A finished job lists its outputs; each one has a short-lived download URL. Artifacts & exports
Export another format when you need it: ask for a GLB, OBJ, 3MF, STL or PLY of a repair or tool result, and Printy3D converts it if the job did not already produce it.

The recipes#

Recipe	What you get	Typical use
`inspect`	Analysis (size, volume, watertightness, holes, shells, recommended repair settings), eight thumbnails and a GLB preview.	Show a model and tell whether it will print, before spending a repair on it.
`repair`	A print-ready, watertight mesh with its textures, as GLB and OBJ (ZIP with MTL and textures), plus before/after analysis.	Turn a game asset, scan or sculpt into something a printer accepts.
`tool`	One operation: cut, mirror, lattice, label, remove small parts, convert, measure, thickness, structural analysis and more.	Split a model to fit a printer, add infill or a label, check walls or strength.
`cad_check`	Exact Check of a STEP part or assembly: walls, gaps and how the parts sit together, measured as designed, then judged free against any process and material.	Tell a customer whether their CAD model will print, with which process, before quoting it.

Base URL and conventions#

All endpoints live under https://printy3d-api-staging.onrender.com/v1. Requests and responses are JSON with snake_case fields; ids carry a prefix (file_, job_, key_) and timestamps are RFC 3339 in UTC.

Authentication: Authorization: Bearer p3d_test_… or p3d_live_…. Authentication & keys
Idempotency: every creating POST takes an Idempotency-Key header, so a retry never creates a second file, job or key.
Errors are RFC 9457 problem documents with a stable code and a human detail. Errors
Lists are cursor-paginated: limit (1–100, default 20) and cursor from the previous page's next_cursor.

Test and live#

Every key is either a test key or a live key. Test keys run inspect, repair and tool jobs free of charge in a sandbox, with the same endpoints, objects and errors; the results are marked simulated: true and the input geometry is not processed: the outputs are placeholder artifacts (a one-triangle mesh, labelled thumbnails, analysis and tool results with simulated: true). Use test mode to build the upload, job, poll and download flow, not to judge repair quality. An Exact Check made with a test key is free too and reports one simulated part (Exact Check). Live keys run the real engine on GPUs and spend credits, where one credit is one second of run time. Test and live data are separate: a test key never sees live files or jobs.

Where to go next#

Quickstart: your first inspect job in a few minutes.
Repair: every repair setting, with pictures of what it changes.
API reference: every endpoint and schema, generated from the OpenAPI document.
Python and TypeScript SDKs.