Smart Locker Software: What the Cloud System Should Do

Smart locker software has six jobs: decide who may open which cell, assign cells to users and orders, open doors on command, record every event, keep working through bad networks, and pass all of it to the systems you already run. On the machine it drives the locks, reads the door sensors and runs the screen. In the cloud it holds the users, credentials, cell states and audit log, and it raises alerts. Through an API and webhooks it lets a delivery platform, ServiceNow or a booking system reserve cells and hear about drop-offs and returns. The cabinet is the visible part, but the software decides whether a locker works day to day. When comparing systems, ask what happens when the network drops, what each audit record contains, how the API is secured, and whether you can export your data.

Smart locker software decides who may open which cell, assigns cells, opens doors, records every event, rides out network drops and passes data to other systems. The cabinet only holds things. The software decides whether the right person gets the right item and whether you can prove it afterwards. This page sets out what a good smart locker system should do, layer by layer, with the questions to ask any supplier and how KioskForce’s own platform answers them.

Quick answer

  • Credentials: issue, revoke and mix PIN, card, QR or one-time code, app and payment, per cabinet.
  • Cell assignment: allocate cells by size and capability, hold a state for every cell, and release cells that are not used.
  • Remote control: open a door, change prices and check status without a site visit. Log every action.
  • Audit log: user, cell, time and reason for every door event, with door-sensor confirmation, exportable.
  • Resilience: acknowledged and replayed instructions, so a dropped connection does not lose a door open.
  • Integration: a documented API, signed and idempotent webhooks, and connectors to ServiceNow, booking or delivery platforms.

The layers of a smart locker system

Layer Runs where What it does
Machine software On the locker (on KioskForce delivery lockers, Android) Drives the lock boards, reads door sensors, runs the touchscreen, QR scanner or keypad, and holds a live connection to the cloud
Cloud service Hosted Users, credentials, cell states, reservations, audit log, alerts, scheduling
Admin portal Browser Configure lockers and cells, manage users, open or recover cells, view and export records
API and webhooks Hosted Let other systems reserve cells, open doors and receive events
Integrations Your systems ServiceNow, HR or badge systems, booking and membership platforms, payment

Ask who wrote each layer. If the cabinet maker, the controller firmware vendor and the cloud software vendor are three different companies, a stuck door becomes three support tickets. KioskForce designs the locker hardware and software in-house. Staff and asset lockers report to the Vending on Track (VoT) cloud platform from our Australian software partner. The delivery locker platform, including its machine software, cloud service, portals and public API, was built in-house end to end.

Credentials and user management

The software has to recognise the credential the site already uses, and let you remove it the moment someone leaves.

Credential Software job Typical use
PIN Issue and change per user Shared staff lockers, no cards to manage
RFID or ID card (MIFARE, HID, EM) Enrol and revoke cards. Map them to users and permissions Sites with existing staff badges
PIN plus card Require both High-value tools, pharmaceuticals
QR or one-time code Generate per order. Expire after use Delivery, click-and-collect
App or API call Authenticate the calling platform, then open one cell Delivery platforms, member apps
Payment at the locker Authorise the card and hold or settle it Hire and sale

Different cabinets in one installation can use different methods. For example, shared employee lockers can use a PIN while tool storage uses an ID card. For staff deployments the user list should come from your HR or badge system rather than being typed in twice. Ask how users are imported and how a leaver is removed.

Cell assignment and cell states

Every cell should have an explicit state, so the system always knows whether it is free, held, full or out of service. The KioskForce delivery platform uses five:

State Meaning
IDLE Empty and available
RESERVED Held for an incoming order, nothing inside yet
OCCUPIED Order inside, waiting for collection
PENDING_SANITIZATION Collected, inside a grace period in case the customer needs to reopen
SANITIZATION Ultraviolet lamp running in that cell while it sits idle, 10 minutes by default

A scheduler checks the whole estate every 30 seconds and moves each cell on. A cycle that hangs is force-completed at twice its configured duration, so a hardware fault cannot strand a cell. Good allocation also matches each request to cell size and capability. A reservation carries the package dimensions and can ask for a heated cell, and the allocator only offers a compartment that fits.

Staff and hire lockers use simpler states, but the same principle applies. A hire locker shows each compartment as available or in use, and an issued item stays assigned to the user until it is returned to a cell.

Remote opening and the audit log

Remote opening is the function operators use most: a user is locked out, an order needs clearing, or a support agent is on the phone. It must be logged like any other opening, against the operator who made it.

The KioskForce delivery API includes an OpenDoor call for customer support. It opens the door without changing the reservation state, works from cell allocation until the cell is reallocated, and confirms asynchronously with an EVENT_TYPE_OPEN_DOOR_FULFILLED webhook carrying the request ID. For maintenance there is RequestMaintenance, which raises a ticket against a cell or locker and can block the cell from new reservations immediately.

A useful audit record holds:

  • Who: the user, operator or calling platform
  • Which: locker, cell and, where known, the item
  • When: timestamps for the lock release, the door opening and the door closing
  • Why: collection, return, drop-off, remote open, maintenance
  • Outcome: confirmed by the door sensor, failed, or unacknowledged

The door sensor matters. “We released the lock” and “the door actually opened” are different facts, and only the second proves a drop-off or a collection. Where you need proof that an item is inside, cells can carry an optional weight sensor. It is specified per cell at order and fitted during manufacture, and it cannot be retrofitted.

When the network drops

Lockers live in basements, lift lobbies, car parks and courtside shelters, on mobile signal that comes and goes. The software has to assume a bad network, not a good one. On the KioskForce delivery platform:

  • The machine holds a live WebSocket to the cloud, and instructions are pushed rather than polled.
  • Every instruction is cached server-side for 30 seconds and acknowledged by the machine. Only acknowledged instructions are cleared.
  • If the machine reconnects within that window, pending instructions are replayed in order. Several queued instructions are all kept, so a second command does not overwrite the first.
  • An instruction that is never acknowledged is logged as an error against that locker, so a failing modem shows up on the operations dashboard.

Not every workflow can run offline. Equipment issue to staff checks entitlements at the moment of issue, so it needs the connection. Card and QR payments depend on the payment terminal’s own connection (see payments). Ask any supplier which of your workflows still work offline, and plan for the ones that do not.

Alerts

The software should tell you about problems before users do. These are the alerts to ask any supplier for:

Alert Trigger
Unacknowledged instruction A door command the machine never confirmed
Offline The locker has lost its connection
Overdue return An issued item is not back by the end of the shift or loan period. The next issue can be made conditional on the return
Uncollected order An order has sat beyond its pickup window and needs clearing
Low stock Sale or issue cells running empty
Maintenance A cell reported faulty and blocked from use
Underweight return On cells with optional weight sensors, the item came back lighter than it left

APIs and webhooks

If lockers are to work with other systems, the API is the product. The KioskForce delivery platform publishes its developer documentation, an OpenAPI specification and a Swagger editor at delivery.kioskforce.com. It is worth checking any supplier against the same points:

  • Authentication and scoping. The delivery API uses an X-API-Key header issued per platform, and every call is scoped to the platform that made it. A platform sees only its own reservations and lockers. This guards against the top risk in the OWASP API Security Top 10 (2023), broken object-level authorisation: one client reading or acting on another client’s objects by changing an ID.
  • Endpoints for the whole lifecycle: search lockers near a location for a free cell that fits, reserve, drop off, pick up, cancel, abandon, query, request maintenance and open the door.
  • Webhooks for every state change: reservation created, dropped off, picked up, cancelled, pickup failed, door opened. Webhooks carry an event ID and an idempotency key, so a retried delivery can be deduplicated safely. The Standard Webhooks specification recommends the same pattern, with signed payloads and timestamps to prevent replay.
  • Published service levels and rate limits. The delivery API targets a 100 ms median for lookups and reservations, and 300 ms median for door opens, which include a round trip to the machine. It allows 1,000 requests per hour per key, with the remaining budget in response headers.
  • Tooling. delivery-cli is a single binary for Linux, macOS and Windows. You can reserve a cell and open a door from a terminal before writing integration code.

Integrations that matter

  • ServiceNow. Staff and asset lockers can join the Industrial Vending platform that runs our PPE and tool machines, and through it integrate with ServiceNow. A collection becomes an asset assignment, and a return closes it. Request pickup, loaner pools and repair drop-off are the common patterns. See IT vending machines and asset lockers.
  • Delivery and click-and-collect platforms, through the reservation API above. See delivery lockers and click and collect lockers.
  • Membership and booking platforms. Hire lockers can link to a venue’s member database, so players open them with an existing membership card or app. API integration with court booking platforms is supported.
  • Payment. The standard hire build uses a Nayax reader on the Marshall protocol, which authorises at pickup and settles after the return, and Nayax has certified it for equipment rental.

Reporting

Day-to-day screens matter less than what you can prove at month end. Expect, at minimum:

  • Live status: which cells are free, occupied or out of service, and which items are out and due back.
  • Usage: peak hours, the most-used cells and items, revenue per compartment for hire and sale.
  • Charging: where cells carry tracked USB-C charging, every session is logged with the user, start and end time, duration and energy used, and limits can be set per user or per day.
  • Export: the raw event log, not just charts, so your own systems hold a copy.

For the wider dashboard features KioskForce machines share, see the cloud vending dashboard.

Data protection

An audit log is personal data: it records who was where and when. Under the EU GDPR (Article 5), personal data must be “adequate, relevant and limited to what is necessary” and kept in identifiable form “for no longer than is necessary”. Other privacy laws set similar rules. In practice:

  • Record what the workflow needs (user ID, cell, time, event), not more.
  • Set a retention period for door events and stick to it.
  • Limit portal access by role, and log operator actions, including remote opens.
  • Keep credentials such as API keys and card numbers out of exports and screenshots.

You remain the controller of your users’ data. KioskForce builds to the requirements you state. We do not certify your compliance.

This is a summary for planning, not legal advice. Rules change; confirm with your privacy adviser (as of October 2026).

What to specify if you are buying one

  1. Workflows: staff issue and return, hire, sale, click-and-collect, delivery, or a mix.
  2. Credentials: what users already carry, and where the user list lives.
  3. Systems of record: ServiceNow, an HR or badge system, a booking platform, an ERP, or the dashboard alone.
  4. Records: fields, retention period and export format.
  5. Network: what must keep working offline.
  6. Per-cell hardware the software must know about: charging, optional weight sensors, heated or chilled cells. These are fitted at build.

Start with the smart locker guide, lay out a cabinet in the configurator, or contact us. Integrations beyond the standard platforms are scoped per project. Support is by email, or through the local distributor where one supplied the system.

What software cannot fix

  • Door sizes. Whether a door sells, hires or issues can be changed in software. Its size cannot.
  • Options not fitted at build. Weight sensors and charging cannot be switched on later if they were not ordered.
  • Condition. The log records custody, not whether the returned drill works.
  • A position with no network at all. A locker that cannot reach the cloud cannot check new credentials or report events.

Frequently asked questions

What is smart locker software?

Smart locker software is the system that controls a bank of electronic lockers and records what happens in them. Software on the machine releases locks, reads door sensors and runs the screen or keypad. A cloud service holds users and credentials, assigns cells, keeps the state of every cell, logs every door event and raises alerts. An admin portal lets operators manage all of this, and an API lets other systems such as a delivery platform, ServiceNow or a booking system work with the lockers directly.

What should a locker management system record?

Every door event with the user, the cell, the locker, the time and the reason for the opening: a collection, a return, a drop-off, a remote open by an operator or a maintenance opening. It should record both that the lock was released and that the door sensor saw the door open and close, because those are different facts. For issued items it should keep an open record against the user until the item comes back. You should be able to export the log and reach it through an API.

What happens to a smart locker when the internet connection drops?

It depends on the system, so ask. On the KioskForce delivery platform, every instruction to a locker is cached server-side for 30 seconds and acknowledged by the machine. If the connection drops and returns within that window, pending instructions are replayed in order, and an instruction that is never acknowledged is logged as an error. Workflows that check entitlements in the cloud at the moment of issue, such as equipment issue to staff, need the connection, so plan how the site works during an outage.

Can smart lockers integrate with other systems?

Yes, and for most deployments that is the point. KioskForce delivery lockers expose a documented REST and gRPC API with webhooks, so a delivery platform can reserve a cell, open doors from its own app and receive an event when an order is dropped off or picked up. Staff and asset lockers can join the Industrial Vending platform and integrate with ServiceNow, where a collection becomes an asset assignment and a return closes it. Hire lockers can link to member databases and booking platforms.

How do users open a smart locker?

With a credential the software has issued or recognises. KioskForce lockers support a PIN on a keypad, an RFID or ID card such as MIFARE, HID or EM, both together for high-value cells, a QR code or one-time code issued per order, an app or API call, and payment at the locker for hire and sale. The software issues and revokes these credentials, and different cabinets in one installation can use different methods.

Can an operator open a locker door remotely?

Yes. Remote opening is a standard function of KioskForce locker software, used when a user is locked out or a support agent needs to help. On the delivery platform there is a dedicated out-of-band OpenDoor call that opens the door without changing the reservation state and confirms with a webhook carrying the request ID. Remote openings appear in the audit trail like any other door event.

Is smart locker software sold separately from the hardware?

Some vendors sell software for other makers’ lockers, and some lockers ship with a basic local controller and no cloud system. KioskForce designs the locker hardware and software together, so the cloud platform, the on-machine software and the cabinet come from one team. That matters when a door will not open, because the hardware, firmware and cloud are not three separate support tickets. Staff and asset lockers use the Vending on Track cloud platform from our Australian software partner.

References

Talk to us about locker software

Tell us the workflows the locker has to run, the credentials your users carry and the systems the records must reach. We will come back with the configuration, the integration scope and a price.

Project brief · 60 seconds

What are we building together?

Three quick steps. Your brief goes straight to the engineers who design, build and support KioskForce systems.

1What are you building?
2Roughly how many units? (optional)
3Where should we send your proposal?

Prefer email? sales@kioskforce.com