Home / Documentation / Integration
Documentation 03
An integration list is only useful if the things on it exist. Everything below is in the product today; things we intend to build are named as such.
A scanner or a warehouse device authenticates with a key issued for that facility, which you can revoke at any time without touching anything else. Devices post what they see — a scan, a position, a reading — and nothing about the integration requires the device to be one we sell.
If your vehicles report to a telematics platform, those positions can flow into Cargovate so a shipment's location comes from the same feed your drivers already generate — rather than from a second tracker stuck to the same pallet.
Orders, parties and stock come in from the export your ERP already produces. What we deliberately do not do is write back into it.
That is a limit we choose. Writing into a customer's ERP makes us a participant in their change control, their audit scope and their outages, and the failure mode is a corrupted production system at a site we cannot log into. If data needs to flow back, we produce an export your integration team consumes on their own terms — the same asymmetry, pointed the other way, with responsibility sitting where the system does.
Everything the interface does is available over a documented HTTP API, authenticated per organisation. Teams commonly use it to push checkpoints from an existing operational system, or to pull the movement history of a consignment into their own reporting.
Direct ERP connectors, EDI transaction sets, and label or automation hardware are all things we know how to build and have not shipped as products. If one of them is a condition of your operation working, say so early and it becomes defined work with a date — rather than a logo on a slide that turns into a discovery call six weeks in.
