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 with a key. The key-authenticated API has no list endpoint: POST /api/print/orders returns a code such as X3D-K7M2QP, and that code is the only handle on the order — store it when you submit, then read GET /api/print/orders/{code}.

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?

Only if you ask. Nothing is pushed to you — 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.

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.

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. A key cannot list your orders, there is no sandbox, nothing is pushed back to you, and an order cannot be cancelled or edited once it is in. 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.

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.
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.

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.13/g	1.21 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%.
US postage is $7 flat, free at $50 and above. 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.

Send a colour, even the obvious one

If you omit the color field the order is stored as "Default", which is not one of the twelve stock spool names, so it prices at the $0.20/g custom-colour floor. Sending color=Black is cheaper than sending nothing.

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.
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