#Änderungsprotokoll

Neueste Änderungen zuerst. Was eine Änderung für bestehende Anbindungen heißt, steht jeweils dabei (Versionsregeln).

#24.09.2026

Geändert

• Fehler der API v1 als Problem Details nach RFC 9457: Medientyp application/problem+json, die Felder type, title, status, detail, instance, code und requestId stehen oben im Objekt, statt in { "error": { … } } (Fehler und Grenzen). Die Codes sind dieselben; type ist die URI des Codes und führt zu seiner Beschreibung.
• Feldfehler stehen in errors statt details.fields bzw. details.errors, je Feld mit JSON Pointer (pointer: #/pickup/postalCode) oder, für Pfad und Abfrage, mit parameter; statt message heißt es detail.
• Was ein Code zusätzlich mitgibt, steht als eigenes Feld: required/granted, currentVersion, allowed, reason, limit/windowSeconds. Der Stand eines entschiedenen Angebots heißt quoteStatus (vorher details.status), der vorhandene Vorgang bei EXTERNAL_ORDER_ID_EXISTS steht in existing (kind, id, Nummer).
• Auch Wartung (503 MAINTENANCE), gesperrte Absenderadressen (403 IP_BLOCKED), ungültiges JSON, zu große Anfragen, ein Rumpf in unbekanntem Zeichensatz oder unbekannter Kodierung (415 UNSUPPORTED_MEDIA_TYPE, neu) und ein unlesbarer Rumpf (400 INVALID_REQUEST) — die letzten beiden vorher 500 — antworten an der API v1 in diesem Format.
• Der Token-Endpunkt antwortet weiter nach OAuth 2.0 (error, error_description, application/json) und trägt zusätzlich die Felder eines Problems — jetzt bei jeder Absage, auch bei Drosseln, Wartung und gesperrter Adresse (Token-Endpunkt).
• Die bisherige Schnittstelle antwortet auch dort in ihrem eigenen Format ({ "error": "CODE", "message", "requestId" }), wo bisher das Format der API v1 durchkam: bei einer Methode, die es an /extern/transportauftraege nicht gibt (UNAUTHORIZED, NOT_FOUND), und bei einem Fehler auf unserer Seite (INTERNAL).

Für bestehende Anbindungen: Wer Fehler der API v1 auswertet, liest code jetzt oben im Objekt statt unter error.code. Das ist die einmalige Ausnahme von den Versionsregeln, bewusst vor der ersten festen Anbindung. Die bisherige Schnittstelle /extern/transportauftraege bleibt, wie sie ist — bis auf die zwei Randfälle eben.

#23.09.2026

Neu

• API v1 für Aufträge unter /api/v1/extern/orders: anlegen mit strukturierten Orten, Fahrzeug, Transportart und Zulassung; lesen und suchen (externalOrderId, updatedSince); ändern und stornieren bis zur Abholung; Stand, Sendungsverfolgung und Dokumente (Endpunkte, Auftrag anlegen).
• OAuth 2.0 Client Credentials unter /api/v1/extern/oauth/token und Rechte je Zugang wie orders:write oder webhooks:manage (Anmeldung und Rechte).
• Wiederholungen ohne Doppel mit Idempotency-Key: derselbe Aufruf ergibt dieselbe Antwort, ein anderer Inhalt 409 (Wiederholungen).
• Ein Fehlerformat für die API v1: { "error": { "code", "message", "requestId", "details" } }, die requestId auch im Kopf X-Request-Id (Fehler und Grenzen).
• Ereignisse der API v1: zwanzig Ereignisse vom Auftrag bis zur Rechnung (Ereignisse), im Umschlag mit type, apiVersion (2026-09-01), createdAt und tenantId. Jedes entsteht in derselben Datenbanktransaktion wie die Änderung, die es auslöst — auch auf Wegen, die bisher keine Nachricht verschickten, etwa Statuswechsel aus dem Übergabeprotokoll oder der Disposition.
• Webhook-Endpunkte über die API: /api/v1/extern/webhook-subscriptions mit dem Recht webhooks:manage (Über die API anlegen).
• Umstellen eines Endpunkts vom bisherigen Format auf die API v1 im Portal — Adresse und Geheimnis bleiben.
• Angebote über die API: POST /quotes fordert ein Angebot an, GET /quotes/{id} zeigt es samt PDF, POST /quotes/{id}/decline lehnt es ab, POST /quotes/{id}/accept nimmt es an — Letzteres nur, wenn Ihre Vereinbarung es vorsieht (Angebote).
• Sandbox-Steuerung der API v1: POST /sandbox/orders/{id}/advance, mit Token oder Schlüssel (Szenarien).

Geändert

• GET /extern/me antwortet im Format der API v1: Konto, Zugang mit Rechten, Anmeldeart und Umgebung.
• Die bisherige Schnittstelle prüft die Rechte des Schlüssels. Bestehende Schlüssel haben orders:read und orders:write — für sie ändert sich nichts.
• Diese Dokumentation beschreibt die API v1; die bisherige Schnittstelle steht unter Bisherige Schnittstelle.
• Neue Endpunkte bekommen immer das Format der API v1, im Portal wie über die API. Sie bekommen nur noch die Köpfe X-LogiCar-*.
• Der Test-Empfänger der Sandbox zeigt die Ereignisse der API v1; die Szenarien schicken sie an Sandbox-Endpunkte der API v1.
• Sandbox, Szenario QUOTE_REQUIRED: Das simulierte Angebot trägt einen Preis (ohne Strecke für 300 km), und der Testauftrag übernimmt genau diesen Preis.
• 409 REQUEST_HAS_QUOTE nennt den Weg: das Angebot mit POST /quotes/{id}/decline ablehnen.

Für bestehende Anbindungen: /extern/transportauftraege bleibt, wie es ist. Wer GET /extern/me auswertet, liest die neue Form. Webhook-Endpunkte, die vor dem 23.09.2026 angelegt wurden, bekommen unverändert das bisherige Format mit X-Webhook-Signature — bis Sie sie umstellen.

#22.09.2026

Neu

• Sandbox: Testschlüssel lc_test_… führen in einen eigenen Testspeicher mit simulierten Abläufen — Standard, Verspätung, Schaden, Storno, Angebot. Steuerbar über X-Sandbox-Scenario und X-Sandbox-Mode sowie die Endpunkte unter /extern/sandbox/… (Sandbox).
• Test-Empfänger für Webhooks ohne eigenen Server (Test-Empfänger).
• GET /extern/me zum Prüfen des Zugangs.
• Webhooks: Signatur mit Zeitstempel (X-LogiCar-Signature über <Timestamp>.<Rumpf>), Umgebung und Zustellkennung in Kopf und Umschlag, Wiederholungen nach festem Plan bis 24 Stunden, Protokoll mit „erneut senden“ und Testnachricht.
• Schlüssel zeigen ihre Umgebung im Präfix: lc_live_ oder lc_test_. Jede Antwort trägt X-LogiCar-Environment.
• Diese Dokumentation mit OpenAPI-Beschreibung.

Geändert

• Auswahlfelder (vehicleType, fuelType, transportMode, …), Zeitpunkte und das Baujahr werden geprüft. Ein falscher Wert ergibt jetzt 400 INVALID_INPUT mit Feldname und erlaubten Werten statt eines Serverfehlers — in Sandbox und Echtbetrieb gleich.
• Webhook-Adressen müssen öffentlich per HTTPS erreichbar sein; Weiterleitungen werden nicht verfolgt.
• Fehlerantworten der Schnittstelle tragen eine requestId.

Entfernt

• Die Ereignisse marketplace.published, marketplace.bid_placed und marketplace.bid_accepted. Sie gingen an Auftraggeber, obwohl sie Daten der Vergabe an Fahrer enthielten. Die Vergabe erfahren Sie weiter als Statuswechsel (order.status_changed). Endpunkte, die sie abonniert hatten, bekommen die übrigen Ereignisse unverändert.

Für bestehende Anbindungen: X-Webhook-Signature und X-Webhook-Delivery-ID kommen weiterhin. Webhook-Geheimnisse bleiben gültig.