What you're seeing right here is a real store with real products, real mock-ups, and a checkout that anybody can open and buy from right now. And here's the part that matters: I didn't design any of it. I never opened Photoshop, never uploaded an image file, and never clicked publish. All I did was write four lines of text into a markdown file, hand Claude Code an API key, and let it run.
Most agentic systems end in a file. This one ends in a checkout. Behind that checkout is a real facility that prints a real shirt and mails it to somebody. And what makes that possible is Printify.
Most people know Printify as a print-on-demand site where you upload a design and put it on a t-shirt. But underneath that interface is a REST API that lets your code create products, position artwork on a garment, publish to a storefront, and submit real orders. If you can write to an API, you can hand the entire thing to an agent.
So here's the full setup: a store, a Claude Code skill that knows the Printify API, and a loop that publishes everything on its own.
How Printify works under the hood
Nothing the agent does later makes sense without understanding Printify's structure. There are four layers, and the agent has to navigate each one correctly.
A blueprint is the theoretical product. It's a t-shirt or a mug before anyone picks a manufacturer or a color. It's just the idea of the thing.
A print provider is the actual facility that does the printing. Printify routes to over a hundred of them. That means the same shirt can be printed by five different companies at five different base costs. The agent has to decide which one to use.
A variant is the specific version from a specific provider. It's the large black shirt from that particular facility. Variant IDs belong to the provider, and this is where beginners trip up. Grab a variant ID from one provider and try to use it with another, and the API just rejects it. Every layer has its own endpoint though, so the agent can query its way down instead of guessing. That's why this whole approach works at all.
A product is the final thing that shows up in your shop. It wraps all of those layers together with your artwork mapped onto it using coordinates.
Setting up the store and the API
Head over to printify.com and create an account. It's free to sign up and free to create products. You only pay when something actually gets produced. No upfront costs.
Now you need somewhere for those products to live. Printify connects to Shopify, Etsy, and others, but for this project I used the pop-up store, which is Printify's own hosted storefront. I didn't want to manage a front end. Give it a name, and now you have a shop ID that every API call is going to need.
Then go to account settings, find the API section, and generate a personal access token. This is the part people rush, and that's where things break. You have to give it scopes. For a full loop, you need six:
- shops.read
- catalog.read
- products.write
- uploads.write
- orders.write
- webhooks.write
Check all six. If you miss one, the loop runs fine right up until it hits that endpoint, and then it dies on a permissions error. Copy the token into a .env file, and that file goes straight into Git ignore.
Picking an idea that reads like a brand
Most print-on-demand stores throw 50 random designs at the wall, and that doesn't look like a brand. It looks like a spam page. I picked one idea instead: agents that keep building on their own. That's what this channel is about, so the products all speak the same language.
Four lines of text, each going on a different product:
- builds.itself, the hero line, big across the chest on the main t-shirt
- bots.plan, on a hoodie
- agentic.loop, on a mug
- AI for builders, on a sleeve
Here's what made the design step work without me touching it. All four are pure typography. Just words and layout. I didn't need an image model at all. Claude Code writes the design directly as an SVG, which is just a text file describing shapes and positions. The agent isn't rolling the dice on an image generator. It's writing a design I can open and read. If the letter spacing is off, I tell it to change the letter spacing, and it changes one number. Then we render that SVG to a PNG at 300 DPI with a transparent background. That's what direct-to-garment printing wants.
Building the skill that knows the API
Now we build the thing that knows how to do all of this, and it's a Claude Code skill. Same pattern I've used before. Create skills/printify and inside it a skill.md file. Everything I just explained goes in there, but written as instructions for the agent instead of for a human.
Four things the skill needs to know:
First, auth. Bearer token from the environment, HTTPS only, and never log it. This is non-negotiable.
Second, the catalog rules. Query the blueprints, get the providers, get the variants from that specific provider, and never mix variant IDs across providers. If the agent does, the API rejects it and the loop stops.
Third, uploads. The endpoint takes a public image URL or a base64 file. I tell the agent to always prefer the URL. Base64 bloats the payload by about a third, and you start risking a 413 "too large" error. You get back an image ID that gets referenced later.
Fourth, the print areas. This is the dense part. We're not just saying "put this image on this shirt." We're saying "place image A at this X, this Y, this scale, this angle." Those coordinates are normalized against the bounding box a manufacturer defines. They are not pixels. So I wrote the common placements in as named positions: a chest, a sleeve, a neck label. The agent picks one by name instead of doing the math every time. That's what took this from flaky to reliable.
The only file I write by hand
Now we tell the agent what to build. This is products.md, and it's just a table. One row per product with the brand line, the blueprint, the placement, and the colors.
builds.itself → Bella Canvas 3001T → chest → black, white
bots.plan → hoodie → chest
agentic.loop → mug → wrap
AI for builders → sleeve
I just keep adding rows. That's the entire interface. No code, no design files, no product IDs.
The loop that runs everything
The loop is the same shape as every loop I've built here. It reads the manifest, takes the first row that isn't done, and runs the sequence:
- Write the SVG
- Render the PNG
- Upload it and get an image ID back
- Query the catalog (blueprints, providers, variants)
- Pick a provider
- Pull the variants in every size
- Post the product
- Make a second call to publish it, because the created product just sits there as a draft until you do
- Mark that row as done
- Move on to the next row
It goes one row at a time because Printify caps publishing at 200 per 30 minutes. And this way, if row three fails, rows one and two are already live. Nothing rolls back, nothing gets stuck.
The run
I start a Claude Code session and all I say is: "Read products.md and build every product that isn't done yet using the Printify skill." That's the whole prompt. From here, I'm not touching anything.
It reads the manifest, picks up row one, and starts writing the SVG. And this is the part I actually like. I can open that file while it's still working and read exactly what it decided. It went with a heavy condensed weight, stacked the two words, and tightened the second line so both lines end at the same width. That's a real design decision sitting in plain text where I can go change it if I want.
Then it renders the PNG, uploads it, gets an image ID back, and hits the catalog. It looks up the blueprint, picks a provider, pulls variants in every size, and posts the product. If I flip to the dashboard and refresh, there's the product. Printify already generated the mock-ups: front, back, folded, on a model. I made none of those.
Then it publishes and moves on to row two.
Notice this isn't a script with product IDs hard-coded in it. It re-queries the catalog on every run, so it always picks up the current reality instead of failing on stale IDs. That matters when providers change or variants get removed.
The store is already live
The products are published, which means the pop-up store is live immediately. A real storefront, actual mock-ups, and anyone can add items to a cart and check out right now. You can point your own domain at it too. Printify gives you the DNS records right in the dashboard.
I'd plug in Google Analytics here. Once there's traffic, I can see whether "Bots Plan" converts better than "Agentic Loop," and then go add rows for whatever's winning. The analytics becomes the input for the next run of the loop.
Let's talk about the money
I want to be straight about this because I don't like videos that skip the numbers.
The account is free. Creating products is free. Publishing is free. The pop-up store is free. Everything I just showed you costs nothing upfront.
What you pay is the base cost of the product, and only when an order is actually placed. That cost comes out of what the customer already paid. So there's no inventory sitting in a warehouse. That's the real reason this works as an agent project: the agent can publish 30 ideas, and if 28 never sell, they cost you nothing. You don't lose money on bad designs.
There is a paid tier, Printify Premium, which runs about $29 to $39 a month for up to 33% off base costs. It's just arithmetic: the breakeven is around 14 to 20 sales a month. If you're moving more than that, premium pays for itself. If you're not, you stay on the free tier and nothing changes.
When somebody does buy, the pop-up store handles the entire transaction. The order goes to production automatically. You don't fulfill anything.
Who this is actually for
There are two groups.
If you're a creator who wants merch and keeps putting it off because it means designing stuff and managing a store, this turns the whole thing into a table you edit. Add a row, run the loop, and the product exists. That's it.
But the bigger one for me is this: if you've been building agentic systems that never leave your terminal, this is a good first project for pushing a loop out into the real world. The API is clean and the failure modes are cheap. If the agent publishes a broken product, you delete it. That's the whole consequence. You're not dealing with payments infrastructure or shipping logistics. Printify handles all of that.
The thing that surprised me wasn't the automation part. It was how little of this needed a human. I assumed the design step was going to be the wall. That's the part where most people stop. But once the design is text instead of pixels, it stops being an art problem and starts being a code problem. And code is what these agents are already good at. An SVG is just a text file. Letter spacing is just a number. Alignment is just coordinates. The agent can iterate on that the same way it iterates on a function.
There's a lot more in Printify than what I covered here: over 1,300 product types and more than 100 print providers. The catalog is huge, and the API gives you access to all of it.
Points clés à retenir
- Printify exposes a full REST API behind its print-on-demand front end, which means an agent can create products, position artwork, publish to a storefront, and submit orders without a human touching the dashboard.
- The four-layer structure (blueprint, provider, variant, product) means the agent must query its way down instead of guessing. Variant IDs belong to a specific provider, and mixing them across providers breaks the API call.
- Set all six API scopes at token creation time: shops.read, catalog.read, products.write, uploads.write, orders.write, and webhooks.write. Missing one causes a permissions error mid-loop.
- Typography-only designs written as SVGs remove the need for an image model. The agent writes a text file describing shapes and positions, renders to PNG at 300 DPI, and you can read and edit the design at any point.
- The products manifest is a simple table in markdown. One row per product, with the brand line, blueprint, placement, and colors. That's the entire human interface.
- The loop processes rows one at a time, re-queries the catalog on every run to avoid stale IDs, and publishes each product with a second API call since created products sit as drafts by default.
- Everything is free until an order is placed. Base costs come out of the customer's payment, and unsold products cost nothing. That makes it a safe sandbox for agentic projects that push beyond the terminal.