X3D API

The X3D API takes a 3D model and a shipping address, prints the part on the farm in Austin, charges your saved card, and hands back an order code.

The X3D API does one job: it turns a 3D model into a printed part at somebody's door. You POST a file and a shipping address with your key, we quote it from the mesh we measure — or, if you send an already-sliced file, from the grams and hours the slicer recorded in it — charge the card on your account, print it in Austin, Texas, and post it. The call returns an order code you poll until tracking appears.

Base URL

https://x3dstudios.com

Every path on this page is relative to that host. There is no version segment and no separate api. subdomain — the endpoints sit on the same origin as the website.

OpenAPI description

The public endpoints are also published as an OpenAPI 3.1 document at https://x3dstudios.com/openapi.json, for API clients, code generators and AI agents. It is generated from these pages, so where the two could differ, they do not.

Status: live, self-serve, and deliberately small#

Keys are self-serve. Sign in, add a card at /profile, press Generate key, and you can submit an order a minute later. There is no waitlist, no approval step and no per-account allowlist in the code that issues keys.

The surface is small, and that is the honest description of it. Two endpoints do the printing — submit an order, read an order — plus three for managing your own key. There is no REST endpoint that lists your orders, no sandbox, no webhook, and an order cannot be cancelled or edited once it is in. What you do get without asking is email: every address on the order hears when it is paid, printed, shipped and delivered. If you need something changed after submitting, mail [email protected] with the order code.

Older posts say private beta

Two articles on the X3D blog describe the developer API as a private beta with keys issued on request. That is no longer how it works: the key is issued by your profile page the moment a card is on file. Trust this page over the blog.

Quickstart

From no account to a submitted, paid order — with a curl command you can paste.

MCP server

Point Claude or Cursor at one URL and let it quote, order and track without writing any of this by hand.

Authentication

Key format, both accepted headers, how keys are stored, rotation and revocation.

Submit an order

Every field POST /api/print/orders accepts, what it defaults to, and what comes back.

Errors

Every status code and the exact message the route returns with it.

Endpoints#

Method	Path	Auth	What it does
POST	/api/print/orders	API key	Submit a print order: a model file plus a shipping address. Charges the card on file and queues the job.
GET	/api/print/orders/{code}	API key	Read one order you own: status, price, and tracking once it ships.
POST	/api/mcp	API key or none	The MCP endpoint. An AI agent discovers the tools and calls them; quoting is public, ordering needs a key.
GET	/api/account/api-key	Session	Whether a key exists on the account, its display prefix, and when it was created.
POST	/api/account/api-key	Session	Issue a key, or rotate the existing one. The secret is returned exactly once.
DELETE	/api/account/api-key	Session	Revoke the key immediately.

The whole developer surface. Session auth means a signed-in browser, not a key.

Other endpoints are documented in this section — quoting a model at /docs/api/quote, listing orders at /docs/api/list-orders, generation at /docs/api/generate and /docs/api/generation-status, and mesh checks at /docs/api/printability. None of them accept an x3d_live_ key: they authenticate with a signed-in browser session, an extension token, or nothing at all. Read those pages for what each one takes.

If the caller is an AI agent, use MCP instead#

Everything below is written for code you control. If the thing placing the order is Claude, Claude Code, Cursor or anything else that speaks Model Context Protocol, you do not have to translate any of it into tool definitions: X3D runs an MCP server at POST /api/mcp, and the agent asks it what it can do.

The tools cover the same ground as this reference, with one difference that matters: ordering is split in two, so a quote has to exist and be confirmed before anything is charged. Setup for both clients, the full tool list and what each tool costs are at /docs/api/mcp.

What an order costs#

One all-in rate per gram covers filament and normal machine time. There is no setup fee and no separate labour line. Billable weight rounds up to the whole gram, the same way postage does.

material	Rate	Density
pla	$0.12/g	1.26 g/cm³
petg	$0.12/g	1.27 g/cm³
abs	$0.12/g	1.04 g/cm³
asa	$0.14/g	1.07 g/cm³
tpu	$0.25/g	1.24 g/cm³

Send one of these in the material field — it is lowercased before checking, so PLA works too. Anything else is a 400.

quality=premium (0.1mm layers) multiplies the per-gram rate by 1.75. quality=standard (0.2mm) is 1x.
Minimum $1.00 per part, so a 4g trinket costs $1.00, not $0.48.
Twelve stock colours print at the material rate. Any other colour is a $0.20/g floor, because the spool has to be bought in.
Bulk: 5 or more units of the same part take 5% off, 10 or more take 10%.
A sliced .gcode.3mf whose plate uses five or more filaments adds a $25 second-AMS fee, once per order.
US postage is $7 standard, free at $49.50 and above, or $15 express (never free). International is $30 flat, free at $500 and above.
An order whose total works out below $0.50 is rejected — that is the floor our payment processor will take.

Leaving out color is fine

An order with no color field is stored as "Default", which means our choice, and our choice is always a spool we stock, so it prices at the material rate. Before 29 September 2026 it was priced at the $0.20/g custom-colour floor; see /docs/api/changelog.

No Priority print through the API

The website checkout sells Priority print, a $5 option that prints an order ahead of the queue. The print API and the MCP server do not offer it yet: every order placed through them is queued as Normal print. If an API order is urgent, email [email protected] with its code.

Reserving a printer by the hour is a different product with different economics — $1.50/hour or $15/day for the machine plus filament at raw cost — and it is not part of this API. See /docs/farm/reservations.

Order lifecycle#

GET /api/print/orders/{code} returns both a machine value in status and a human string in statusLabel. These are the nine values that exist.

status	statusLabel	What it means
PENDING_PAYMENT	Awaiting payment	The order exists but is not paid. On an API submit this only happens when the card charge failed.
RECEIVED	Received — in review	Paid. Waiting for an operator to accept it.
ACCEPTED	Accepted — queued to print	On a printer's queue, not started.
PRINTING	Printing	On the plate now.
PRINTED	Printed — preparing to ship	Off the plate, being inspected and packed.
SHIPPED	Shipped	Handed to the carrier. tracking is populated.
DELIVERED	Delivered	Carrier reported delivery, read by a daily check, or marked by an operator.
CANCELLED	Cancelled	Stopped before printing.
REJECTED	Rejected	The farm declined the job — usually an unprintable file.

That order is the intended flow, not an enforced one

Nothing in the code validates the transitions. An operator can set any of the eight non-payment values directly, so write your integration to react to the status it reads rather than to assume it only ever moves forward.

Limits and sharp edges#

One file per order, up to 100MB. Accepted: STL, GLB, .gcode and .gcode.3mf. OBJ is not accepted.
quantity is clamped to 1–50 rather than rejected: send 900 and you get 50, send 0 and you get 1.
note is truncated at 1000 characters without complaint.
Order codes are X3D- followed by six uppercase characters, e.g. X3D-K7M2QP. The status lookup is case-sensitive, so a lowercased code returns 404.
A 404 from the status endpoint means either no such code or not your order. The two are deliberately indistinguishable.
Nothing in the application rate-limits these two endpoints today. Do not read that as permission to hammer them — see /docs/api/rate-limits.

Submit your first order

Questions

Do I need approval to get an X3D API key?

No. Sign in, put a card on file at /profile, and press Generate key. There is no waitlist and no application form. Older posts on the X3D blog describe the API as a private beta with keys issued on request — that is out of date.

Can I list all of my API orders in one call?

Not over REST. The REST API has no list endpoint: POST /api/print/orders returns a code such as X3D-K7M2QP, and you read each order back with GET /api/print/orders/{code}, so store the code when you submit. Two other places do list them: the MCP server's list_my_orders tool takes the same key and returns your 20 most recent orders, and the /orders page shows every order on the account, API orders included, when you are signed in.

Is there a sandbox or test mode for the X3D API?

No. Every call to POST /api/print/orders creates a real order, charges the card on your account, and puts work in front of an operator. Test against small parts, not against a fake environment.

Does the API tell me when an order ships?

Your program has to ask. Nothing is pushed to a server, because an order carries no callback URL, so you poll GET /api/print/orders/{code} and watch for status SHIPPED, at which point the tracking object holds the number and carrier. The people on the order are told by email: the shipped email carries the tracking number.