Funktionen

Systemintegrationen & API

Heute liefert Logistiq genau eine Maschinenschnittstelle aus — die schlüsselgeschützte, ratenbegrenzte Gate-Device-API — plus ein Self-Service-Portal für Frachtführer, über das Frachtführerdaten ohne Dateiaustausch hereinkommen. Die API für TMS, WMS und ERP steht auf der Roadmap, und diese Seite sagt das so, statt es schönzureden.

Demo anfordern Preise

Heute eine Maschinen-API, eine Partner-API auf der Roadmap

Bevor Sie nach einem Konnektor fragen

Die meisten Hofdaten kommen noch per E-Mail, Telefon und Abtippen

Das Pförtnerhaus arbeitet mit einer ausgedruckten Liste und einem Anruf ins Büro. Der Frachtführer mailt am Vortag eine Ankunftstabelle, ein Disponent tippt sie in eine Buchung ab, und das Kennzeichen wird an der Schranke noch zweimal korrigiert. Nichts davon ist ein Technikproblem — es ist ein Erfassungsproblem, jeden Morgen aufs Neue, bezahlt mit Disponentenstunden und Standzeiten.

Logistiq setzt an der Datenerfassung selbst an, statt Ihre Systeme zu verdrahten. Frachtführer registrieren sich in ihrem eigenen Portal und pflegen ihre Firmen, Fahrer, LKW und Auflieger selbst — die Daten werden also einmal von der Partei erfasst, die sie tatsächlich kennt. Fahrer erledigen den Check-in über qrgo.ro oder die QRGO Driver App. Buchungen führen ein Feld external_reference, das für die Sendungs-ID Ihres eigenen Systems gedacht ist. So bleiben beide Datensätze heute per Sichtprüfung abgleichbar — und maschinenlesbar an dem Tag, an dem es eine API gibt, die sie ausliest. Und das Tor ist bereits Maschine-zu-Maschine: Ein QRGOBox-Gerät ruft die API mit einem organisationsgebundenen Schlüssel auf, und die Schranke öffnet bei gültigem Check-in-Code.

Ohne Logistiq

Der Frachtführer mailt die Ankünfte von morgen als Tabelle
Ein Disponent tippt Fahrer-, LKW- und Aufliegerdaten von Hand ab
Das Pförtnerhaus ruft im Büro an, um eine erwartete Ankunft zu bestätigen
Ihre Sendungs-ID steht auf Papier, weit weg vom Hofdatensatz

Mit Logistiq — heute

Frachtführer registrieren sich selbst und pflegen ihre Fahrer, LKW und Auflieger
Der Fahrer erledigt den Check-in über qrgo.ro oder die QRGO Driver App
Ein QRGOBox-Gerät prüft den Check-in-Code gegen die API und öffnet die Schranke
bookings.external_reference hält die Sendungs-ID Ihres eigenen Systems

Die eine Maschinenschnittstelle, die live ist: die Gate-Device-API

Sechs Endpunkte auf logistiq.cloud, authentifiziert über einen einzigen Schlüssel je Organisation. Das ist Geräteauthentifizierung für QRGOBox-Schrankenhardware — sie stellt Tore, Heartbeat und die Prüfung von Check-in-Codes bereit und nichts zu Buchungen, Check-ins, Rampen oder Auswertungen.

Live-Endpunkte: 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
Authentifizierung: Ein Schlüssel je Organisation, Format org_ gefolgt von 32 Hex-Zeichen. Übergabe als X-API-Key-Header bei /api/device/gates, als api_key im JSON-Body bei den POST-Routen und als Query-Parameter ?api_key= bei GET /api/gate/list.
Der Tor-Aufruf: POST /api/gate/validate mit { gate_id, api_key, checkin_code }. Der Schlüssel selbst bestimmt den Mandanten — es wird keine Organisations-ID mitgesendet, und ein Schlüssel sieht ausschließlich sein eigenes Lager.
Öffnet für: Check-ins im Status confirmed, assigned oder in_progress. Alles andere wird an der Schranke abgewiesen und als gate_entry_denied in die Timeline geschrieben.
Rate-Limit: 30 Anfragen pro 60 Sekunden auf den vier Routen des Device-Buckets, 60 pro 60 Sekunden auf Heartbeat und Gate-Liste, gezählt in gemeinsam genutztem Redis, damit das Limit über alle Serverless-Instanzen hinweg greift.
Schlüssel-Lebenszyklus: Erzeugen, kopieren und neu generieren unter Einstellungen → API-Zugangsdaten (für QRGoBox). Ein Schlüssel je Organisation; ein neu generierter Schlüssel bedeutet, jedes Gerät mit dem alten Schlüssel zu aktualisieren.

Die Objekte, die Ihre Systeme austauschen würden, gibt es bereits

Eine Integration ist immer nur so gut wie die Felder darunter — und die stehen längst im Schema und sind täglich im Einsatz. Eine Buchung führt booking_reference und external_reference für die ID Ihres eigenen Systems, booking_status, type (loading, unloading oder both), scheduled_date mit Start- und Endzeit, transport_company, driver_name und driver_phone, truck_number und trailer_number, eine Ladungskategorie, eine Abteilung sowie extra_references als freies JSON für alles, was an Ihrem Standort anders heißt. Ein Check-in führt dieselben Referenzen plus die zugewiesene Rampe oder den Parkplatz und die komplette Zeitstempelkette: checked_in_at, confirmed_at, assigned_at, started_at, completed_at. Jeder Statuswechsel wird bereits in eine typisierte Timeline geschrieben — created, status_change, ramp_assigned, ramp_unassigned, parking_assigned, department_changed, gate_entry, gate_entry_denied, gate_exit und weitere. Die Substantive stehen, die Ereignisse sind katalogisiert. Was fehlt, ist der Endpunkt, der sie ausliest — und genau das sprechen wir offen aus.

roadmap

Die API für TMS, WMS und ERP ist Roadmap, kein Release

Um genau zu sein: Es gibt heute kein /api/v1, keine OpenAPI-Spezifikation, kein SDK und keine Client-Bibliothek, keine ausgehenden Webhooks und keinerlei EDI oder Dateiaustausch. Eine öffentliche REST-API für Buchungen — Schlüssel je Organisation, Endpunkte für Buchungen, Zeitfenster und Abteilungen sowie Event-Webhooks — ist als geplantes Feature festgehalten und mit „nicht begonnen“ markiert. Wir nennen dazu kein Quartal, denn ein Datum, das wir nicht halten können, ist weniger wert als das Tor, das heute Morgen funktioniert. Wenn Sie ein TMS, WMS oder ERP betreiben, mit dem Logistiq sprechen soll: Sagen Sie uns welches — diese Antwort entscheidet, was zuerst gebaut wird.

Integrationsfragen, klar beantwortet

Nein. Die einzige Maschine-zu-Maschine-API im Produkt ist die Gate-Device-API, und sie existiert, um QRGOBox-Schrankenhardware zu authentifizieren: Tore, Heartbeat und Prüfung von Check-in-Codes. Sie stellt nichts zu Buchungen, Check-ins, Rampen oder Auswertungen bereit. Eine öffentliche REST-API für Buchungen ist intern spezifiziert und als „nicht begonnen“ markiert. Das sagen wir lieber, als Ihnen einen Endpunkt zu verkaufen, der nicht antwortet.

Nein, nichts davon. Es gibt kein EDIFACT, X12 oder AS2, kein SFTP und keinen Dateiablageordner, keinen Batch-Feed und keinen Export von Buchungen oder Check-ins nach Excel oder CSV. Der einzige Umgang mit Dateien im Produkt ist eine Person, die eine .xlsx in den Daten-Tab einer einzelnen Buchung zieht — eine formfreie Tabelle, angehängt an genau diesen einen Datensatz. Frachtführerdaten kommen stattdessen über das Frachtführerportal herein.

Die Frachtführer tragen sie selbst ein. Ein Transportunternehmen legt sein eigenes Konto an, Sie laden es einmal ein, und von da an pflegt es seine Fahrer, LKW und Auflieger selbst. Der Fahrer erledigt den Check-in über qrgo.ro oder die QRGO Driver App, in seiner eigenen Sprache. Die Daten werden einmal von dem erfasst, der sie tatsächlich kennt, und landen nie als Tabelle im Postfach eines Disponenten.

Nein, darüber rechnen wir mit Ihnen ab. Stripe wickelt das Abonnement ab, SmartBill stellt die rumänische Rechnung dazu aus. Keines von beiden berührt Ihre Buchhaltung, Ihr ERP oder Ihre Hofdaten, und keines ist offengelegt, damit Sie etwas daran anschließen. Verstehen Sie sie als unsere Dienstleister, nicht als Konnektoren auf Ihrer Seite des Zauns — der Unterschied zählt, und wir werden ihn nicht verwischen.

Bereit, Lagerablaufe zu transformieren?

Schliessen Sie sich Hunderten von Lagern an, die Effizienz gewahlt haben. Kostenlose Demo, schnelle Einrichtung, keine Verpflichtungen.

Kostenlose Demo anfordern