API Explained

Spreadshirt API makes most of the features of our platform available to you via programmable REST interfaces. Spreadshirt API is right now available in version 1 (v1) alpha.

Please note: There is a seperate API for our .net and .com platform:

  • api.spreadshirt.net (Europe)
  • api.spreadshirt.com (North America)

API Features

Today, API v1 provides the following features:

  • Retrieve images for designs, products, product types, print types, etc.,
  • Retrieve data for designs, products, articles, product types, print types, etc.,
  • Design upload and product creation,
  • Design and article search for marketplace,
  • Create baskets and forward to Spreadshirt HTML checkout and
  • Create and retrieve orders 
  • Retrieve order reports

API Technology

API v1 is based on the following technology stack:

  • REST: API v1 is provided as a pure REST (Representational State Transfer) API via HTTP, which means that we use for example HTTP methods, HTTP status codes and URL structures correctly to allow you to retrieve, create, update and delete data.
  • XML, XSD: For exchanging data the API uses XML as data exchanged format. The allowed lists and entities are described using XSD (XML Schema).
  • WADL: Our API is described using WADL (Web Application Description Language). Using WADL we describe which URLs the API provides, which HTTP methods can be used per URL, which HTTP status codes can be expected and what the input and output payload is. WADL can be used like WSDL to generate client code for all kinds of programming languages, such as Java.
  • SVG: We make use of SVG (Scalable Vector Graphics) to describe product types and products, e.g. for describing print areas or design positioning and transformations.

API Parts

API v1 consists right now of three parts as you can see in the picture above:

Existing APIs

API v1 will replace on the long term all APIs that exist right now, be it API v0 (which is used by our T-Shirt-Designer), our old SOAP API (which is used for a couple of integrations and widgets) or partner specific APIs. It should also used by all plugin writers, system integrators and widget developers in the future, that use legacy APIs or RSS feeds in their applications right now.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 06, 2010

    Anonymous says:

    Interesting article.

    Interesting article.