Home / Docs / Developers
Developers

Sub-accounts (platform embedding)

If you're building a product that needs to print to your customers' label printers — an order tool, a warehouse app, a POS — sub-accounts let each customer run their own Print Bridge in an isolated workspace, while every print bills to your account. One integration, many tenants.

How it fits together

Create a sub-account

Idempotent on your own tenant id, so you can call it on every provision without duplicating:

POST /api/v1/subaccounts
Authorization: Bearer pr_live_<management key>

{ "name": "Acme Coffee Co", "external_id": "tenant_8213" }
→ 201 { "id": "…", "name": "Acme Coffee Co", "external_id": "tenant_8213", "created": true }

Connect their Print Bridge

Mint a print key scoped to that child (returned once), or hand them a pairing code for the Bridge:

POST /api/v1/subaccounts/:id/keys      → { "key": "pr_live_…" }   // scopes: print, read
POST /api/v1/subaccounts/:id/pair-code → { "code": "…", "expires_in_seconds": 1800 }

The child's own key prints to the child workspace as usual. Your management key can also print directly into any child by passing subaccount_id:

POST /api/v1/print
{ "subaccount_id": "…", "printer": "Zebra ZD421", "template": "Shipping 4x6", "data": { … } }

Templates resolve in the child first, then fall back to your parent library — so you can publish shared designs once and print them for every tenant.

Manage & report

GET /api/v1/subaccounts lists children with 30-day print counts; GET /api/v1/subaccounts/:id/usage returns a per-child usage summary for your own invoicing; DELETE /api/v1/subaccounts/:id removes one. The console's Sub-accounts tab does all of this by hand too.

One level of nesting (a child can't have its own children), and children share your plan — sub-accounts are about isolation and billing rollup, not reselling separate plans. Full request/response shapes are in the OpenAPI spec.