What is a food delivery locker?

A food delivery locker is a bank of individually locking, access-controlled compartments installed in the lobby of an office tower or apartment building. A delivery rider drops an order into an assigned cell and leaves; the customer collects it later with a code or QR scan. It removes the two failure points in last-metre delivery: the rider cannot reach the customer's floor, and the customer is not free at the moment the rider arrives. KioskForce builds the locker hardware, the software running on the machine, and the cloud service that assigns cells, opens doors, and notifies both sides.

How does a delivery platform integrate with KioskForce delivery lockers?

Through a documented REST and gRPC API, published at delivery.kioskforce.com. A platform authenticates with an X-API-Key header, searches for lockers near a delivery address by latitude, longitude, radius and package dimensions, reserves a cell, and receives back a drop-off code, pickup code, and QR codes for both. Door opens can be triggered either by the codes at the machine or by API calls from the rider and customer apps. Every state change — reservation created, dropped off, picked up, cancelled, pickup failed, door opened — is pushed to the platform's HTTPS webhook endpoint with an event ID and an idempotency key. There is also a cross-platform command-line tool for testing the integration before writing any code.

How does the rider open the locker?

Three ways, and a deployment can use all three at once. The rider can scan the drop-off QR code on the machine's scanner, type the drop-off code on the touchscreen, or tap unlock in the rider app, which calls the platform's backend and then our DropOff endpoint. All three land in the same place: the cell light comes on, the door releases, and the machine reports the door open and door closed events back to the cloud. If the rider accidentally shuts the door too early, a drop-off grace period — 120 seconds by default, configurable per reservation — lets them reopen the same cell without a new authorisation.

What happens if the locker loses its internet connection?

Instructions are not lost. The cloud service caches every instruction it sends to a locker for 30 seconds, and the machine acknowledges each one it executes. If the machine drops off the network and reconnects within that window, the pending instructions are replayed in the order they were issued, and only then removed. Multiple instructions queued for the same locker are all preserved rather than the last one overwriting the first. If an instruction is never acknowledged, it is logged as an error against that locker rather than failing silently. This matters in real buildings, where lockers sit in basements and lobbies on marginal mobile signal.

Can the cells keep food warm?

A heating pad is available per cell as a build-time option, and the capability is carried through the whole stack — the API exposes a heating flag per cell, and a reservation request can state that the order needs a heated cell, so the allocator only picks a compartment that has one. Every cell also has active ventilation as standard, which is what stops a hot meal steaming up the compartment and the food going soggy while it waits. Heating pads are specified when the locker is built rather than switched on later, so the ratio of heated to ambient cells is one of the first decisions in scoping a site.

How is a cell cleaned between deliveries?

Automatically, on a timer, per cell. After the customer collects their order there is a grace period — configurable per reservation, typically 30 to 300 seconds — in case they close the door and need to open it again. Once that expires and the door is confirmed shut, the cell runs a sanitisation cycle, 10 minutes by default: an ultraviolet lamp inside that individual compartment runs while the cell sits idle, and the compartment ventilates. Only when the cycle completes does the cell return to the available pool. It is per cell, not per cabinet — a compartment two doors down can be taking a drop-off while this one sanitises. A scheduler in the cloud service checks every 30 seconds and force-completes a stuck cycle at twice the configured duration so a hardware fault cannot strand a cell out of service indefinitely.

Who was the delivery locker system built for?

It was designed and built for a major on-demand delivery platform, for food and parcel handover in busy office buildings and apartment complexes. The complete system was delivered: locker hardware, on-machine software, cloud service, admin portals, integration API, public developer documentation and a command-line tool. It is open to other partners too — we work with delivery platforms, building operators, and grocery and pharmacy operators who want locker handover without building the locker stack themselves.

Can we run our own locker network on your platform, or do you operate it?

Either. The software is multi-tenant by design: every platform authenticates with its own API key and can only see and act on its own reservations, and each platform can set a global webhook URL or override it per reservation. An operator can run a network of lockers and sell access to several delivery platforms at once, or a single delivery platform can own its own estate. There is an admin portal for operators covering locker configuration, reservation tracking, opening and recovering individual cells, and uploading advertising for the locker screens.

What does a delivery locker deployment need from the site?

A mains power outlet, a footprint with clearance for a fully opened cell door, and mobile or Wi-Fi coverage the machine can hold. Beyond that the scoping questions are about traffic, not the building: how many orders a day arrive at that address, what the peak hour looks like, the largest package that has to fit, and how long an uncollected order can sit before it has to be cleared. Those four answers set the cell count, the cell size mix, and how many compartments need the optional heating pad. Send us the address and an order-volume estimate and we will size it.

Can the locker screen show advertising?

Yes, and it is part of the shipped platform rather than a later addition. The machine plays image and video advertising full-screen while idle and alongside the interface during a transaction. Operators upload creative in the admin portal and assign it to specific lockers, so a network can run different campaigns per building. For a locker sitting in the lobby of a tower with thousands of daily passes, that screen is a second revenue line beside the delivery fee.

Food & Parcel Delivery Lockers — The Last Metre, Automated

A KioskForce delivery locker is the handover point between a delivery rider and the person who ordered. The delivery platform reserves a cell through our API before the rider even arrives; the rider opens it with a drop-off code, QR scan, or an API call from the rider app; the platform gets a webhook the moment the food or parcel is inside, and passes a pickup code to the customer. No lobby buzzer, no rider waiting in a corridor, no food left on a doorstep. Every cell is individually lit, actively ventilated, and sanitised by an ultraviolet lamp that runs while the cell sits idle after a collection; a heating pad is available as an option. Cell sizes are set per site rather than to a catalog. The whole platform — locker hardware, on-machine Android software, cloud server, admin portal, and the external API — is designed and maintained in-house. The integration API is published at delivery.kioskforce.com with webhooks, an OpenAPI spec, and a command-line tool. The system was built and delivered for a major on-demand delivery platform, and is open to integrate with other delivery services, building operators, and grocery and pharmacy operators.

The Last Metre Is Where Delivery Breaks

Everything in a food delivery is optimised until the rider reaches the building. Then it stops. The rider cannot get past the lobby, or cannot find the apartment, or gets there and the customer is in a meeting. The order sits on a reception desk going cold, or on a doorstep going missing, and the rider — paid per drop — burns ten minutes they cannot bill.

A delivery locker is the handover point that does not require both people to be in the same place at the same time. The rider arrives, drops the order into an assigned compartment, and leaves. The customer collects when they are free. The building’s reception desk stops being an unpaid parcel room.

White ten-compartment KioskForce delivery locker on castors, each cell door carrying a translucent panel, with a touchscreen and QR scanner set into the second row and an identical second cabinet standing behind it — A KioskForce delivery locker cabinet before dispatch. Ten compartments on castors; the touchscreen and the QR scanner slot beneath it take one cell position in the second row, at standing height for a rider carrying two bags. Every cell has its own light, its own ultraviolet sanitising lamp, and active ventilation — and cabinets gang together for a larger lobby.

KioskForce built this system end to end: the locker cabinet, the Android software running the screen and the door hardware, the cloud service that assigns cells and drives the machine, the operator admin portals, and the public API that delivery platforms integrate against. The integration documentation is live at delivery.kioskforce.com — the same docs a customer’s engineering team reads on day one.

How a Delivery Runs, End to End

Step	Who acts	What the platform calls	What the locker does
1. Order placed	Customer, in the delivery app	`ReserveCell` — with the package dimensions and, optionally, a requirement for a heated cell	A suitably sized cell is held. The platform gets back a reservation ID, the cell label (e.g. `A03`), a drop-off code, a pickup code, and QR codes for both.
2. Rider arrives	Rider	`DropOff`, or nothing at all if the rider uses the code or QR at the machine	The cell light comes on, the door releases, the screen says which compartment. Door-open and door-closed are both reported back.
3. Order is in	—	Webhook `EVENT_TYPE_DROPOFF` fires	The platform now knows the food is in cell A03 and can push the pickup code to the customer.
4. Customer collects	Customer	`PickUp`, or the pickup code or QR at the machine	The door opens, the customer takes the order, the webhook `EVENT_TYPE_PICKUP` fires.
5. Cell resets	Nobody	—	Grace period, then a UV sanitisation cycle in that individual compartment, then the cell rejoins the available pool.

Reserving early is deliberate. The recommendation in the API documentation is to call ReserveCell as soon as the customer is about to place the order, not when the rider sets off — that is what guarantees a compartment is actually free at 12:30 in a tower where four hundred people order lunch inside twenty minutes.

Three ways to open a door, and why all three ship

A rider with a dying phone, a customer whose app has logged out, a building with no mobile signal in the lift lobby — each of these breaks exactly one of the three access methods, which is why the machine supports all of them:

Numeric code on the touchscreen. Works with nothing but the code. The code arrives by SMS, push notification, or in-app text.
QR scan at the machine’s scanner. Fastest for a rider carrying three orders.
An API call from the app. The rider or customer taps unlock in the delivery platform’s own app; the platform calls DropOff or PickUp, and the door opens without anybody typing anything.

All three share the same grace-period timer, so a rider who shuts a door too early can reopen the same cell by whichever method is to hand.

What Happens After the Customer Walks Away

The part of a delivery locker that decides whether the operator’s life is tolerable is not the drop-off. It is what the cell does on its own afterwards.

Every cell moves through a defined lifecycle, driven by a scheduler in the cloud service that checks the estate every 30 seconds:

State	Meaning	How it ends
`IDLE`	Empty and available	A reservation is assigned
`RESERVED`	Held for an inbound order, nothing inside yet	Rider drops off — or the platform cancels and the cell is released
`OCCUPIED`	Order inside, waiting for the customer. Cell light on	Customer picks up
`PENDING_SANITIZATION`	Picked up, inside the grace period	Grace period expires with the door shut
`SANITIZATION`	UV lamp running inside that compartment while it sits idle, 10 minutes by default	Cycle completes — or is force-completed at twice the duration, so a hardware fault cannot strand the cell

The grace period exists because people close the door, walk three steps, and realise they left the drink. It is configurable per reservation, typically 30 to 300 seconds. The sanitisation cycle exists because the previous occupant of that compartment was somebody’s curry — an ultraviolet lamp in the cell runs while it sits idle, before the next order goes in. Both run per cell, so one compartment sanitising does not take the cabinet out of service. Neither requires an operator to do anything.

For the cases that do need a human, the API has two escape hatches. RequestMaintenance raises a ticket against a cell or a whole locker and can block the cell from further reservations immediately. OpenDoor is an out-of-band open for customer support: it opens the door without changing the reservation state, works from cell allocation right through until the cell is reallocated, and confirms asynchronously with an EVENT_TYPE_OPEN_DOOR_FULFILLED webhook carrying the request ID you sent. That is the endpoint a support agent’s tooling calls at 11pm when a customer says the door will not open.

The Cabinet

The locker is built the way the rest of our machines are built — to the site, not to a catalog page.

Cells sized per site. Compartment dimensions are held in millimetres and matched against the package dimensions the platform sends on every reservation. A building whose traffic is 80% single-meal orders and 20% grocery gets a different cell mix from a tower doing document courier work.
Cabinets gang together. The cabinet pictured above carries ten compartments; a typical installation runs three actuator boards for around thirty cells, and larger lobbies add more. Castors are standard, so a building can reposition the unit without re-running conduit.
Per-cell light, switched by the cloud, so the customer walks to the right door instead of reading a label.
Per-cell door sensor. Open and closed are both reported as events. The system knows the difference between “we released the lock” and “the door actually opened”, which is what makes the drop-off confirmation trustworthy.
Per-cell ultraviolet sanitising lamp, run on a timer by the scheduler while the compartment sits idle after a collection — one cell at a time, so the rest of the cabinet stays in service.
Active ventilation in every cell, as standard. Without it a hot meal steams up its own compartment and arrives soggy; with it, the cell clears between orders instead of holding the last one’s smell.
An optional heating pad per cell, specified at build where the food mix justifies it — exposed in the API as a per-cell capability flag and honoured by the allocator when a reservation asks for a heated compartment.
Per-cell weight sensors are available as an option, specified at order. They are integrated during manufacture and cannot be retrofitted in the field, so the compartments worth instrumenting are chosen before the cabinet is built. See weight-sensor tracking for how they work.
Touchscreen, QR scanner and code keypad on the door column.
Advertising playback on the same screen — image and video, uploaded and assigned per locker from the admin portal.

Cabinet finish, branding, footprint and indoor or outdoor rating follow the same custom manufacturing process as the rest of our range.

The Software Nobody Sees, and Why It Decides Whether This Works

Anyone can build a cabinet with solenoid locks. The reason delivery locker programmes fail is that lockers live in basements, service corridors and lift lobbies, on mobile signal that comes and goes, and a locker that misses the instruction to open a door has just stranded somebody’s dinner behind a locked steel door.

So the instruction path is built to survive a bad network rather than to assume a good one:

The machine holds a live WebSocket to the cloud, and instructions are pushed down it rather than polled for.
Every instruction is cached server-side for 30 seconds and the machine acknowledges each one it executes. Only an acknowledged instruction is cleared.
If the machine drops off and reconnects inside that window, its pending instructions are replayed in order. Several instructions queued for one locker are all preserved — a second command does not overwrite the first, which is exactly the case that bites when two riders arrive at a disconnected locker within a minute of each other.
An instruction that is never acknowledged is logged as an error against that locker, so a machine with a failing modem shows up in the operations dashboard rather than in customer complaints.
Webhooks carry an event ID and an idempotency key, so a retried delivery to the platform’s endpoint is safe to deduplicate rather than being processed twice.

The same discipline applies to old software in the field: a machine that does not announce it can acknowledge instructions is served the way it always was, with no error logging and no behaviour change. Backwards compatibility is a rule in this codebase, not an aspiration — machines in a lobby ceiling are not easy to reflash.

Integrating: What Your Engineers Actually Get

The full developer documentation, including the OpenAPI specification and a Swagger editor, is published at delivery.kioskforce.com.

Authentication is an X-API-Key header issued per platform. Every call is scoped to the platform that made it — a platform can only see and act on its own reservations and its own lockers.

Endpoints (REST over HTTP, with gRPC available for the same service):

Call	Purpose
`Echo`	Connectivity and credential check — the first thing to run
`SearchMachines`	Lockers within a radius of a latitude/longitude, filtered by whether they can fit a given package and whether they currently have a free cell
`GetMachine`	Detail for one locker, including its cell capabilities
`ReserveCell`	Hold a cell; returns drop-off and pickup codes and QR codes
`DropOff` / `PickUp`	Open the door for the rider / the customer
`CancelReservation`	Release a cell that was never used
`AbandonPickUp`	Customer is not coming; flag it for the operations team to clear
`GetReservation` / `ListOngoingReservations`	Query one reservation, or page through everything currently in flight
`RequestMaintenance`	Report a faulty cell or locker; optionally block the cell immediately
`OpenDoor`	Out-of-band door open for customer support, without changing reservation state

Webhooks push every state change to an HTTPS endpoint you nominate — globally at onboarding, or overridden per reservation:

Event	Fires when
`EVENT_TYPE_RESERVATION_CREATED`	A cell has been held
`EVENT_TYPE_DROPOFF`	The order is in the cell
`EVENT_TYPE_PICKUP`	The customer has taken it
`EVENT_TYPE_RESERVATION_CANCELLED`	The reservation was cancelled
`EVENT_TYPE_PICKUP_FAILED`	A pickup attempt did not complete
`EVENT_TYPE_OPEN_DOOR_FULFILLED`	An out-of-band door open finished

Service levels are published per endpoint, not as a single number. Lookups and reservations target a 100 ms median and 150 ms at the 99th percentile; door-open calls target 300 ms median and allow up to two seconds at the 99th percentile because the round trip includes talking to a machine over a mobile network. Availability targets run 99.5% to 99.9% depending on the call. Rate limiting is 1,000 requests per hour per API key, with the remaining budget returned in response headers.

There is a command-line tool. delivery-cli is a single static binary for Linux, macOS and Windows with AWS-CLI-style commands and JSON output. A product manager can reserve a cell and open a door from a terminal before an engineer writes a line of integration code — which is usually the fastest way to settle an argument about whether the workflow fits.

And there is an operator portal, authenticated through Auth0 or Cloudflare Zero Trust, covering locker configuration, platform and webhook setup, reservation tracking and filtering, opening or recovering an individual cell, and advertising upload and assignment.

Where This Came From — and Who Else Can Use It

This platform was designed and built for a major on-demand delivery platform, to handle food and parcel handover in busy office towers and apartment complexes. The brief was the one every delivery platform in a dense city eventually hits: riders losing time in building lobbies, and buildings refusing to keep absorbing the traffic.

We delivered the complete system — cabinet, on-machine software, cloud service, operator portals, integration API, public developer documentation, and tooling — against staging environments provisioned for both a regional edge deployment and the central service.

The platform is open to other partners. It is finished, tested and publicly documented — the engineering that normally takes a delivery platform a year to fund and build is already done, and the API is already public. Who it suits:

Delivery and on-demand platforms — food, grocery, pharmacy, courier — wanting locker handover without building the locker stack
Building owners and facility managers in office towers, apartment complexes, co-living and student accommodation, who want the parcel problem off the reception desk
Grocery, pharmacy and QSR operators running their own delivery fleets into residential and office buildings
Locker network operators who want to run an estate and sell access to several delivery platforms at once

This is a delivery locker, not a click-and-collect cabinet. It is designed around an inbound order arriving with a rider who has never been to the building before — cell assigned in advance by the platform, drop-off code issued to a stranger, order handed over unattended. Collection of stock a shop has already set aside is a different job with different software; that is custom smart lockers.

If you already run a delivery platform, the fastest way to evaluate this is to read the API documentation, then ask us for a staging key and drive it with delivery-cli for an afternoon.

What We Need to Scope a Deployment

Four answers size a site. None of them are about the building:

How many orders a day arrive at this address, and what the peak hour looks like. Lunch in an office tower is the entire design constraint.
The largest package that has to fit. This sets the big-cell count, which is the expensive part.
How long an uncollected order can sit before it must be cleared. This sets cell turnover, and therefore how many cells you need for the same volume.
What proportion needs to stay hot. The heating pad is a per-cell build-time option, so this is a decision to make before manufacture, not after. Ventilation and UV sanitisation are standard on every cell and need no decision.

Then the practical site checks: a mains outlet, floor space with door-swing clearance, and mobile or Wi-Fi coverage the machine can hold. And on the integration side: whether you want your riders and customers opening doors through your own app via the API, or through codes and QR at the machine, or all of it.

Custom smart lockers — the wider locker platform, including PPE, tool, asset and click-and-collect applications, with an online configurator
Industries we build for — hotels, retail, transportation, healthcare and more, several of which run the same locker handover pattern
Southeast Asia vending machines — manufacturing and delivery into ASEAN markets
Kiosks — self-service terminals built on the same hardware and software platform

Talk to Us About a Delivery Locker Programme

Tell us whether you are a delivery platform, a building operator, or a retailer — and roughly how many drops a day you are trying to handle. We will come back with a cell configuration and a realistic timeline rather than a brochure.

Contact Us for More Information