Build Your Integration with an AI Assistant

You can let an AI coding assistant such as Claude Code, Cursor, GitHub Copilot or ChatGPT write most of your Shirtigo integration. To do that well, the assistant needs the API documentation in a form it can read. We provide it as plain Markdown:

File	Use it for
llms.txt	Short overview: authentication, the two order workflows, links and a list of all endpoints
llms-full.txt	Everything in one file: the guides, every endpoint with its parameters and the data models
swagger.json	OpenAPI (Swagger 2.0) specification for client generators

Assistants that can browse the web fetch these files themselves when you give them the address. Otherwise download llms-full.txt and attach it or add it to your project.

Prompt to get started

Copy the prompt below into your assistant and replace the part in brackets with what you want to build. It tells the assistant where the documentation is and which rules matter most.

I want to integrate the Shirtigo Cockpit API (print-on-demand and fulfillment) into my system.

Goal: [describe what you want to build, e.g. "forward new orders from my shop
system to Shirtigo and write the tracking number back"]

Before writing any code, read the documentation:
- Overview: https://cockpit.shirtigo.com/docs/llms.txt
- Full reference: https://cockpit.shirtigo.com/docs/llms-full.txt
If you cannot open URLs, tell me and I will provide the files.

Rules for the integration:
- Base URL https://cockpit.shirtigo.com/api, header "Authorization: Bearer <key>"
  and "Accept: application/json". Read the API key from configuration or an
  environment variable, never hard-code it.
- Decide with me which order workflow fits:
  A) everything in one call: POST /orders with base_product_sku and processings
     (design URL, print area, size in millimetres), or
  B) create products first (POST /customized-product) and order them by SKU.
- Send a unique external_reference with every order so that retries never
  create duplicate orders.
- Handle 422 validation errors by reading the error details in the response.
- Prefer webhooks (POST /webhooks) over polling for status updates.
- There is no sandbox. While testing, create orders with "is_onhold": true and
  use an account with prepayment, so nothing is produced or charged. Cancel
  test orders with POST /orders/{reference}/cancel.

Only use endpoints and fields that exist in the documentation. If something is
unclear, ask me instead of guessing.

Tips

• Start with one workflow. Let the assistant build and test a single order end to end before adding webhooks, stock information or branding.
• Check prices first. POST /orders/predict-price accepts the same body as POST /orders and returns the price without placing an order.
• Keep the documentation current. If your assistant stores the files in your project, download them again after API updates. The files are regenerated with every documentation release.