A Secure, API-First Platform for Print Farm Automation

Most print farm software gives you an API as an afterthought — a handful of endpoints bolted on after the fact, with just enough coverage to check a box. Printago is built differently: the same API that powers app.printago.io is the one you build on. Every feature you see in the UI exists because it's backed by an API endpoint. There's no hidden layer, no privileged internal interface.

That matters because it means the API is production-grade by necessity. When we break something, we feel it too.

A Permission Model Built for Real Operations

Print farms aren't single-person operations. You have operators on the floor, a design team managing files, contractors building integrations, and maybe a business partner who needs visibility without access to everything. Giving all of them the same credentials isn't a security strategy — it's a liability.

Printago's permission model reflects how print farms actually work. Five built-in roles cover the most common configurations:

• Store Owner — full access, implicitly bypasses all permission checks

• Admin — manages users, settings, integrations, and day-to-day operations

• Operator — runs printers and manages the queue; read-only access to parts, SKUs, and orders

• Part Manager — full control over parts and SKUs; no access to queue management or operations

• Viewer — read-only across all operational areas

Roles aren't just coarse access levels — they map to granular permissions. An Operator can control printers and manage the queue but can't touch integrations or billing. A Part Manager can manage your entire parts library but can't send a job to a printer. If the built-in roles don't fit, individual permissions can be mixed and matched.

API keys inherit the same permission model. When you create an API key, you scope it to exactly the permissions that integration needs — nothing more. A key built for an order automation script gets order and queue permissions. A key for a read-only dashboard gets view-only access. A contractor building an integration gets a key scoped to what they need for that project, and it's revoked when the project ends.

IP Restrictions as a Defense Layer

Beyond permission scoping, API keys support CIDR-based IP allowlisting. A key can be restricted to specific IP ranges — your server, your office network, a contractor's known IP. Requests from outside the allowlist are rejected regardless of whether the key itself is valid.

This is a meaningful security boundary. Even if a key is exposed, it's only usable from trusted network locations. For production automation running from a fixed server, there's no reason not to lock it down.

One Key Per Integration

The operational principle that makes all of this work: one API key per integration, never shared. An order automation script gets its own key. A monitoring dashboard gets its own key. A developer building a custom tool gets their own key.

The reason is isolation. If one integration starts misbehaving — hammering the rate limit, producing errors — you can identify it, revoke just that key, and leave everything else running. With a shared key, you're debugging in the dark and your only option is to kill all access at once.

Real-Time Events: Two Models

Printago gives you two ways to stay in sync with what's happening on the floor, and they serve different purposes.

Webhooks are for outbound events — Printago pushes to your endpoint when something happens. The event model covers print jobs (starts, succeeds, fails, cancelled), printers (comes online, goes offline, reports an error or warning, Fabmatic disabled), and orders (created manually, created from retail sync, cancelled, closed, auto-printed). You subscribe to exactly the events you care about. For building alerting systems or triggering downstream workflows when a job completes, webhooks are the right tool.

MQTT is for real-time state — telemetry, live printer status, progress updates. But it goes beyond printer events: changes to nearly any entity in the platform are pushed over MQTT as well. When a part is renamed, a SKU configuration is updated, or a material assignment changes, subscribers see those updates in real time — scoped to the permissions of the connected key. Where webhooks are event-driven, MQTT is a persistent connection that streams state as it changes. For anything that needs to react to platform state in real time rather than just at event boundaries, MQTT is the appropriate architectural choice.

Together, they mean your integrations don't need to poll. Polling is inefficient, eats into rate limits, and gives you data that's only as fresh as your poll interval. Push and stream instead.

A Versioned, Documented API

The API is versioned, and Printago maintains backwards compatibility within versions. Integrations you build today won't break because of a platform update.

The live OpenAPI specification is always available for download from the API Keys portal. It's generated from the running platform, not maintained separately — so it's always accurate. If you're building against the API, start with the spec. It's the authoritative source for endpoint behavior, field names, and data types.

For a more browsable reference, the Printago Developer Portal documents every endpoint with its required permissions, request and response schemas, and full parameter detail. Like the spec, it's auto-generated from the live platform, so it stays current as the API evolves.

Built for the Age of AI Agents

Structured APIs, consistent conventions, and comprehensive documentation aren't just good engineering practice — they're what makes a platform usable by AI agents. Printago is designed with this in mind. The API's structure and the OpenAPI spec are oriented toward machine consumption as much as human consumption.

For developers who want to take this further, Printago publishes a Claude skill for Claude Code that lets you manage your print farm through natural language — query queue status, manage parts, fulfill orders, generate reports. It's an example of what's possible when the underlying API is built to be consumed programmatically, and a practical tool for operators who want to work faster without writing custom scripts. As AI becomes more capable, we're looking to invest even further in an AI agent's ability to effectively navigate the platform.

The Practical Upshot

A well-designed API platform for a print farm isn't just about what you can automate today. It's about whether the foundation is trustworthy enough to build on for the long term — whether the access controls are granular enough to give different people different levels of trust, whether the event model is efficient enough to scale, whether the documentation is reliable enough to build against with confidence.

That's what we built. The UI is just one way to use it.