Features
Systems Integrations & API
Today Logistiq ships one machine surface — the keyed, rate-limited gate device API — plus a carrier self-service portal that gets carrier data in without file exchange; the API for TMS, WMS and ERP systems is on the roadmap, and this page marks it as such rather than dressing it up.
One machine API today, a partner API on the roadmap
Today Logistiq ships one machine surface — the keyed, rate-limited gate device API — plus a carrier self-service portal that gets carrier data in without file exchange; the API for TMS, WMS and ERP systems is on the roadmap, and this page marks it as such rather than dressing it up.
Most yard data still arrives by e-mail, phone call and re-typing
The gatehouse runs on a printed list and a phone call to the office. The carrier e-mails an arrival spreadsheet the day before, a dispatcher re-types it into a booking, and the plate number gets corrected twice more at the barrier. None of that is a technology problem — it is a data-entry problem, repeated every morning, paid for in dispatcher hours and truck idling.
Logistiq attacks the data entry at the source instead of wiring your systems together. Carriers register in their own portal and keep their companies, drivers, trucks and trailers current themselves, so the data is typed once by the party who actually knows it. Drivers file the check-in from qrgo.ro or the QRGO Driver app. Bookings carry an external_reference field built to hold your own system's shipment ID, so the two records stay reconcilable by eye today — and machine-readable the day an API exists to read them out. And the gate is already machine-to-machine: a QRGOBox device calls the API with an organisation-scoped key, and the barrier lifts on a valid check-in code.
Without Logistiq
- The carrier e-mails tomorrow's arrivals as a spreadsheet
- A dispatcher re-types driver, truck and trailer details by hand
- The gatehouse phones the office to confirm a truck is expected
- Your shipment ID lives on paper, nowhere near the yard record
With Logistiq today
- Carriers self-register and maintain their own drivers, trucks and trailers
- The driver files the check-in from qrgo.ro or the QRGO Driver app
- A QRGOBox device validates the check-in code against the API and opens the barrier
- bookings.external_reference holds your own system's shipment ID
The one machine surface that is live: the gate device API
Six endpoints on logistiq.cloud, authenticated by a single per-organisation key. This is device authentication for QRGOBox barrier hardware — it exposes gates, heartbeat and check-in-code validation, and nothing about bookings, check-ins, ramps or analytics.
- Live endpoints
- GET /api/device/gates · POST /api/device/heartbeat · POST /api/device/validate-api-key · POST /api/device/validate-key · POST /api/gate/validate · GET /api/gate/list
- Authentication
- One key per organisation, format org_ followed by 32 hex characters. Sent as the X-API-Key header on /api/device/gates, as api_key in the JSON body on the POST routes, and as an ?api_key= query parameter on GET /api/gate/list.
- The gate call
- POST /api/gate/validate with { gate_id, api_key, checkin_code }. The key itself resolves the tenant — no organisation ID is sent, and a key can only ever see its own warehouse.
- Opens for
- Check-ins in status confirmed, assigned or in_progress. Anything else is refused at the barrier and written to the timeline as gate_entry_denied.
- Rate limit
- 30 requests per 60 seconds on the four device-bucket routes, 60 per 60 seconds on heartbeat and gate list, counted in shared Redis so the limit holds across every serverless instance.
- Key lifecycle
- Generate, copy and regenerate under Settings → API Credentials (for QRGoBox). One key per organisation; regenerating it means updating every device that uses the old one.
The objects your systems would exchange already exist
An integration is only ever as good as the fields underneath it, and those are already in the schema and in daily use. A booking carries booking_reference and external_reference for your own system's ID, booking_status, type (loading, unloading or both), scheduled_date with a start and end time, transport_company, driver_name and driver_phone, truck_number and trailer_number, a cargo category, a department, and extra_references as free-form JSON for whatever your site calls things. A check-in carries the same references plus the assigned ramp or parking spot and the full timestamp chain: checked_in_at, confirmed_at, assigned_at, started_at, completed_at. Every state change is already written to a typed timeline — created, status_change, ramp_assigned, ramp_unassigned, parking_assigned, department_changed, gate_entry, gate_entry_denied, gate_exit and more. The nouns are settled and the events are catalogued. What is missing is the endpoint that reads them out, and that is the part we say out loud.
roadmap
The TMS, WMS and ERP API is roadmap, not release
To be exact about it: there is no /api/v1 today, no OpenAPI specification, no SDK or client library, no outbound webhooks, and no EDI or file exchange of any kind. A public REST API for bookings — per-organisation keys, endpoints for bookings, slots and departments, and event webhooks — is written down as a planned feature and marked not started. We are not putting a quarter on it, because a date we cannot back is worth less than the gate that works this morning. If you run a TMS, WMS or ERP you want Logistiq to talk to, tell us which one: that answer decides what gets built first.
Integration questions, answered plainly
No. The only machine-to-machine API in the product is the gate device API, and it exists to authenticate QRGOBox barrier hardware: gates, heartbeat, and check-in-code validation. It exposes nothing about bookings, check-ins, ramps or analytics. A public REST API for bookings is specified internally and marked not started. We would rather say that than sell you an endpoint that does not answer.
No, to all of it. There is no EDIFACT, X12 or AS2, no SFTP or file drop, no batch feed, and no export of bookings or check-ins to Excel or CSV. The only file handling in the product is a person dragging an .xlsx into the Data tab of one booking — a free-form spreadsheet attached to that single record. Carrier data comes in through the carrier portal instead.
Carriers put it in themselves. A transport company creates its own account, you invite it once, and it maintains its own drivers, trucks and trailers from then on. The driver files the check-in from qrgo.ro or the QRGO Driver app, in their own language. The data is typed once by whoever actually knows it, and never lands as a spreadsheet in a dispatcher's inbox.
No, those are how we bill you. Stripe runs the subscription and SmartBill issues the Romanian invoice for it. Neither touches your accounting, your ERP or your yard data, and neither is exposed for you to connect anything to. Read them as our vendors, not as connectors on your side of the fence — the distinction matters and we are not going to blur it.
Everything you need for an efficient warehouse
Digital Check-in
On arrival, the driver scans the QR code or accesses the warehouse in the QRGO Driver app. Fills in the data and receives confirmation. No papers, no queues.
Dock Management
Operators allocate, release and optimize truck flow from a single dashboard.
Real-time Chat & Notifications
Instant chat between operator and driver, push notifications on phone, and SMS options. Clear communication, regardless of the platform used by the driver.
Ready to transform warehouse operations?
Join hundreds of warehouses that chose efficiency. Free demo, quick setup, no obligations.