No interface? Then files.
Eight defined datasets, delivered by CSV or REST. That runs max.dash on any warehouse system - an in-house build just as well as an enterprise WMS that never had a public interface to begin with.
Why this route exists.
Because the largest operators run the worst interfaces. That isn't a coincidence, it's a consequence of growth.
- Past a certain size, operators build their own. Businesses running five- and six-figure daily volumes often run their own warehouse software, because no standard system maps their process. Those systems never had a public interface - they never had a reason to build one.
- Enterprise WMS are engineered per client, not integrated. The larger warehouse management systems get configured for one customer at a time and typically run in that customer's own data center. There's no developer portal there, but there is a database with everything in it.
- Grown estates are the normal case, not the exception. One site on system A, an acquired operation on system B, a major client running its own portal next to both. Waiting for all three to grow a public API is a wait without an end.
One adapter per vendor doesn't solve that. A defined schema solves it at once - for all three cases together, and for whatever custom WMS reporting your estate needs next.
The eight datasets.
Exactly these eight, no more. Kept deliberately narrow: everything needed for control, proof and billing, and nothing beyond that.
Scroll table sideways
| Dataset | What's in it | What max.dash needs it for |
|---|---|---|
| Brands | your clients, with an identifier and a name | the dividing line for every report and every portal login |
| Staff | who packs, with the identifier scanned in the warehouse | performance per person, matched to time tracking |
| Shipments | per parcel: client, timestamps, handler, carrier | throughput, SLA rate, billable volume |
| Delivery notes | the order reference for the shipment | cycle time from order to dispatch |
| Lines | what was in the shipment, with quantity | weighting and the points system per parcel content |
| Open orders | the current backlog | daily forecast, staffing needs, early warning |
| Stock | per client and item | cover, stock value, portal stock view |
| Movements | receiving and returns | return rate, receiving performance |
Pricing, margins, payroll data and end-customer data beyond name and delivery address don't need to be delivered. Running the operation doesn't need them, so they're not in the schema.
How the data reaches us.
Two routes, you pick the one that fits your system. Both are equal, and neither needs anything installed on your side.
CSV over SFTP
Your system, or a scheduled database export, drops eight files into a directory. max.dash picks them up. That's the route for anything that can produce a reporting or database export - and that's practically every warehouse system, which is exactly why this is called 3PL reporting without API.
REST push
Your system sends the datasets to an endpoint on its own. The route for in-house builds that already run their own interface layer - usually a matter of a few hours of work on your side.
The hard schema validation is deliberate. An import that silently skips broken rows produces reporting that looks plausible and is wrong - and nobody notices. Better a rejected delivery with a line number than an SLA rate that was too good for three days.
What you get from it.
The full feature set. The difference against a direct connection is latency, not capability - this is a warehouse KPI dashboard built from a CSV import, not a reduced version of one.
Scroll table sideways
| Capability | Via the import | Built from |
|---|---|---|
| SLA rate per client | yes | shipments, delivery notes, brands |
| Throughput and daily forecast | yes | shipments, open orders |
| Labor report per person | yes | shipments with handler, staff |
| Points system by parcel content | yes | lines |
| Client portal | yes | brands as the dividing line |
| Billable volumes | yes | shipments, movements |
| Cover and stock value | yes | stock |
| Returns and receiving | yes | movements |
What the import can't do: run the live monitor on the wall screen to the minute. Deliver hourly, and you see hours. For SLA tracking, billing, labor reporting and the client portal that has no consequence at all - those are day and month figures, not minute figures.
Who this route reaches.
Anything that can export. In practice that covers three groups a connector would never reach on its own.
- In-house builds. The warehouse software built in-house over years, with a database that knows everything. Here the import isn't the second choice - it's the only route in, and the fastest one at the same time. This is what in-house WMS analytics usually comes down to.
- Enterprise WMS without a public interface. Systems such as LFS, Infios, PROLAG World, storelogix and comparable platforms all keep a record in their database of who booked what, when. A reporting export out of that database is enough.
- Systems running side by side. When one site runs on one system and another on a second, both land in the same cockpit: one connected directly, one through the import. For the reporting, that difference is invisible.
LFS, Infios, PROLAG World, storelogix and any other enterprise system named on this page are products of their respective vendors. All product and company names are trademarks of their respective owners. They are named solely to state reachability. No partnership, endorsement or certification is implied.
How the connection runs.
Four steps. The effort sits once on your side, then it runs automatically.
Schema and export route
You get the schema description for the eight datasets, with a field list and a sample file. Together we work out which route is simplest inside your system.
First delivery
You deliver historical data once, typically 90 days. That's what the mapping is built against, and completeness gets checked on it.
Rules per client
Cutoff time, working days, public holidays, exclusions - per brand. Plus the mapping of your scanner logins to staff.
Sign-off
One real week is checked against what you already know: volumes, SLA rate and labor performance. Only then does it go live.
Common questions.
Does a CSV file really work?
Yes. Eight files, one defined schema per file, dropped over SFTP or pushed over REST. If your system can export, it can supply max.dash. A reporting export from a database or a scheduled job is enough.
How current are the numbers with an import?
As current as you deliver. An hourly export keeps the numbers hourly current, a nightly one keeps them daily. The app shows visibly which delivery the displayed numbers come from - so nobody mistakes a number for more current than it is.
Am I missing features if I come in through the import?
No. The import carries the full feature set: SLA per client, labor performance per person, the points system, client portal, billable volumes, cover, returns and receiving. The difference to a direct connection is latency, not scope.
What happens if a file is faulty?
The import validates the schema hard and rejects a faulty delivery rather than processing it halfway. You get the error back with line and field. The last valid state stays in place - no silent gaps appear in the reporting.
How much effort is this on my side?
Setting up the eight exports once, then it runs automatically. Anyone already pulling reporting exports from their system usually builds on what's there. We supply the schema description and check the first deliveries together with you.
What if my system gets an interface later?
Then we switch the data route and hours of latency become minutes. Nothing changes in your reporting, clients or portal logins - the definitions live in max.dash, not in the data route.
Send us what your system can export.
30 minutes, no commitment. We'll show you on your own export file what it becomes - and what's still missing.