Developer platform

One print-order API.
Every provider behind it.

Batch Relay validates prepared assets, resolves one compatible provider, and freezes the route before payment or fulfillment. Build against a single contract instead of one lab's SDK.

Read the quickstart Open the dashboard

Batch Relayprint-order API

HTTP APILive
any HTTP client
DashboardLive
keys · orders · billing
n8nComing soon
multi-step workflows
ZapierComing soon
trigger-based automations
WebhooksPlanned
push order status

OpenAPI 3.1 spec

The full contract is machine-readable at api.batchrelay.com/openapi.json — generate a client in any language.

Idempotent by default

Every submission carries an Idempotency-Key. Retries are safe, and reuse with a changed payload is rejected.

Staging first

br_test_ keys run the same quote-and-submit flow against sandbox fulfillment before anything goes live.

The order lifecycle

Compatibility, quote, freeze, submit.

Four requests take an order from prepared assets to fulfillment. The route is frozen before any payment, so nothing changes underneath you.

01
Create a scoped key
Generate a staging key in the dashboard with print_orders:write and print_orders:read. Staging and production are separate key environments.
Authentication
02
Check compatibility
POST /v1/providers/compatibility confirms a provider can produce every line item before you commit to anything.
Provider routing
03
Quote and freeze the route
Quoting resolves one compatible provider and locks provider and pricing for 15 minutes. What you show the customer is what fulfills.
Provider routing
04
Submit with an Idempotency-Key
POST /v1/print-orders against the frozen quote. Retries are safe; reusing a key with a different payload returns 409 idempotency_conflict.
Idempotency

From the terminal

A print order in one request.

Authenticate with a bearer key, pass an idempotency key, and submit against your frozen quote. Every error comes back structured — a stable code, a docs_url, and a request_id you can hand to support.

Full request and response shapes in the API reference

curl https://api.batchrelay.com/v1/print-orders \
  -H "Authorization: Bearer br_test_••••" \
  -H "Idempotency-Key: event-2481-order-114" \
  -H "Content-Type: application/json" \
  -d '{ "quote_id": "…", "order": { … } }'

# 202 Accepted → payment_pending → paid
# → fulfillment_submitted → accepted → shipped

Ways to connect

Use the API directly, or wait for the wrapper.

HTTP API

Live

The production path used by Batch Relay's own surfaces. Provider-neutral catalog, quoting, and order submission from any language.

Quickstart

n8n node

Coming soon · in pilot

Prepare, quote, and submit print orders from multi-step n8n workflows. The node calls the Batch Relay API — provider credentials never enter your workflow.

n8n docs

Zapier

Coming soon · in pilot

A planned Zapier Platform app for trigger-based automations, built on the same API boundary as everything else.

Zapier docs

Webhooks

Planned

Push order and fulfillment status changes to your systems. Until they ship, poll order state with GET /v1/print-orders/{id}.

Webhooks docs

Looking for lab availability instead? See current integration status for WHCC, Richmond Pro Lab, and the pilots.

Safe to call

Boring where it counts.

Real orders and real money move through this API, so the failure modes are designed to be dull. The full architecture is documented on the trust page.

Trust & security Authentication docs

Keys are hashed, not stored
Raw API keys are never persisted — only a one-way hash. If a key leaks, revoke it in the dashboard and rotate.
Idempotency is enforced
Reusing an Idempotency-Key with a different payload is rejected with a 409. A retry never becomes a duplicate order.
Provider credentials stay server-side
Automations authenticate to Batch Relay, and Batch Relay talks to the labs. Lab credentials never enter your code.
Staging is a separate environment
br_test_ keys can only create sandbox orders, and production keys can't touch sandbox. A mixed-up key fails closed.

Documentation