Reference · v1
One bearer token, JSON in and JSON out, and the same store your dashboard is looking at. Orders, line items, shipments, inventory, and folder moves — there is no dashboard-only surface.
https://api.printexchange.io/api/v1/
Bearer pxk_9f3c1d8a4b…
GET /api/v1/test
Create an account and PrintExchange shows you a store ID and an API key once. The key is a bearer token; put it on every request.
Request
$ curl https://api.printexchange.io/api/v1/orders/26070814324201607 \ -H 'Authorization: Bearer pxk_9f3c1d8a4b'
Response
{
"status": "success",
"execution_time": "0.0104 seconds",
"order": {
"id": "26070814324201607",
"source_name": "Shopify",
"source_id": "5512-A",
"email": "[email protected]",
"order_total": 30.29,
"folder_id": 2,
"shipments": []
}
}
| Scheme | Headers |
|---|---|
| Bearer | Authorization: Bearer pxk_9f3c1d8a4b… |
| Store key | PRINTEXCHANGE-STORE-ID: 1000 · PRINTEXCHANGE-API-KEY: pxk_… |
Every response carries x-tokens-remaining and x-retry-after. Read them rather than guessing: x-retry-after tells you how long to wait before the next call when you are out of tokens.
/api/v1.Line items and shipments are nested under the order that owns them. Three batch endpoints exist for the work you do a hundred rows at a time.
| Methods | Endpoint |
|---|---|
| GET | /api/v1/test |
| GET | /api/v1/store |
| Methods | Endpoint |
|---|---|
| GET · POST | /api/v1/orders |
| GET · PUT · DELETE | /api/v1/orders/{id} |
| POST | /api/v1/orders/{id}/order-history |
| POST | /api/v1/move-orders |
| Methods | Endpoint |
|---|---|
| GET · POST | /api/v1/orders/{id}/order-items |
| GET · PUT · DELETE | /api/v1/orders/{id}/order-items/{itemId} |
| GET · POST | /api/v1/orders/{id}/shipments |
| GET · PUT · DELETE | /api/v1/orders/{id}/shipments/{shipmentId} |
| POST | /api/v1/batch-shipments |
| Methods | Endpoint |
|---|---|
| GET · POST | /api/v1/inventory-items |
| GET · PUT · DELETE | /api/v1/inventory-items/{id} |
| PUT | /api/v1/batch-inventory-items |
Folders are the production workflow: New, Prepared, Closed, Canceled. An order sits in exactly one of them, named by its integer folder_id. POST /move-orders refiles a set of orders in a single call.
status first, every time.Success and failure share one shape. A single response is keyed by its resource; a list adds its counters and puts the collection under a key named for the resource.
Single resource
{
"status": "success",
"execution_time": "0.0104 seconds",
"order": { … }
}
List
{
"status": "success",
"execution_time": "0.0212 seconds",
"total_records": 1284,
"records_returned": 50,
"offset": 0,
"limit": 50,
"orders": [ … ]
}
Error
{
"status": "error",
"message": "Order 26070814324201607 Could Not Be Found",
"execution_time": "0.0304 seconds"
}
There is no errors array. A failure is one message string; render it or log it, but do not iterate it. The collection key follows the resource: orders, shipments, inventory_items.
Order, line item, and shipment ids arrive quoted — "26070814324201607", never a bare JSON integer. They exceed Number.MAX_SAFE_INTEGER, so a JavaScript parser would silently round the last digits away. Keep them as strings end to end.
folder_id is an integerNot a string, not a folder name. It is the one field that says where an order is in the workflow, and it is the field POST /move-orders writes.
An order total comes back as 30.29, not "30.29" and not 3029. Weights are decimals too.
POST /orders is not an upsertPost the same source_id twice and the second call fails with HTTP 400 and an existing_order_id in the body. Read that id and issue a PUT if you meant to update.
GET /test.Your raw API key is shown exactly once, on the screen right after you create your account. Put it in your secret manager before you navigate away.
On the roadmap Print jobs on a line item, and endpoints for routing them to a print partner. Not built yet, and not in v1 — when they land they will be additive.