Two ways to send orders to Fabrixa: connect the store you already run — Shopify or WooCommerce — with no code, or build directly on the Integration API. This guide covers both: connect a sales channel in minutes, or go from auth to fulfilment in fifteen.
Most stores never touch the API. Add Fabrixa as a sales channel and orders from your shop flow straight into production — products synced, statuses pushed back, no code to write or maintain. The API route further down is for custom storefronts and POD platforms.
In your dashboard, open Create channel and choose your integration type. Each channel keeps its own products, imported orders and import rules — connect as many as you run.
No keys to copy. Authorise Fabrixa from your Shopify admin and the connection is live.
Create channel, choose Shopify.A WordPress shop connects with a read/write REST key pair — generated in WooCommerce, pasted into Fabrixa once.
Settings → Advanced → REST API → Add key with Read/Write permissions.ck_ key, cs_ secret and your store domain into Fabrixa.Selling customised products? Fabrixa Studio — the white-label design editor — is available on Shopify and WooCommerce stores too, so your shoppers personalise products under your brand. See Fabrixa Studio →
Connected stores sit next to your API and partner channels in the Channels view — synced products, received orders, the last imported reference and revenue per channel. Flip a channel from draft to live when you’re ready; nothing downstream changes.
Building a custom storefront or your own POD platform instead? The rest of this guide is the API route — auth to fulfilment in four steps.
Three things get you from zero to a live order. All of them are issued from your Fabrixa dashboard or by your solutions engineer.
An Application Access Token and an Application Key. Both are required on every request — the token in the Authorization header, the key in X-Application-Key. Create a sales channel in your dashboard to generate them instantly — no request needed.
A publicly-reachable HTTPS endpoint that accepts JSON POST requests. Localhost works in development via a tunnel. You verify the HMAC-SHA256 signature on every payload before processing.
Your artwork file — PDF, TIFF, JPG or PNG — reachable over HTTPS without authentication. RGB colour, up to 50 MB and 15,000 px per side. Multi-page PDFs are one page per layer. We fetch the file and build the correct print files when we render the job.
Every request goes to the base URL https://api.fabrixa.com/v2/integration with both headers set. GET /ping confirms the token and key are valid before you do anything else.
A 401 means a header is missing or the token has been revoked. A 403 means the credentials are valid but lack permission for the resource.
# Verify auth before anything else curl https://api.fabrixa.com/v2/integration/ping \ -H "Accept: application/json" \ -H "Authorization: Bearer APPLICATION_ACCESS_TOKEN" \ -H "X-Application-Key: APPLICATION_KEY" # 200 OK → credentials valid # 401 → missing header or revoked token # 403 → valid, but no access to the resource
The catalogue returns product variants with their SKU and variant_id. Every list response is wrapped in the standard links / meta / data envelope, so paginate with the next_page link. Cache locally — the catalogue isn’t per-request.
Full field detail is in the Swagger reference.
GET /v2/integration/products?page=1
{
"links": {
"self": ".../products?page=1",
"next_page": ".../products?page=2",
"prev_page": null
},
"meta": { "total": 248, "current_page": 1, "per_page": 10 },
"data": [
{ "id": 1306, "name": "Unisex AOP T-shirt", "SKU": "COF099191" }
]
}
Send rows (SKU + quantity + a source PDF), customer and shipping_address. Set your own number as the reference — omit it and we generate one. Store the returned Fabrixa order id against your order.
Studio orders swap sources for a cart_item_key — everything else is identical.
POST /v2/integration/orders
{
"number": "ORD-2026-0142",
"purchased_at": "2026-05-28 14:22:01",
"rows": [
{
"sku": "COF099191",
"quantity": 1,
"sources": [
{ "type": "file", "url": "https://cdn.you.com/art/9812.pdf" }
]
}
],
"customer": {
"first_name": "Maria", "last_name": "Silva",
"email": "maria@example.com", "phone": "+351912345678"
},
"shipping_address": {
"address": "Rua do Carmo 42", "city": "Lisboa",
"postal_code": "1200-094",
"country_code": "PT", "country": "Portugal"
}
}
Set your webhook URL in the dashboard. We POST order.created and order.updated to it with the full order body, an x-webhook-signature (HMAC-SHA256) and an x-webhook-topic header. Verify the signature, return 200 fast, process asynchronously.
Every event and the verification snippets are on the webhooks reference.
# Request headers content-type: application/json x-webhook-topic: order.updated x-webhook-signature: YmEwNjBhMGMy...AxMw== # Body (truncated) { "id": 23069, "number": "1250211835", "status": "imported", "fulfillment_status": "unfulfilled", "updated_at": "2026-05-28T07:43:52Z" }
Errors come back as JSON, never HTML. The errors.messages array names what failed; on a 400 it lists the fields that didn’t validate.
Validation error, missing or revoked credentials, insufficient permission, or unknown resource.
30 requests per application per minute. X-RateLimit-Limit and X-RateLimit-Remaining are on every response.
Server-side. Retry with back-off; if it persists, send the request id to your solutions engineer.
{
"links": { "self": ".../v2/integration/orders" },
"meta": [],
"errors": {
"messages": [
"Application Key is not specified."
]
}
}
For integration support, credential or sales-channel issues, custom requirements or capacity planning — the technical SE channel, not the sales line. Response inside one business day.
