Printify MCP Server

Printify

Print-on-demand platform. Two parallel domains: the global catalog (what you can make) and your shops (what you sell, fulfil, and ship).

Entity Hierarchy

Global Catalog (no shop_id needed)

• Blueprints — product templates (t-shirts, hoodies, mugs, posters, …). Hundreds of items; the list endpoint returns every one in a single response.
• Print Providers — manufacturing partners. Each has a location and a list of decoration_methods (dtg, embroidery, dtf, …).
• Blueprint × Print Provider — the combination that determines what you can actually produce. For each combination Printify exposes:
  • Variants — every (size, color, decoration) option, each with a numeric id and a placeholders array describing the printable positions on the garment (front, back, neck, left_sleeve, right_sleeve …) with width/height in pixels.
  • Shipping profiles — handling time and per-method, per-region cost.

Shop-Scoped (requires shop_id)

• Shops — connected stores (Shopify, Etsy, WooCommerce) or API-only shops with sales_channel = "disconnected". Always list shops first.
• Uploads — image library. Upload by URL or base64; archive to retire. Image ids feed into product print_areas.
• Products — your saved designs. Each product binds one blueprint + print provider, plus the chosen variants (with prices) and the print_areas placing uploaded images at named positions on each variant. Products are draft until published to a connected sales channel.
• Orders — external orders you submit (line items + shipping method + address) or orders the sales channel pushes through Printify. New orders start on-hold; you confirm them by sending to production. Cancellation is status-gated.
• Webhooks — per-shop event subscriptions (order:created, order:shipment:delivered, product:publish:started, …).

Workflows

• Build a product: list shops → pick blueprint → list print providers for that blueprint → pick provider → fetch variants (note variant ids and placeholder positions) → upload artwork → upsert product with variants and print_areas → publish to sales channel.
• Place an external order: list shops → list products (or fetch one) → calculate shipping for the line item + address → create order with shipping_method → send to production. Cancel before send-to-production for the highest success rate.
• Track fulfilment: subscribe a webhook to order:shipment:created and order:shipment:delivered, or poll get_orders filtered by status.
• Manage artwork: upload images, list uploads, archive obsolete ones.

Gotchas

• shop_id is required for products, orders, uploads list-by-shop, and webhooks. Always list shops first.
• blueprint_id + print_provider_id together are required for variants and shipping endpoints — variants belong to a specific provider.
• Image upload by URL fails (HTTP 400 code 10300) when Printify's fetcher cannot reach the URL or the host blocks bots; fall back to base64 contents.
• Publish/unpublish are sales-channel-gated. API-only shops with sales_channel = "disconnected" return HTTP 400 code 8254 on publish; unpublishing a never-published product returns code 8100.
• Order cancel is status-gated — once production picks the order up, cancel returns HTTP 400 code 8501.
• Webhook deletion needs the host of the registered URL as a query parameter; Printify rejects the call without it.