1. Home
  2. Knowledge Base
  3. Skublox API
  4. General
  5. Integrate Skublox API – General

Integrate Skublox API – General

Purpose of the Skublox 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.

Obtain your Rest API endpoint address using your Sellercloud team name. Insert your team name into this URL and open the URL in a new browser tab – https://api.sellercloud.com/api/server-by-team/?team={your_team_name}. The ApiUrl in the resulting JSON is the Rest API endpoint that should be used for all API calls.

Example: XX server → https://xx.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. The Token API hosted on each Sellercloud server handles operations such as acquiring and refreshing tokens.

Example: XX server → https://xx.api.sellercloud.com/token/swagger

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

Send Requests

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

Handle Responses

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

Exceptions include endpoints that 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 the server side. Response body will contain more information about the exception encountered.

Was this article helpful?

Need Support?
Can’t find the answer you’re looking for?
Contact Support