Integrating Skublox API – General

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/lightwallSwagger

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/tokenSwagger

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.

Was this article helpful?