## Purpose of API

The purpose of the Skublox API is to provide a programmatic way of managing SellerCloud & Skublox entities, and processes.

SellerCloud entities include **orders, products, picklists, employees** ( **users** of Employee type), **warehouses**, and **web app settings** (be it global or client-specific).

Skublox-specific entities include **walls, sort boxes** (also known as **slots**), **items** in sort boxes, and **user sessions**.

Skublox processes include **creating** and **configuring a wall, acquiring a sorter (worker) session, scanning barcodes** (and **confirming/cancelling** them), **swapping slots,** and checking for **product suggestions**.

## Endpoints & Routes

Skublox was developed with the code name **Lightwall**.

This is the reason why the API is hosted with a base route **<SERVER>.api.sellercloud.com/lightwall** on each Sellercloud server. Auto-generated Swagger documentation and “playground” can be accessed at **/lightwall/swagger**.

_Example:_ **TT** server → **https://tt.api.sellercloud.com/lightwall** → [Swagger](https://tt.api.sellercloud.com/lightwall/swagger)

SSL/TLS is required.

## Authentication

A common RESTful practice, the user token must be included with each Skublox API request as an HTTP header named **Authorization** with value **Bearer <token>**

The Skublox API does not expose authentication endpoints. Operations such as **acquiring and refreshing tokens** are handled by the Token API hosted on each Sellercloud server.

_Example:_ **TT** server → **https://tt.api.sellercloud.com/token** → [Swagger](https://tt.api.sellercloud.com/token/swagger)

Tokens are not interchangeable between servers (even if a user has the same email/password/credentials on both servers).

## Sending Requests

The body of an HTTP request (where applicable) is expected in **JSON** format.

## Handling Responses

When returned, the body of an HTTP response is encoded in **JSON** format.

Exceptions include endpoints which return **file attachments** for easy integration. Such endpoints include **/products/image/{id}** and **/products/thumbnail/{id}** so that product images can be sourced easily, without processing any JSON/Base64-encoded data.

Common HTTP response codes include:

- **200 OK** – GET requests will always return a body. **PATCH** and **DELETE** endpoints may not return body. Consult with the Swagger documentation.
- **400 Bad Request** – Invalid structure of the request. likely caused by missing required query parameters or JSON body key. Consult with the Swagger documentation.
- **404 Not Found** – Requested entity not found in the context of the authenticated client. e.g. the product with the given SKU does not exist (or exists for another client hosted in the same database).
- **409 Conflict** – Valid structure of the request but inapplicable in the given context.
- **5XX Internal Server Error** – Unhandled error on server side. Response body will contain more information about the exception encountered.