Walk lists

POST /api/v1/locate-lists pushes a named list of product codes into the Check location mode on the scan screen. A typical setup: a "Send to WMS" button in your order management system calls this endpoint with the order's EANs — the operator picks up the scanner, opens Check location and the walk list is already waiting, sorted by bin codes.

This is the only writing endpoint in the API. It creates a pending list; nothing else in your data changes.

Request

POST https://vintrhall.com/api/v1/locate-lists
Authorization: Bearer vh_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json

{
  "name": "Order #4521",
  "codes": ["5904960819779", "THP4225", "5906302367986"]
}

• name — shown on the scanner so the operator knows what the walk is for (1–120 characters).
• codes — 1–200 entries, each an EAN or SKU (matching happens on the scanner: exact SKU first, then EAN). Duplicates are removed, order is kept.

Response

{ "id": "k3j2…", "name": "Order #4521", "codesCount": 3 }

Status 201. Codes that do not exist in Vintrhall are accepted anyway — the scanner reports them as not found when the list is loaded, so nothing disappears silently.

URL-only platforms

If your platform can only call a templated URL (custom "call URL" order actions in an OMS, Base and similar), the same endpoint works as a GET with query parameters, and the API key may travel in the URL when headers are not an option:

GET https://vintrhall.com/api/v1/locate-lists?api_key=vh_…&name=Order-4521&codes=5904960819779,THP4225

Codes may be separated by commas or pipes (|), so template tags that join EANs with | work without reformatting. Prefer the Authorization header whenever your platform supports it — keys in URLs tend to end up in logs.

Lifecycle

A list waits until an operator loads it in Check location (then it disappears from the queue). Sending the endpoint twice creates two separate lists. Rate limit: 30 requests per minute.