Integrating robots when our system has no API is still straightforward: you move the work on a schedule instead of in real time, exporting open tasks to a file the robot fleet reads, and importing completion confirmations back the same way. Logistics UK puts the sector at more than 200,000 businesses contributing £185 billion a year to the economy (Logistics UK research), and a large share of those sites run stock systems bought long before anyone planned to put a robot on the floor. For a supply chain director in chilled and frozen distribution, that is this quarter's blocker: the capital is approved, the trucks are specified, and the programme stalls because nobody can get an order out of a system with no documented interface. A warehouse system with no API can still drive a robot fleet through scheduled file exchange, where middleware handles format translation, retries and duplicate suppression.
Why a system with no API stops a robot programme
Most chilled and frozen distribution centres in the UK are not running new software. They run a stock system chosen ten or twenty years ago, extended by a succession of report writers, on a support contract saying modifications are at the operator's own risk. The vendor may have retired the product line. Whoever wrote the last interface may have left. When the automation business case lands, IT reads it as a request to modify the one system that nobody is allowed to break during a trading week, and the request stops there.
Cold chain makes that worse than most sectors. A chilled site works to retail delivery slots, so the despatch window is fixed by a customer, not by the warehouse. The change window a general merchandise site might find on a Sunday night does not exist when the building runs 24 hours and the stock has a shelf life measured in days. Freezer labour is also the hardest to recruit, which is exactly why the robot case was approved. The chilled and frozen estate clustered around DIRFT, Daventry and Magna Park runs to that pattern.
It is worth testing the premise first. "No API" frequently means "no API we are licensed to use", or "none the current support contract covers", or simply that nobody has looked. Almost every warehouse system can already write a scheduled report to a folder, because finance and the customer reporting pack depend on it. That supported, already-tested capability is usually the fastest route to a robot fleet, and it does not touch the core system.
Lever one: build the export and import cycle around the shift
Start from the flow you want to automate and work backwards to a cadence. A worked example: at five minutes to each hour, the existing report scheduler writes an open-work file with a sequence number to a network share. Each row carries a task identifier, a pallet licence plate, a from location, a to location, a priority and a due time. The middleware collects it within 60 seconds, validates every location against the site map, and pushes rows it cannot resolve into an exceptions file a shift supervisor sees on screen rather than into a silent log.
Confirmations run the other way on a tighter cycle, typically every five minutes, because a stock balance lagging by an hour is worse than no automation. Each confirmation names the task, the pallet, the location it left, the location it reached, the timestamp and the outcome. Agree three rules in writing before anyone builds: one file per cycle, sequence numbered and never overwritten, a file counts as complete only once renamed from a temporary name, and an unprocessed file raises an alarm rather than waiting for the next one.
Lever two: put middleware between the files and the fleet manager
The middleware is where integration risk is actually managed, and it is the component most often left out of a budget. It should carry an idempotency key, normally the task identifier plus an attempt number, and a short-lived table of keys it has already accepted. That mechanism is what stops a replayed file double-posting a stock movement, the failure mode that destroys trust in an automation programme faster than any mechanical fault.
Beyond deduplication, insist on four behaviours. Retries with a backoff, so a share that is briefly unavailable does not drop a shift's work. A quarantine for messages that fail repeatedly, visible to a named person. A single clock, with every timestamp in a consistent time base, because a site spanning a clock change will otherwise produce confirmations that appear to arrive before the tasks that caused them. And a reconciliation at the end of every shift comparing tasks issued against confirmations received, published as a number the supervisor signs off. Reconciliation turns an invisible interface into an auditable one.
Lever three: keep the robot side on an open standard
If the link to your stock system has to be bespoke, make certain it is the only bespoke thing in the design. On the robot side, VDA 5050 gives a published message format between a fleet manager and vehicles, so adding a second or third machine class later does not add a second or third integration project. The M4 fleet manager sits above the robots, takes the work the file seam delivers and turns each task into routes, traffic rules and vehicle assignments, while the robot dispatch software sequences work and charging around your despatch windows.
That separation matters commercially. A programme starting with two reach trucks on chilled high-bay racking, then adding counterbalanced machines on the yard-to-goods-in leg, should not need the stock system touched again.
| Route | Typical build effort | Task latency | Change to core system | Best suited to |
|---|---|---|---|---|
| Scheduled file exchange with middleware | Lowest. Uses report scheduling the system already has | 5 to 60 minutes | None | Goods-in to store, store to despatch, cross-dock staging |
| Database view or read replica plus middleware | Medium. Needs a supported read path and DBA time | 1 to 5 minutes | Read only | Sites with in-house database support and tighter stock visibility |
| Live web interface | Highest. Needs vendor involvement or a supported upgrade | Seconds | Yes, usually a version change | Pick-face replenishment, or any flow where a person waits on the robot |
Lever four: treat the file seam as work equipment evidence
A scheduled interface is not only an IT artefact. Any robot on your floor is work equipment, so the duties in the Provision and Use of Work Equipment Regulations 1998 (PUWER 1998) apply to it as they apply to a manned truck, and the HSE guidance on PUWER and on workplace transport is what your risk assessment will be read against. The interface belongs in that assessment for a simple reason: a stale task list sends a machine to collect a pallet a person has already moved, and the controls that prevent it are the validation and reconciliation steps above.
ISO 3691-4 covers driverless industrial trucks and their systems, and a BSI subscription is the usual route to the current text. Build the evidence while you commission, not afterwards: keep the exceptions file, the shift reconciliation and the traffic management plan together. Great Britain recorded 59,219 employer-reported non-fatal injuries to employees in 2024/25 (HSE statistics), the context any inspector brings to a site where machines and people share an aisle.
A warehouse system with no API can still drive a robot fleet through scheduled file exchange, where middleware handles format translation, retries and duplicate suppression.
What FlyWei does here
FlyWei is an independent, vendor-neutral UK systems integrator of autonomous forklifts and AMRs, and integration is the part we scope first, before any machine is chosen. FlyWei designs the seam between your stock system and the fleet: the file contract, the cadence, the validation rules, the exception path and the shift reconciliation your supervisors will actually use. Because FlyWei integrates machines from several manufacturers rather than selling one range, the design question is which class of truck fits the chilled aisle and the freezer door, not which catalogue the answer comes from.
On the robot side, FlyWei supplies and commissions FlyWei autonomous forklifts, reach trucks for high-bay chilled racking and counterbalanced trucks for the yard-to-goods-in leg, under the M4 fleet manager with the robot dispatch software sequencing work around your despatch slots. On the systems side, our warehouse robot ERP integration services cover the middleware, the idempotency design and the reconciliation reporting, so the interface is owned rather than improvised. If a live interface becomes available later, the fleet layer does not change. Only the adapter does, and that is the point of putting the bespoke work in one place. See also what data a robot fleet exchanges with an ERP, whether you need to replace your WMS to use AMRs and what happens when the network fails mid-operation.
Frequently asked questions
Can we start with file exchange and move to a live interface later?
Yes, and it is the normal path. Keep the task and confirmation structures identical in both designs. When a live interface arrives you swap the adapter, and everything above it carries on unchanged.
How often should the export run?
Set it from the flow. Pallet moves between goods-in, bulk store and despatch tolerate a 15 to 60 minute cycle. Confirmations should return faster, usually every five minutes, because the operation depends on stock accuracy.
What stops a replayed file posting the same stock movement twice?
An idempotency key held by the middleware. Every task carries an identifier, the middleware records the identifiers it has accepted, and a repeat is acknowledged then discarded. Without it, any retry risks a duplicate, and duplicates make a stock controller stop trusting the system.
Does the robot fleet need its own stock database?
No. The fleet layer holds tasks, positions, loads and vehicle state. Your existing system remains the record of stock. That boundary makes the integration auditable and lets you change either side later without a data migration.
What if our system cannot write files to a share at all?
That is rare, but a supported read path to a database view can serve as the task source. The pattern does not change: something outside the core system produces a validated task list on a known cadence, and middleware turns it into missions.
Who owns the middleware after go-live?
Decide before you sign. Name who owns the file contract, the exception queue and the shift reconciliation, and put support hours and response times in writing. An unowned interface is the commonest reason a working integration degrades in its second year.
Does file-based integration change the safety requirements?
It does not reduce them. The robots remain work equipment under PUWER, the traffic management plan governs shared aisles, and ISO 3691-4 applies to driverless trucks. The interface design adds evidence: validation rules, an exception path and a reconciliation record.
If a stalled integration is on your Q4 risk register while the automation capital is already approved, the fastest way to unblock it is to test the seam rather than the robots.
Get a 48-hour feasibility read on your highest-volume flow, and see how the M4 fleet manager takes work from a system that was never built to talk to robots.
No obligation, and we reply within one business day.