The print API is becoming more important than the print shop website

For years, if you wanted to sell print online, you started with the website. You built a catalogue, added the options for size, stock, finishing and quantity, worked out the pricing, gave people a way to upload artwork and got them through a checkout. I spent years doing exactly that, and none of it is going away. People still need good websites.

I'm increasingly convinced the website might be the least interesting part of the problem. The next thing trying to understand what you can produce often isn't a person at all. It's another ecommerce platform, a procurement system, an MIS, a design tool, or increasingly an AI agent buying on someone's behalf. A person can land on a printer's site, read a few slightly messy pages and still make a good guess about what's on offer. They'll work out that business cards, leaflets and brochures probably means commercial digital print, they'll interpret "premium stock", they'll notice that a particular finish isn't offered on every product, and if they're still unsure they'll pick up the phone. Software makes none of those leaps unless you hand it the information in a form it can actually use.

And print carries a lot of information to understand. Someone asks for 500 nice flyers for an event next week, and a good print salesperson immediately starts filling in the gaps. What size? Single or double sided? What does nice mean here, coated or uncoated, something disposable or something that needs to feel substantial? Is the artwork ready? Where's the event, and does next week include delivery or just production? Are there finishing requirements the customer hasn't thought to mention? The flyer they end up with might be completely ordinary. Getting from that one sentence to an accurate production requirement is not.

The print API thought its moment had arrived. Then MCP turned up.

Print APIs aren't new, and recent announcements have made the direction hard to ignore. Where The Trade Buys launched its Print API, giving ecommerce businesses automated access to more than 140 print products, with order and artwork data flowing into production and finished work dispatched in white-label packaging, so resellers can broaden what they sell without investing in more kit and while keeping their own website, branding and customer relationships.

More recently, Print.com went live inside ChatGPT, letting someone browse the catalogue, price a job and check delivery times in conversation before being handed a link to finish the order on Print.com's own site.

Both are worth paying attention to, and they're doing slightly different things. WTTB has taken a catalogue and made it callable, which is genuinely useful plumbing. Print.com has gone a step further and, in the words of its AI lead Daan de Jong, "made billions of possible specifications readable for AI". That second sentence is the one I'd pin to the wall, because it describes a different kind of asset from a product list with an API bolted on.

There's something slightly amusing about the timing too. The print API has spent years looking like the obvious destination for all this work, and just as it starts having its moment, MCP turns up and changes how software might actually consume it. It doesn't make the API obsolete. It makes the question of what the API actually means much harder to avoid.

Then there's the problem sitting underneath all of it. If I connect to 5 print producers, how do I know that the product one of them calls a flyer is the same thing another calls a leaflet, and that a third hasn't described the identical job purely as dimensions, substrate and process with no familiar name at all? Quite often they don't line up. A stock might be available at one size and not another. A finish might depend on the production method. Quantity can change the sensible process. Geography and lead times matter. An API gives software access to the information. It doesn't give that information a shared meaning, and that gap is the part that's going to bite.

The customer, increasingly, is software

This isn't really a print story. Commerce as a whole is building interfaces meant for software acting on a buyer's behalf. OpenAI's Instant Checkout, and the Agentic Commerce Protocol behind it, let an agent create and complete a checkout with a merchant while the merchant keeps responsibility for pricing, inventory, payment and fulfilment. It's telling that when Print.com connected to ChatGPT it did so through an open standard, the Model Context Protocol, rather than a single proprietary checkout, and that you still complete the order on Print.com's own site rather than inside the chat.

That ordering is the part I'd hold onto. An agent being able to place an order doesn't mean it knows what to order. Before anything reaches a checkout, someone or something has to turn a rough intent into an accurate production requirement and work out who can actually make it. Placing the order is close to solved. Working out what the order should even be is the bit print keeps underestimating.

A catalogue and a capability model are not the same thing

None of this is new to me. I saw the potential back in 2013 when I joined Printed.com. Building a catalogue API was never the goal, and neither was a pile of SKUs bolted onto a system we called F-codes (make what you like of that). What I wanted was a system that could take whatever bespoke requirement came along and turn it into something the factory could actually produce. The difficulty with something like that was never the software. The factory had to be willing to make it, the commercial team willing to price it, and sales and marketing willing to sell it... which inevitably fell back to me to design a website to support anyway. We built it. We just never properly released it. So it's oddly satisfying to watch the industry work out, more than a decade on, how much this matters.

That's why I've become far more interested in the idea of a digital capability model than another digital catalogue. A catalogue tells you what a business has chosen to sell. A capability model tells software what a business can actually produce, under which constraints, using which processes and materials. The two overlap, but they answer different questions.

Once that information has a controlled, shared meaning, the same description can feed a lot of things. A website can consume it. So can an ecommerce platform, a procurement system, another printer looking for capability it doesn't have in-house, and eventually an agent shopping on a customer's behalf. It's worth keeping the questions separate while you build it, because they get muddled constantly. "Can you make this?" is not the same question as "can you make this for £420, deliver it to Chicago by Thursday and take the order now?" Capability, price, availability and order acceptance are related, but treating them as one thing is how a system becomes impossible to reason about.

And my team and I haven't left the problem sitting there either. We're working on it again now because we think the industry needs a shared way for software to understand print requirements and production capability, looking at it directly from the same problem: how do you turn what someone wants into a controlled print requirement, describe what producers can actually make in a comparable way, and let software reason across the two without pretending capability, live price, availability and order acceptance are all the same thing?

We're not pretending with Gnaww that we've solved the whole thing. There are some quite deliberate boundaries in what we're building, particularly between understanding whether something can be produced and knowing its live price, availability or whether a producer will accept the order. But we're trying to make that first part properly useful, open it up through APIs and other software interfaces, and work with the industry rather than build another closed catalogue that only makes sense inside our own system.

Seeing WTTB and Print.com moving different parts of the same problem forward is encouraging. There should be more of this. It's too big, and too fundamental to how print will be bought by software, for any one company to sensibly own the answer.

The website isn't going anywhere

None of this means print websites are disappearing. If anything the human experience should get better as the description underneath it becomes richer and more reliable. But we're reaching the point where designing the website and designing the machine interface deserve similar care. For years the website was the digital representation of a print business. It's turning into one consumer of a much fuller representation sitting behind it.

So if you run a print business, the question worth sitting with isn't whether to build an API. It's whether anything, a person or a piece of software, could read how you describe your work today and come away knowing what you can actually make, rather than only what happens to be on the price list.

Where The Trade Buys and Print.com have both answered a version of that question with real products recently. My team and I are working on another part of it. Hopefully plenty of others are too.

If software is going to find, understand and eventually buy print on our behalf, giving it a checkout button was never going to be enough. First it has to understand what we can make.