Slotting

Slotting is a put-wall service that you install in your own environment. You describe your put walls (sort walls, cubby walls, mobile put carts) once. For every wave of orders it plans which bins each order gets, as a compact group of neighbouring bins when one bin isn't enough. Then, for every item scan at the wall, it answers which bin the unit goes in, and when the scan completes an order, it gives that order's full list of bins so the packer can pull them.

Three things use it:

Your WMS or backend calls the JSON API: it creates the bin setup (a layout), sends each wave's orders and item dimensions, and releases bins after pack-out. See Calling the API.
The operators scan at the wall. Either your own scan screen calls POST /api/waves/{waveId}/scan, or you embed the ready-made station component, which works with keyboard-wedge scanners. See Embedding the components.
Whoever sets up the walls imports them from a CAD drawing (DXF), a spreadsheet (CSV), a generated grid or a photo, checks them in the setup editor and saves them. See Bin setups.

Two optional connections go the other way: put-to-light hardware shows the operator the bin and reports button presses (Put-to-light), and webhooks tell your systems when orders and waves are complete (Webhooks). A wave can also ask for every put to be confirmed with a scan of the bin label or a press of its light button (Confirmed puts).

How the bins are chosen (capacity, clusters, which order gets a unit, what happens when the wall is full) is explained for warehouse engineers in How slotting decides. Every field and error code is in the API reference.

A wave, from start to finish#

text

  your WMS                         slotting install                          put wall
     │                                    │                                      │
     │ POST /api/layouts (once) ─────────▶│  walls, bins, sizes                  │
     │                                    │                                      │
     │ POST /api/waves ──────────────────▶│  plans every order:                  │
     │   orders, item dimensions          │  a cluster of bins, or "queued"      │
     │◀──────────────── wave + plan ──────│  (bins are reserved for the wave)    │
     │                                    │                                      │
     │                                    │◀── POST .../scan { sku } ────────────│  operator scans a unit
     │                                    │─── bin "A-02-03" ───────────────────▶│  puts it into A-02-03
     │                                    │          ...                         │
     │                                    │─── bin, orderComplete, orderBins ───▶│  last unit: the order is
     │                                    │                                      │  complete, pull its bins
     │ POST .../release { orderId } ─────▶│  bins are free for the next order    │  (packed out)
     │                                    │                                      │
     │ POST .../close ───────────────────▶│  frees whatever the wave still holds │

Create the layout once (or import it, see Bin setups). It changes only when the walls do.
Create a wave with its orders. The response has the plan: each order's bins and the expected puts, or queued when the wall has no room for it yet.
Scan. Each scan returns the bin. A scan can carry a scanId of your choice; repeating it (after a network timeout, for example) returns the first answer and never puts a unit twice.
Release each order after it is packed out, so its bins can take the next orders. A wave that is done (or abandoned) is closed, which frees everything it still holds.

What your install serves#

URL	What
`/api/...`	The JSON API, for your backend and the components (Calling the API, API reference)
`GET /healthz`	`{"status":"ok","store":"redis","storeOk":true}`, for load balancers and monitoring
`GET /v1/info`	The version, the license in use, and whether photo import, lights and webhooks are configured (API reference)
`/docs/status.html`	The Status page: health, store, version, license and photo import of this install
`/widget/1.0.0/slotting-components.js`	The components (station, wall, setup editor, wave monitor), versioned and cacheable for a year (Loading the script)
`/widget/1.0.0/slotting-components.d.ts`	Their TypeScript declarations
`/widget/slotting-components.js`	Always the installed version (`no-cache`), for development
`/docs/`	These pages
`/`	The admin page: layouts, waves, a station and a monitor, for setting up and trying things out

This install is version 1.0.0. The default address is http://127.0.0.1:10083, unless your operator changed HOST / PORT or put the install behind a reverse proxy (Install and operate).

The API is not authenticated#

Anyone who can reach the port can change layouts and waves. That is by design: the install belongs on a private network, reachable only by your backend, the scan stations and the people who manage the walls. Never expose it to the internet; put your own authentication in front of it (a reverse proxy or gateway) if your network needs it. The install refuses changes from browser pages on other origins and, with SLOTTING_ALLOWED_HOSTS, requests for unknown host names. See Install and operate.

Licensing#

Every change through the API (creating layouts and waves, scans, releases, imports) needs a license key, checked offline. The download includes an evaluation (trial) license: everything works, but responses are marked as trial and the components show a TRIAL mark. Without a valid license those calls answer 402; reading (every GET), these pages, the components script, GET /healthz and GET /v1/info keep working. See License, and the Status page for the license of this install.