API-Änderungsprotokoll

Neues Produkt lane-cost-index (GET /api/v2/data/lane-cost-index). Es liefert den Kostenindex einer beladenen Lkw-Fahrt von A nach B in Europa: Kraftstoff, Maut, Fahrerzeit und Spesen.

• Eingabe: from und to als "lat,lng" oder Stadt-ID, vehicle (zum Beispiel artic_40t), optional euro, co2_class und empty_return.
• Pro Land: km, Maut, Diesel in Litern und Kraftstoffkosten (netto ohne MwSt.) sowie die berechnete Maut-Fahrzeugklasse.
• Fahrerzeit: Lenkzeiten, Pausen und Ruhezeiten folgen der EU-Verordnung 561/2006. Fahrerkosten und Spesen nutzen den Satz des Ursprungslandes. Spanien und Italien haben jetzt einen Fahrersatz und Spesen aus den Tarifverträgen.
• Trend: trend liefert den Kostenindex des aktuellen und der zwei vorherigen Monate.
• Unvollständige Daten: wenn für ein Land auf der Route keine Maut- oder Kraftstoffdaten vorliegen oder für das Ursprungsland kein Fahrersatz hinterlegt ist, ist incomplete gleich true und die Summe ist eine Untergrenze. missing_countries und missing_components zeigen, was fehlt.

Dies ist ein Kostenindex, kein Frachtpreis: Fahrzeugkapital, Versicherung, Gemeinkosten und Marge sind nicht enthalten.

Kontingent: eine Anfrage zählt als 1 Einheit der Klasse route, wie bei truck-route.

Dokumentation: Lane Cost Index.

Das Produkt toll-cost berechnet Frankreich, Spanien und Italien jetzt genauer.

• Frankreich und Spanien: ein Autobahnabschnitt zwischen zwei Mautstellen auf der Route wird nach dem Ein-/Ausfahrtstarif des Autobahnbetreibers berechnet. Er erscheint als neuer Positionstyp motorway_section mit Betreiber oder Straße, den beiden Mautstellen, toll_km und cost_eur. Die übrigen mautpflichtigen km des Landes nutzen weiter den Durchschnittssatz pro km.
• Fahrzeugklasse: Frankreich: Klasse 3 für 2 Achsen und Klasse 4 für 3 oder mehr Achsen. Spanien: Pesados 1 für 2 oder 3 Achsen und Pesados 2 für 4 oder mehr Achsen.
• Italien: Lkw mit 2 und 3 Achsen haben jetzt eigene km-Sätze.
• Euro- und CO2-Klasse: die Tarife in Frankreich, Italien und Spanien hängen nicht von diesen Klassen ab. Wenn Sie euro oder co2_class senden, ist class_fallback für diese Länder false und class_note nennt den Grund.
• Keine Mautstraße: eine Route in Spanien ohne Mautstraße (zum Beispiel Saragossa–Barcelona) liefert Spanien mit cost_eur 0 und scheme not_tolled.

Andere Länder ändern sich nicht. Dokumentation: Truck Toll Cost.

Neues Produkt toll-cost (POST /api/v2/data/toll-cost, JSON-Body). Es liefert die Lkw-Mautkosten einer Route durch Europa.

• Eingabe: die Routenlinie als coordinates (zum Beispiel die Geometrie aus truck-route) oder waypoints, die wir mit unserem Lkw-Routing berechnen.
• Fahrzeug: axles, gross_weight_t, euro und co2_class. Optional date für die Tarife und currency für die Gesamtsumme.
• Pro Land: mautpflichtige km, effektiver EUR-Satz pro km, Kosten, die berechnete Fahrzeugklasse und das Tarifdatum. Sätze für eine bestimmte Euro- und CO2-Klasse werden verwendet, wo ein amtlicher Tarif für diese Klasse vorliegt. Sonst wird der Satz der Standardklasse verwendet und class_fallback ist true.
• Eigene Posten: Autobahn-Konzessionsabschnitte sowie Tunnel und Brücken mit eigener Lkw-Maut (zum Beispiel Calafat-Widin).

Kontingent: eine Anfrage zählt als 1 Einheit der Klasse route, wie bei truck-route.

Dokumentation: Truck Toll Cost.

Zwei neue Produkte unter /api/v2. Für eine Busfahrt zeigen sie, welche Seite Sonne oder Schatten hat und welche Plätze am besten für Schatten oder Aussicht sind.

• bus-sun-side (/api/v2/data/bus-sun-side), GET: eine Route aus unserem Busrouten-Register (route_id, dir, date) oder eine freie Fahrt (from, to, depart).
• bus-sun-side, POST: senden Sie Ihre eigene Route als Liste von Haltestellen, als GeoJSON-Linie oder als kodierte Polylinie. Fügen Sie Busparameter hinzu (Reihen, Sitzanordnung, Türseite, Fenster, Deck) oder wählen Sie ein Modell aus dem Katalog mit bus_model.
• Wetter: Für Fahrten in den nächsten 3 Tagen wird die stündliche Vorhersage entlang der Route verwendet. Spätere Fahrten werden für klaren Himmel berechnet. Senden Sie weather=0, um immer das Ergebnis für klaren Himmel zu erhalten.
• Bilder (POST): Sitzplan, Routenkarte und Zeitleiste als URLs im Format PNG, WebP oder JPG. Die Bilder werden 12 Stunden gespeichert. Sie erhalten auch embed_html, um das Ergebnis auf Ihrer Seite einzubinden. Bild-URLs beginnen mit https://api.nakordoni.dev/images/.
• Animation: Der Block animation enthält alle 5 Minuten ein Bild mit Busposition, Fahrtrichtung, Sonnenazimut und Sonnenhöhe sowie der Sonnenseite, mit Beschriftungen in Ihrer Sprache, Summen pro Seite und einer Legende. Senden Sie animation=0, um ihn wegzulassen.
• Widget: Zeigen Sie das Ergebnis auf jeder Website an, auch in WordPress, mit einem Script-Tag oder einem iframe. Das Widget nutzt einen öffentlichen Schlüssel, der nur auf den von Ihnen erlaubten Origins funktioniert, und unsere eigenen Kartenkacheln. Ein WordPress-Plugin (ZIP) ist verfügbar.
• bus-sun-catalog (/api/v2/data/bus-sun-catalog): die Busmodelle, die bus-sun-side akzeptiert, mit Sitzanordnung und Fenstern.

Kontingent: Eine POST-Anfrage mit Bildern zählt als 2 Einheiten. Alle anderen Anfragen zählen als 1 Einheit.

Doku: Bus Sun Side.

fleet-compliance-validate deckt jetzt mehr von der VO (EG) 561/2006 in der Fassung der Verordnung (EU) 2020/1054 ab. Bestehende Antwortfelder ändern sich nicht; neue Felder kommen hinzu.

• Ausnahme nach Art. 12: Markieren Sie Lenktätigkeiten mit art12_exceed: true. In Ausnahmefällen darf ein Fahrer die täglichen und wöchentlichen Lenkzeitgrenzen um bis zu 1 Std. überschreiten, um das Betriebszentrum oder seinen Wohnort für eine wöchentliche Ruhezeit zu erreichen, oder um bis zu 2 Std. nach einer Pause von 30 Min., wenn eine regelmäßige wöchentliche Ruhezeit folgt. Der Validator akzeptiert dies und gibt den geschuldeten Ausgleich und dessen Frist (das Ende der dritten Woche danach) in remaining.driving.art12_compensation und exceptions.art12 zurück.
• Art. 8(8a) Rückkehr zum Standort: Senden Sie location (residence, operational_centre oder elsewhere) bei wöchentlichen Ruhezeiten. Sie erhalten eine Warnung, wenn in 4 aufeinanderfolgenden Wochen keine regelmäßige wöchentliche Ruhezeit zu Hause oder im Betriebszentrum stattgefunden hat.
• Art. 8(6a) 12-Tage-Ausnahme: passenger_12day: true für eine einzelne gelegentliche internationale Reisebusfahrt. Die wöchentliche Ruhezeit darf dann bis zu zwölf 24-Stunden-Zeiträume nach einer regelmäßigen wöchentlichen Ruhezeit beginnen. Die darauf folgenden Ruhezeiten und das Fahren in der Nacht (22:00-06:00) werden geprüft. AETR Art. 8(6)(b) wird auf dieselbe Weise angewendet.
• Nationale Nachtzeitfenster (Richtlinie 2002/15/EG Art. 3(h)): Verwenden Sie country oder wtd.country, um den nationalen Nachtzeitraum anzuwenden. Geprüft: AT, IE (Fahrgäste separat) und SE. Andere EU/EWR-Länder verwenden 00:00-04:00 und liefern night_window_verified: false.
• fleet-compliance-limits: AETR listet nun die geprüften Änderungen nach 2010 auf. Sie betreffen nur Artikel 14, nicht die Lenk- oder Ruhezeitregeln.

Dokumentation: Fleet Compliance.

Vier neue Produkte, bereitgestellt über /api/v2 und berechnet von unserer eigenen Feiertagsregel-Engine für 51 Länder (Europa und der Golf: SA, AE, QA, KW, BH, OM), 2020–2035:

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — gesetzliche, Bank-, regionale und religiöse Feiertage sowie Gedenktage für bis zu 10 Länder in einem Jahr oder einem Datumsbereich. Zu jedem Feiertag wird angegeben, ob er ein freier Tag, ein Bankfeiertag oder innerhalb der Schulferien ist, ob ein auf das Wochenende fallender Feiertag auf einen anderen Tag verschoben wurde, ob ein Datum des islamischen Kalenders noch geschätzt ist und ob an diesem Tag ein Lkw-Fahrverbot gilt (truck_ban). Filterung nach Region (region=DE-BY), Typ, Sprache und Name; school=1 fügt Schulferien hinzu.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — Zählen von Werktagen zwischen zwei Daten, Addieren oder Subtrahieren von Werktagen, Prüfen eines Datums oder Ermitteln des nächsten oder vorherigen Werktags. Berücksichtigt werden das Wochenende des Landes (Samstag–Sonntag bzw. Freitag–Samstag und andere Wochenenden am Golf), nationale und regionale freie Tage sowie per Erlass verschobene Tage.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — die abgedeckten Länder mit Wochenendtagen, Zeitzone, Regionen und Feiertagstypen; mit country= zusätzlich die Arbeitstage pro Jahr und die nächsten fünf Feiertage.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, Pro-Plan und höher) — modellbasierte Schätzung der Geschäftsauswirkungen: ein Impact-Score von 0–100 pro Feiertag, Wahrscheinlichkeit von Ladenschließungen, Nachfragekategorien, Position im langen Wochenende bzw. Brückentag sowie Nachfragespitzen-Zeitfenster. Bei holiday-calendar-holidays erhalten Pro- und höhere Pläne diesen Block ebenfalls mit include=impact und können mit min_impact filtern.

Das bestehende Produkt holiday-calendar bleibt unverändert. Dokumentation: Holiday Calendar.

Drei neue Produkte zur Einhaltung der Lenkzeitvorschriften, bereitgestellt über /api/v2:

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, JSON-Body) — prüft aufgezeichnete Fahreraktivitäten gegen EU 561/2006 oder AETR sowie die Arbeitszeit nach Directive 2002/15/EC. Es liefert jeden Verstoß mit dem Artikel der Vorschrift und der Schweregradstufe sowie das, was dem Fahrer aktuell noch bleibt: tägliche Lenkzeit, die rollierenden Grenzen von 56 h pro Woche und 90 h pro zwei Wochen, die nächste Pause, tägliche und wöchentliche Ruhezeit. Abgedeckt sind aufgeteilte Pausen, verkürzte und verlängerte Tage, Ausgleich verkürzter wöchentlicher Ruhezeiten, Nachtarbeit, Doppelbesatzung sowie unterbrochene Ruhezeiten auf Fähre oder Zug.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — die Regelparameter für EU 561, AETR (mit seinen Abweichungen von 561) und 2002/15 sowie die Schweregradstufen nach Regulation (EU) 2016/403.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, JSON-Body) — prüft geplante Schichten vor der Disposition auf Lkw-Fahrverbote, gesetzliche Feiertage und Wochenendtage in den Ländern der Fahrt sowie auf die Vorschriften EU 561, AETR und 2002/15. Jede Schicht erhält die früheste zulässige Startzeit.

Dokumentation: Fleet Compliance.

Ab v3 haben Stopps für tägliche und wöchentliche Ruhezeiten die Felder in_vehicle_allowed, accommodation_required und rule (route-plan mit rest_rules=eu561 und truck-route). Die Verordnung (EU) 2020/1054 hat Art. 8 Abs. 8 der EU 561/2006 geändert: Eine regelmäßige wöchentliche Ruhezeit und jede wöchentliche Ruhezeit von mehr als 45 h darf nicht im Fahrzeug verbracht werden. Für diese Stopps ist in_vehicle_allowed = false. Eine reduzierte wöchentliche Ruhezeit (24 h bis unter 45 h) und tägliche Ruhezeiten dürfen in einem stehenden Fahrzeug mit Schlafmöglichkeit verbracht werden.

Stopps für wöchentliche Ruhezeiten haben außerdem accommodation[] — Parkplätze mit Zimmern vor Ort in der Nähe des Stopps —, und der Parkplatz des Stopps hat has_accommodation. Das ist nur eine Information: Der Stopp, seine Zeit und sein Lkw-Parkplatz ändern sich nicht. Ist kein Ort mit Zimmern bekannt, hat der Stopp warning = no_accommodation_found. Antworten von v1 und v2 ändern sich nicht.

Tankstellenpreise in /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local und /api/v2/data/fuel mit mode=nearest haben jetzt ein Höchstalter von 90 Tagen. Ein Preis, den wir zuletzt vor mehr als 90 Tagen bestätigt haben, wird nicht mehr ausgegeben. Bisher wurde ein solcher Preis mit stale = true ausgegeben.

Was sich in den Antworten ändert: Eine Sorte, die nur einen älteren Preis hat, fehlt in prices; eine Tankstelle ohne verbleibenden Preis wird nicht aufgeführt oder hat ein leeres prices-Objekt, wo Tankstellen ohne Preis angezeigt werden; und eine Antwort kann leer sein, wo sie bisher alte Preise enthielt. Eine leere Antwort enthält wie bisher empty_reason. fuel-local kann dann aus der Regions- oder Landesebene antworten. Das Flag stale ist unverändert: Es ist true, wenn ein Preis zuletzt vor mehr als 7 Tagen bestätigt wurde. Die Preishistorie bleibt erhalten. Für fuel-cities, fuel-cost, Landesdurchschnitte und fuel-grades gibt es keine praktische Änderung. Details: Preisalter.

GET /api/v2/data/route-plan erhält in v2 ein erweitertes Stoppmodell (additiv: nichts wurde entfernt oder umbenannt) und in v3 neue Standardwerte (/api/v3/data/route-plan).

v2, additiv. Mit stop_places=1 enthält jeder Halt (Pause, Mahlzeit, Übernachtung, Wochenruhe) places[]: Parkplatz-Kandidaten in einem Fahrzeitfenster um den Halt, jeweils mit name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 und type_rank. Die Suche steuern Sie mit places_before_min, places_after_min, places_radius_km und rest_radius_km; ein Radius über 25 km wird begrenzt und mit der Warnung radius_clamped gemeldet. rest_rules=legacy|eu561 wählt das Ruhezeitmodell, und mit eu561 können Sie Ihren Fahrerstatus senden: driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used und allow_reduced. Neue Stopptypen: ban_wait (mit ban: name, country, from, until) und weekly_rest; eine Wartezeit, die eine Pause oder Ruhezeit ersetzt, ist mit counts_as markiert. Lkw-Ausreisen aus der Ukraine mit elektronischer Warteschlange liefern zusätzlich registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note und registration_url sowie die Warnungen echerha_registration und echerha_wait_unverified.

v3, neue Standardwerte. rest_rules ist standardmäßig eu561; Ortsnamen sind strikt (nur echte Parkplätze und Rastanlagen); die von eCherha veröffentlichte Wartezeit (frische Daten, nicht gekappt) wird als Grenzwartezeit verwendet, und eine Grenzwartezeit zählt als die fällige Pause oder Ruhezeit. v2 behält das alte Ruhezeitmodell und den ursprünglichen Ortsfilter, bestehende Integrationen ändern sich also nicht. Details: Route Planner API.

GET /api/v3/data/truck-route nutzt jetzt die eCherha-Grenzwartezeit. In v3 übernehmen border_crossings[] für Lkw-Spuren bei der Ausreise aus der Ukraine mit elektronischer Warteschlange wait_min aus der von eCherha veröffentlichten Wartezeit (nur frische Daten, nicht gekappt; bei veralteten Daten ist wait_min gleich null und die Warnung echerha_wait_unverified wird ergänzt) und enthalten registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note und registration_url, mit der Warnung echerha_registration.

Der Ruhezeitplan behandelt eine Grenzwartezeit als am Grenzübergang verbrachte Zeit: Eine lange Warteschlange zählt als die fällige Pause, tägliche oder wöchentliche Ruhezeit (counts_as in der Zeile waits[]), statt obendrauf addiert zu werden. v2 bleibt unverändert. Details: Truck Route API.

Wenn /api/v2/data/fuel-stations oder /api/v2/data/fuel-cheapest keine Tankstelle findet, lautet die Antwort weiterhin HTTP 200 mit leerer Liste und nennt jetzt den Grund. Nur bei einer leeren Antwort enthält data die Felder empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type oder no_fresh_price_in_radius), nearest_station_km (die nächste Tankstelle mit Ihrer Sorte, gesucht bis nearest_search_km = 50 km; null, wenn keine), country und suggestion — ein kurzer Satz in Ihrer lang, zum Beispiel: Keine Tankstelle innerhalb von 5 km — die nächste ist 6,4 km entfernt; versuchen Sie radius_km=10.

Verzweigen Sie Ihren Code anhand von empty_reason und nearest_station_km. suggestion ist ein Hinweis für Menschen, und sein Wortlaut kann sich ändern. Wir vergrößern den Radius nie für Sie. Wenn Sie ein Gebiet oder eine Route im Raster abtasten, verwenden Sie radius_km 10–15. Antworten mit Tankstellen bleiben unverändert. Details: Leere Antworten.

Suchradius. radius_km bei /api/v2/data/fuel-stations behält jetzt eine Dezimalstelle. Ein Radius wie 4.8 wurde bisher ohne Hinweis auf 4 gekürzt, sodass jede Suche bis zu ein Drittel weniger Fläche abdeckte als angefragt und weniger oder keine Tankstellen liefern konnte. anchor.radius_km zeigt den tatsächlich angewendeten Radius; ganze Zahlen werden wie bisher zurückgegeben.

Markennamen. Dieselbe Marke wird in brand jetzt immer gleich geschrieben — zum Beispiel werden ORLEN und orlen als Orlen und CircleK als Circle K zurückgegeben. Tankstellen, Preise, IDs und Felder bleiben unverändert. Wenn Sie Marken per exakter Schreibweise zuordnen (für Logos oder Filter), prüfen Sie bitte Ihre Liste anhand der neuen Namen.

GET /api/v2/data/truck-route akzeptiert einen neuen optionalen Parameter traffic. Er legt fest, wie der Verkehr in ETA, Ruhezeitplan, Ankunftszeiten an Grenzen und Zeiten an Lkw-Fahrverboten berücksichtigt wird:

• forecast (Standard): wiederkehrende Staus zu der Stunde, zu der der Lkw den jeweiligen Abschnitt passiert, aktuelle Staus, die mit der Zeit bis zur Ankunft abklingen, Baustellen und Sperrungen auf der Strecke sowie Wetter, wo uns Daten vorliegen. Die Antwort enthält einen Block traffic_forecast mit der nach Ursache aufgeteilten Verzögerung.
• live: nur der aktuelle Verkehr, ohne wiederkehrende Staus.
• off: keine Verkehrsanpassung; die Zeiten sind Lkw-Routing-Zeiten bei freiem Verkehrsfluss. traffic_forecast enthält dann nur model und mode.

Jeder andere Wert liefert 400 bad_request mit der Meldung Invalid traffic: forecast, live or off. Anfragen ohne den Parameter erhalten den Standard forecast.

Lkw-Fahrverbote zur prognostizierten Ankunftszeit: Mit forecast oder live wird truck_bans[].active jetzt zu dem Zeitpunkt beurteilt, zu dem der Lkw laut Prognose das jeweilige Verbot erreicht (ab depart_at, oder ab jetzt, wenn Sie keinen senden), vor jeder Wartezeit an diesem Verbot. Ein neues Feld truck_bans[].active_at gibt den beurteilten Zeitpunkt in der Ortszeit des Verbotslandes an. bans_summary, restriction_hits und legal folgen denselben Urteilen, und ein Verbot, in das die prognostizierte Verzögerung neu hineinläuft (zum Beispiel an einem späteren Tag oder in einem anderen Land), wird ebenfalls in truck_bans aufgeführt. Mit traffic=off wird active auf der Zeitachse bei freiem Verkehrsfluss beurteilt, und active_at entspricht eta_at_ban.

Neues Produkt: Truck Route API (GET /api/v2/data/truck-route, nur v2). Ein Aufruf liefert eine Lkw-taugliche Route und alles, was ein Disponent entlang der Strecke braucht. Die Route wird vom selben Routing-Kern berechnet wie in unserer Lkw-Navigations-App TruckTurn, auf unseren eigenen Kartendaten.

• Fahrzeug: height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (ADR-Klassen) und adr_tunnel (B–E). Lkw-Fahrverbote und Sperrzonen werden auf der zurückgegebenen Linie geprüft.
• Entlang der Route: Tankstellen mit aktuellen Preisen, Lkw-Parkplätze und Wiegestationen, jeweils mit km_from_start und Umweg.
• Ruhezeitplan für Fahrer nach EU-Verordnung 561/2006: Pausen (auch geteilt 15+30), tägliche und wöchentliche Ruhezeit (auch verkürzt), Einzel- oder Doppelbesatzung (crew=2), ausgehend vom aktuellen Fahrerstatus, sofern Sie ihn übergeben. Jeder Halt wird auf einem realen Parkplatz entlang der Route platziert. Es ist eine Planungshilfe, kein Fahrtenschreiber-Nachweis.
• ETA einschließlich Ruhezeiten, Lkw-Fahrverboten und Grenzwartezeiten. Planung nach depart_at oder arrive_at.
• Mautkostenschätzung je Land (EUR, nach Achsen und Emissionsklasse); Länder ohne Tarif sind in tolls.coverage_note aufgeführt. Außerdem avoid (Maut, Fähren, Autobahnen, Grenzen, Tunnel, unbefestigte Straßen, Umweltzonen), bis zu 2 Alternativen, eine Aufschlüsselung je Land und geometry als polyline5, polyline6 oder GeoJSON.

Kontingent: ein eigenes Lkw-Routen-Kontingent: 10 Aufrufe pro Tag für jedes Konto, mehr in bezahlten Tarifen, plus das Add-on Zusätzliche Lkw-Routen-Aufrufe. In der Sandbox können Sie 10 Lkw-Routen pro Tag berechnen, das Ergebnis mit dem vollständigen Routenplan auf der Karte ansehen und als GPX, KML, GeoJSON, CSV, Kalender (.ics) oder ITN exportieren. Siehe die Produktseite und die Referenz.

Gemäß den API-Nutzungsbedingungen ist ein Market das Land, dessen Daten Sie nutzen, und Ihr Schlüssel deckt die für Ihr Konto freigegebenen Länder ab. Bisher beantworteten koordinatenbasierte Produkte (lat/lon — z. B. Nearby Shops, Truck Parkings, Fuel Stations) jeden Punkt in Europa. Ab 13. Oktober 2026, wird dies bei der Verarbeitung Ihrer Anfrage geprüft:

• Eine Anfrage, deren lat/lon in einem für Ihr Konto nicht freigegebenen Land liegt, liefert 403 mit error.code market_not_allowed. Die Meldung nennt das Land und Ihre freigegebene Länderliste.
• Kreuzt der Radius eine Grenze, werden Ergebnisse entfernt, deren country_code außerhalb Ihrer freigegebenen Länder liegt. Die Antwort enthält dann markets_filtered (Anzahl der entfernten Ergebnisse) und markets_notice, und total_found zählt nur die erhaltenen Ergebnisse.

Dies gilt für Konten, deren Länder geprüft wurden (Status approved oder partial). An der Anfrage ändert sich nichts — kein neuer Parameter, keine neue Version. Falls Ihre App ein weiteres Land benötigt, fügen Sie es vor dem 13. Oktober im Entwicklerportal hinzu. market_not_allowed ist zusammen mit den anderen Fehlercodes im Referenzhandbuch aufgeführt.

Entwicklerkonten, die mit einem Nakordoni-Partners-Konto mit derselben E-Mail-Adresse verknüpft sind, können jetzt Nachrichten einreichen und ihre NakBus-Flotte (NakDriver / NakManager) über partners.nakordoni.eu verwalten, mit Teamrollen (Owner, Manager, Viewer) und Ein-Klick-Anmeldung zwischen den beiden Portalen. Die Seiten des Entwicklerportals, API-Schlüssel, Flotten-Endpunkte und Apps bleiben unverändert.

Bei Fuel Prices liefen updated_at und das eigene age_hours/stale-Flag der Antwort nach unterschiedlichen Uhren: updated_at ändert sich nur, wenn sich ein Preis tatsächlich ändert, die Veralterung wurde aber so berechnet, als ändere es sich bei jeder Bestätigung. 46.7% des Preisindex zeigten age_hours ≤48 und stale:false, obwohl updated_at tatsächlich älter als 48 Stunden war, bei 12,620 Stationen sogar älter als eine Woche. Jeder Preis enthält nun zusätzlich confirmed_at — den Zeitpunkt der letzten Bestätigung des Preises, auf die Stunde abgerundet und nie früher als updated_at — und age_hours/stale werden daraus berechnet. Die Bedeutung von updated_at ist unverändert: Nutzen Sie es, wenn Sie wissen wollen, wann sich der Preis zuletzt bewegt hat, und confirmed_at, wenn Sie wissen wollen, wie aktuell er jetzt ist. Im eingefrorenen v1-Vertrag nicht vorhanden.

Zwei Sprachfehler, beide unbemerkt: Wurde der kanonische Sortencode als lang=pl (oder eine der anderen 24 Sprachen der Website) gesendet, kam fuel_type_local unabhängig davon auf Englisch zurück — nur 10 Sprachen wurden je gegen die Bezeichnungstabelle geprüft, sodass alles außerhalb dieser Liste auf das Standard-UI-Vokabular zurückfiel statt auf die angeforderte Sprache. Unabhängig davon beantwortete lang=tr (oder mehrere andere gültige Codes) Stationslisten auf Ukrainisch, weil ein interner Standardwert uk immer dann griff, wenn die angeforderte Sprache nicht in derselben 10-Sprachen-Liste stand. Beides ist behoben: Die gesendete Sprache ist jetzt die gelieferte Sprache, in allen 25.

Außerdem: brand bei Nearby Fuel Stations liefert für die ~330 Stationen, deren Marke wir nicht kennen, nicht mehr den rohen Ingest-Platzhalter OTHER, sondern null — konsistent mit jedem anderen unbekannten Feld der Antwort.

Der Grenz-KI-Assistent (/api/v1/data/assistant) antwortete mit 503 internal_error — „Assistent vorübergehend nicht verfügbar“ —, wenn derselbe Schlüssel dieselbe Frage zweimal innerhalb von fünf Minuten stellte. Nicht verfügbar war dabei nichts: In den meisten dieser Fälle war die Antwort bereits berechnet und stand zur Auslieferung bereit. Sie wird jetzt regulär zurückgegeben, mit ok: true und HTTP 200.

Trifft die Wiederholung ein, während die erste Antwort noch geschrieben wird, liefert der Aufruf jetzt 429 mit error.code gleich duplicate_request statt einer 503, sodass eine Retry-Strategie „gleich noch einmal fragen“ von einer echten Störung unterscheiden kann. Beide Fälle wurden außerdem als Serverfehler auf die Fehlerrate Ihres Kontos angerechnet; das ist nicht mehr der Fall. Am Request selbst ändert sich nichts — kein Parameter, keine Version. duplicate_request ist in der Referenz zusammen mit den übrigen Fehlercodes aufgeführt.

Lkw-Parkplätze (/api/v2/data/truck-parkings) lieferten Einträge mit name gleich null und leerem address — bei Bensheim 20 von 50. Das sind Orte, die wir nur als Koordinate vorhalten: nichts zum Anzeigen und nichts, womit sich Ihr eigener POI-Bestand abgleichen ließe. Sie gehören nicht mehr zu diesem Produkt: Es liefert jetzt ausschließlich benannte Standorte, derzeit mehr als 22.000 in ganz Europa. Wenn Sie unbenannte Einträge selbst herausgefiltert haben, ist dieser Code nun überflüssig, aber unschädlich. Antworten fallen bei gleichem radius und limit kürzer aus, und jeder zurückgegebene Eintrag ist nutzbar.

Unabhängig davon trugen rund 10.000 Parkplätze ein rohes Koordinatenpaar als name, zum Beispiel 51.927301,10.14112, während die eigentliche Bezeichnung in address stand. Sie tragen nun diese Bezeichnung — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — überall, wo sie vorkommen, auch in /api/v1/data/pois. Die id jedes Ortes bleibt unverändert, eine zwischengespeicherte Zuordnung bleibt also gültig; nur der name ist anders.

snapshot.updated_at in /api/v1/data/queue und /api/v1/data/multi ist Ortszeit in der Zone des jeweiligen Grenzübergangs (zum Beispiel Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), und bislang stand in der Antwort nirgends, um welche Zone es sich handelt — ein Aufrufer konnte den Wert also keinem Zeitpunkt zuordnen. snapshot erhält zusätzlich das Feld timezone (IANA-Name) neben updated_at. Kein Parameter, keine Version, keine Änderung an anderen Feldern.

Bislang beschrieb jeder Kraftstoff-Endpunkt seine eigene Abdeckung mit einer von Hand gepflegten Liste: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, wobei Polen darin auf die Dreistadt eingeschränkt war. Beide Angaben waren längst veraltet. Die Abdeckung wird jetzt aus dem Live-Index der Tankstellen gemessen und alle sechs Stunden neu berechnet: 39 Länder haben heute Tankstellen mit Preisen, Polen darunter landesweit und nicht in drei Städten. An der Anfrage selbst ändert sich nichts: kein Parameter, keine Version.

Tankstellen in der Nähe und Günstigster Kraftstoff: Wenn eine Suche leer zurückkommt, enthält der Block coverage jetzt gemessene station_countries, station_counts, sparse_coverage und measured_at, und zwar auf die angefragte Sorte bezogen statt auf Kraftstoff im Allgemeinen. Ein Land landet in sparse_coverage, wenn wir dort 25 Tankstellen mit Preisen oder weniger haben — das ist gezählt, nicht eingeschätzt.

Es gibt einen neuen Hinweis für eine Sorte, die wir kennen, die aber niemand dort bepreist, wo Sie gefragt haben. Bisher erschien coverage.fuel_type_note nur, wenn uns der Zapfsäulenname selbst unbekannt war. Jetzt erscheint er auch, wenn der Name korrekt aufgelöst wird und es für ihn in diesem Land schlicht keinen Preis gibt; er nennt die Länder, in denen diese Sorte bepreist ist, und die Sorten, die wir in Ihrer Umgebung bepreisen. Der tschechische Zapfsäulenname Natural 100 ist das saubere Beispiel: Er wird aufgelöst, und keine Quelle liefert dafür in Tschechien einen Preis. Eine leere Antwort sieht damit nicht mehr wie eine kaputte Anfrage aus.

Kraftstoffsorten (/api/v2/data/fuel-grades) bekommt priced_countries und priced_station_counts für jede Sorte, dazu priced_here, wenn Sie ?country= übergeben. Die beiden Listen bedeuten Verschiedenes: Ein Land unter countries ist eines, in dem wir diesen Zapfsäulennamen akzeptieren, während priced_countries die Länder sind, in denen eine Quelle ihn tatsächlich bepreist; priced_here mit 0 ist deshalb eine echte Antwort und keine Lücke in der Ausgabe. Mitgeliefert werden außerdem coverage_measured_at und coverage_note, und Cache-Control sinkt von 24 Stunden auf 6, passend zur Häufigkeit der Neuberechnung.

Auch mehr lokale Zapfsäulennamen werden aufgelöst, darunter Klimadiesel 90 (HVO100) und HVO Diesel, Erdgas und Metano, Autogas und Autogaz, DEF für AdBlue sowie eine Reihe von Markennamen für Premium-Diesel und -Benzin. Die Auflösungsreihenfolge ist unverändert und der Abgleich bleibt exakt, kein zuvor funktionierender Name bedeutet heute etwas anderes, und ein neuer Name kann höchstens eine leere Antwort in eine Antwort mit Preisen verwandeln. Gleichzeitig wurden die Referenzdokumentation und die Endpunktbeschreibungen in allen 25 Sprachen der Website korrigiert.

„Günstigster Kraftstoff“ (/api/v2/data/fuel-cheapest) gab die nächstgelegenen Tankstellen nach Entfernung sortiert zurück statt der günstigsten. Da die Sortierung angewendet wurde, bevor das Ergebnis auf Ihr limit gekürzt wurde, konnten die günstigsten Tankstellen innerhalb Ihres Radius vollständig in der Antwort fehlen. Die Sortierung funktioniert wieder korrekt: zuerst der günstigste Preis für die angefragte Kraftstoffsorte, bei Gleichstand gewinnt die nähere Tankstelle, und eine Tankstelle ohne Preis für diese Sorte steht am Ende. An der Anfrage selbst ändert sich nichts — kein Parameter, keine Version.

Die v2-Kraftstoffantworten sind außerdem so dokumentiert, wie sie tatsächlich geliefert werden: Tankstellen kommen unter data.stations[], ein Eintrag pro physischer Tankstelle, wobei jede Kraftstoffsorte im prices-Objekt verschachtelt ist (price, currency, local_name, updated_at, age_hours, stale) sowie station_ref, grades, total_found und notices. Die Referenz für „Tankstellen in der Nähe“ und „Günstigster Kraftstoff“ beschrieb weiterhin die ältere flache Zeilenliste data.data[].

Auf der Abrechnungsseite (Monats-Tab) gibt es zwei Add-ons zu jedem Tarif, ohne ihn zu wechseln: Zusätzliche Prognose-Aufrufe — +100 Prognose- und Statistik-Aufrufe pro Tag je Block, 2 € im Monat je Block, bis zu 10 Blöcke; und Zusätzliche Länder — +1 deklarierbares Land je Einheit, 2 € im Monat je Land. Beim Ändern der Menge sehen Sie ein exaktes anteiliges Angebot, bevor etwas abgebucht wird.

Ab 10. November 2026 enthält jeder Tarif eine feste Anzahl deklarierter Länder: Explorer und Student 4, Starter 10, Pro und höher unbegrenzt. Ab diesem Datum lässt sich eine Deklaration, die länger ist als Tarif plus gekaufte zusätzliche Länder, nicht mehr speichern; der Konto-Tab zeigt Ihr Kontingent schon jetzt an, und Konten, die bereits darüber liegen, sehen einen Hinweis im Dashboard. Vor dem 10. November ändert sich nichts.

Die API-Sandbox kennzeichnet jetzt jeden Endpunkt in der Auswahl mit seiner Quota-Klasse (Schwer / Standard), zeigt die Quota-Kosten der gewählten Version an, bevor Sie etwas ausführen, und zeigt nach einem Aufruf, was derselbe Aufruf Ihre Live-Quota gekostet hätte — einschließlich der Formel ceil(N ppids × M sub-products / 2), die für Aufrufe im /multi-Format verwendet wird.

Das ist eine reine Lesevorschau: Sandbox-Aufrufe selbst werden aus Ihrem separaten Sandbox-Testbudget abgezogen, nie aus Ihrer Live-Quota.

Ab heute ist alles, was wir öffentlich als auslaufend angekündigt haben, für Entwicklerkonten gesperrt, die am Ankündigungsdatum oder später erstellt wurden. Bestand Ihr Konto bereits vor der Ankündigung, ändert sich nichts — Sie behalten die volle Übergangsfrist, bis zum Abschaltdatum aus dem Eintrag, der sie angekündigt hat.

Warum es diese Regel gibt. Am 24. August 2026 haben wir angekündigt, dass truck-bans v1 am 8. September 2026 abgeschaltet wird. Zwei Konten registrierten sich wenige Tage nach dieser Ankündigung, bauten ihre Integration auf v1 auf und standen Stunden vor einem 410, ohne dass eine unserer E-Mails sie je erreicht hätte: Sowohl die Ankündigung als auch der Benachrichtigungsversand lagen vor ihrer Anmeldung. Nichts in der API hinderte sie daran, eine Version zu übernehmen, deren Ende wir bereits genannt hatten. Das war unser Fehler, und dies ist die Behebung — Sie können nichts neu übernehmen, dessen Entfernung bereits terminiert ist.

Wie es sich zeigt. Ein solcher Aufruf wird mit 410 Gone und dem Fehlercode version_closed_to_new_accounts abgelehnt. Die Meldung nennt das Abschaltdatum, das Ankündigungsdatum und die stattdessen zu verwendende Version. Es ist bewusst ein anderer Code als version_sunset, den jedes Konto erhält, sobald das Abschaltdatum selbst überschritten ist — der Support unterscheidet „zu spät gekommen, um anzufangen” von „für alle weg”, ohne ein Log zu lesen.

Der Bestandsschutz richtet sich nach dem Erstellungsdatum des Kontos, nicht nach dem ersten Aufruf. Wenn Sie sich vor der Ankündigung registriert haben und erst jetzt mit der Integration beginnen, erhalten Sie dennoch die volle Übergangsfrist: Sie könnten die ganze Zeit dagegen entwickelt haben.

Ab sofort in Kraft für truck-bans v1 (angekündigt am 24. August 2026, Abschaltung am 8. September 2026) und automatisch für jede Abschaltung, die wir von nun an ankündigen. Von Ihnen ist nichts Neues erforderlich: Jede Antwort auf einer auslaufenden Version trägt bereits die Header Deprecation, Sunset und Link: rel="successor-version", sodass eine neue Integration eine bevorstehende Abschaltung erkennt, ohne diese Seite zu lesen.

Folgeschritt zur gestrigen v4-Änderung (Entwickler-Ticket #105). Kommagetrennte destination-Listen in v1 und v2 funktionieren weiterhin, unterliegen aber jetzt derselben Frist wie destination=all: beide enden am 2026-10-06 (bis dahin Deprecation/Sunset-Header, danach 400 destination_list_removed mit /api/v4/ als genanntem Ersatz). Die bestehende Prüfung auf maximal 10 Einträge in Kommalisten bleibt bis zu diesem Datum unverändert.

v4 bleibt bei einem Ziel pro Aufruf — daran hat sich heute nichts geändert. Geändert hat sich nur die Kommunikation zu v1/v2: Der 400er zu destination=all schlägt keine Kommaliste mehr als Migrationsweg vor (sie würde am selben Datum sterben), sondern verweist direkt auf v4.

Docs-Korrektur: Das v4-Beispiel auf dieser Seite lautete zuvor /api/v4/data/border/1/2,3,4/9 — eine Kommaliste, die v4 ablehnt. Jetzt heißt es /api/v4/data/border/1/2/9. Wer das alte Beispiel kopiert hat, hätte beim ersten Aufruf einen 400er bekommen; Entschuldigung.

Neuer übersetzter Schlüssel product_border_v4_p_destination erscheint in allen 25 Sprachen der Website und nennt die Ein-Ziel-Regel von v4 ausdrücklich, statt auf die Formulierung von v1/v2 zurückzufallen.

/api/v4/data/border/{origin}/{destination}/{crossing_type} ist ab heute live. Gegenüber v2 ändern sich drei Dinge, und zusammen sind sie der Grund, warum dies eine neue Version ist und keine Anpassung der alten.

1. Kein destination=all mehr. Unsere Daten sind pro Land lizenziert (Developer API Terms, Abschnitt 7), und ein Platzhalter, der sich zu "jedem Nachbarland, zu dem wir Daten haben" ausweitet, liefert Länder, für die Ihr Konto womöglich nicht freigegeben ist — und nichts in der Anfrage zeigt das an. In v4 benennen Sie das Land.

2. Ein Zielland pro Aufruf. /api/v4/data/border/1/2/9 fragt genau eine Grenze ab. Kommalisten werden nicht akzeptiert: Senden Sie 1/2/9, 1/3/9 und 1/4/9 als getrennte Aufrufe. Eine Kommaliste oder all antwortet mit 400 und nennt die genauen Aufrufe, die zu senden sind, damit nichts stillschweigend fehlschlägt.

3. Ein Lkw-Code. v1 und v2 teilten den Güterverkehr in 8 (Freight Transport) und 9 (Freight Transport up to 7.5 t) auf. Diese Trennung existiert am Übergang tatsächlich, aber kein Integrator kann daraus etwas ableiten: Eine v2-Abfrage von 9 an der Grenze UA-PL lieferte 21 der 70 Lkw-Übergänge, ohne dass darauf hingewiesen wurde. v4 beantwortet 9 mit allen Lkw-Spuren und akzeptiert 8 als Alias von 9. Jede Zeile trägt ihren eigenen crossing_type, sodass eine zusammengeführte Antwort nachvollziehbar bleibt.

In v1 und v2 funktioniert destination=all noch bis zum 06.10.2026 und trägt bis dahin Deprecation- / Sunset-Header. Ab diesem Datum antworten auch diese Versionen bei all mit 400 — der Rest von v1 und v2 bleibt unverändert und weiterhin verfügbar. Dasselbe Datum gilt für die übrigen Alle-Länder-Abkürzungen: travel-matrix ohne ?dest=, bus-carriers mit ?ppid=all und fuel-grades ohne ?country=.

v3, heute früher angekündigt, wird durch v4 abgelöst. v3 unterschied sich von v4 nur dadurch, dass es weiterhin eine Kommaliste akzeptierte, und keine Integration nutzt diese Form. v3-URLs antworten weiterhin, damit nichts bricht, was dagegen geschrieben wurde, aber v3 ist nicht dokumentiert und wird nicht weiterentwickelt — migrieren Sie auf v4.

Alles Übrige in v4 entspricht v2: die gerichtete Reihenfolge im Pfad, direction{from,to}, stale und ?max_age_min=.

Die numerischen IDs in /border/{origin}/{destination}/{crossing_type} wurden nie als Tabelle veröffentlicht, also haben Integratoren sie aus Zeitzonen und Beispiel-URLs rekonstruiert. Sie stehen jetzt in der Dokumentation unter Länder- und Fahrzeugtyp-Codes, gerendert aus denselben Tabellen, gegen die die API validiert — Länder-IDs mit den Grenzen, zu denen sich jede aufklappt, und jeder crossing_type mit der Bezeichnung, die die API zurückgibt.

Beim Veröffentlichen fiel uns auf, dass die Sandbox und die Endpoint-Metadaten 8 als "truck<7.5t" und 9 als "truck" beschrieben. Das ist vertauscht: Die API bezeichnet 8 als Freight Transport und 9 als Freight Transport up to 7.5 tons, und das war immer so. Wer den Lkw-Code aus dem Parameterhinweis übernommen hat, filterte auf die entgegengesetzte Spur. Überall korrigiert, und v3 nimmt die Wahl vollständig heraus.

API Terms v1.1 ersetzen v1.0, bevor diese in Kraft getreten sind, und gelten ab 06.10.2026. Bitte akzeptieren Sie sie in Ihrem Dashboard.

Abschnitt 7 sagt jetzt, was ein Markt ist: das Land, dessen Daten Sie nutzen — dort, wo der abgefragte Grenzübergang oder die abgefragte Grenze liegt — nicht das Land, in dem Ihre Nutzer leben. Unser Dashboard hatte an verschiedenen Stellen beides behauptet; die Durchsetzung meinte immer das Erste.

Zwei Änderungen zu Ihren Gunsten. Länder, die für Ihr Konto bereits freigegeben sind, bleiben nutzbar, während eine spätere Änderung geprüft wird (das Hinzufügen eines Landes setzt die vorhandenen nicht mehr aus). Und wenn wir eine Marktangabe nicht innerhalb von 5 Werktagen beantwortet haben, gelten Ihre vollen Tariflimits, bis wir es tun.

Abschnitt 10.3 entspricht jetzt dem, was das Dashboard tatsächlich verlangt, und Abschnitt 13.2 nennt eine Verfügbarkeitsgrundlage, die wir messen und Ihnen zeigen können.

Drei Produkte führen jetzt ein zusätzliches Feld data_quality (high oder low), das angibt, ob ein Messwert eine echte Beobachtung ist oder eine Modellschätzung ohne Live-Zählquelle an diesem Übergang: queue (auf der obersten Ebene in snapshot und auf jeder historischen Zeile in data[] — bei Prognosezeilen nicht vorhanden), update-info (im Envelope) und multi (in beiden Unterobjekten queue und update_info je Grenzübergang). Das ist kein neues Signal — das zugrunde liegende Flag existierte intern bereits —, aber es wurde nie ausgegeben, sodass ein vollständig modellierter Grenzübergang identisch zu einem direkt gemessenen aussah. is_realtime bleibt absichtlich unverändert: Es liefert weiterhin true für modellierte Zeilen, und diese Bedeutung zu ändern wäre ein Breaking Change auf v2-Ebene, den wir hier nicht vornehmen.

Ebenfalls aus diesem Release: Das Produkt queue-advanced gibt keine rohen Wetterdaten der Vorsysteme mehr weiter. weather_main, temperature und wind_speed werden durch ein abgeleitetes condition_code ersetzt (Gefahrenskala 0–5, null, wenn keine Wetterdaten vorliegen), dazu condition und severity.

Ab 2026-08-30 wird eine /api/v1/data/multi-Anfrage für höchstens 5 Grenzübergänge beantwortet. Ein Aufruf mit mehr PPIDs wird nicht abgelehnt: Er liefert weiterhin 200, beantwortet aber nur die ersten 5 IDs in ?ppids=. Die übrigen IDs werden ignoriert, in meta.ppid_cap.ignored zurückgegeben und nicht auf Ihr Kontingent angerechnet — abgerechnet wird, was der Aufruf tatsächlich zurückgibt.

Solange ein Aufruf über dem Limit liegt, enthält die Antwort den Header X-Devapi-Warning: multi_ppid_cap und einen Block meta.ppid_cap mit cap, enforced_from, enforced, ppids_asked, ppids_answered und ignored[]. Bis 2026-08-30 erscheinen diese Felder mit enforced: false und dem vollständigen Ergebnissatz, sodass Sie die kommende Änderung in Ihren eigenen Logs sehen.

Der Kontingentrabatt von der Hälfte bleibt unverändert. Teilen Sie Ihre Grenzübergänge in Gruppen zu 5 auf und senden Sie pro Gruppe einen Aufruf in Ihrem üblichen Aktualisierungszyklus; für häufiges Abfragen ausschließlich von Warteschlangenlänge und Aktualität bleibt update-info das günstigere Produkt der Standardklasse.

Das berechnete ukrainische Hitze-Fahrverbot — mit include_ua_heat zurückgegeben und bei country=UA automatisch — antwortet jetzt für das Datumsfenster, nach dem Sie fragen. Zuvor lieferte es die kommenden sieben Tage, egal was date_from und date_to sagten, sodass ein Dezember-Fenster stillschweigend die Zeilen dieser Woche zurückgab. Das Verbot wird aus der Wettervorhersage berechnet und nicht aus dem Verbotskalender gelesen; es hat daher zwei Grenzen, die der Kalender nicht hat: Es blickt nicht zurück und endet dort, wo die Vorhersage endet. Ihr Fenster wird nun mit dem geschnitten, was die Vorhersage tatsächlich abdeckt, und das neue Feld ua_heat_ban.forecast_horizon nennt das letzte erreichbare Datum. Ein Fenster jenseits dieses Horizonts liefert keine Zeilen und erklärt den Grund in summary — das ist nicht dasselbe wie „kein Verbot“. v1-Antworten bleiben unverändert.

Die Form der Antwort war bisher nirgends dokumentiert — der einzige Weg herauszufinden, was ein Produkt zurückgibt, war es aufzurufen. Auf jeder Produktseite steht nun unter der Parametertabelle eine Tabelle Antwortfelder mit einer kurzen Beschreibung jedes Feldes; Felder von Listenelementen erscheinen als items[].name, Felder auf Umschlagebene (usage, meta, snapshot, resolved_location) ohne Präfix. Dokumentiert sind 40 von 42 Produkten: die zwei noch nicht gestarteten (weather, road-quality) bleiben bewusst ohne Beschreibung. Dieselbe Tabelle erscheint in unserem öffentlichen GitHub-Dokumentationsspiegel.

Jedes Kraftstoffprodukt akzeptiert jetzt den lokalen Namen einer Sorte, nicht nur unsere interne Schreibweise: ON in Polen, Nafta in Tschechien, Gázolaj in Ungarn, Motorină in Rumänien, ДП in der Ukraine, Motorin in der Türkei, Gasóleo in Portugal und Spanien. Aufgelöst wird zuerst nach Land — „95“ ist E10 an einer dänischen und E5 an einer polnischen Zapfsäule —, senden Sie also country zusammen mit dem lokalen Namen oder Koordinaten, über die sich der Punkt verorten lässt. Die Antwort enthält fuel_type (kanonisch), fuel_type_requested (wie eingegeben) und fuel_type_local. Einen Namen, den wir nicht verorten können, ersetzen wir nie durch eine Standardsorte: die Antwort kommt leer zurück und sagt das auch.

Die vollständige Tabelle ist jetzt ein eigenes Produkt — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — unsere kanonischen Sorten und ihre lokalen Namen in 41 europäischen Ländern, auch in Märkten, für die wir keine Preise führen. Die Länder- und Regionsebene von fuel und fuel-local liefert außerdem ein Objekt grades, das jeden Preisschlüssel seiner Sorte und dem lokalen Zapfsäulennamen zuordnet.

Das Produkt truck-bans beantwortet jetzt Anfragen für ein bestimmtes Datum oder einen Zeitraum unter /api/v2/data/truck-bans. Bisher lieferte es immer die kommenden 7 Tage und ignorierte jedes übergebene Datum; für einen Kalender war deshalb eine Anfrage pro Tag nötig — und bei einem Tarif mit zwei Anfragen pro Sekunde werden die meisten davon mit 429 qps_exceeded abgelehnt.

Verwenden Sie ?date=YYYY-MM-DD für einen einzelnen Tag oder ?date_from= und ?date_to= für einen Zeitraum. Beide Grenzen sind inklusiv und jede darf entfallen: der Beginn ist standardmäßig heute, das Ende der Beginn plus 7 Tage. Ein Fenster darf höchstens 92 Tage umfassen — ein längeres wird mit 400 date_range_too_long abgelehnt, statt stillschweigend gekürzt zu werden. Dies ist ein vorausschauender Kalender: Ein Fenster darf höchstens 7 Tage in der Vergangenheit beginnen, ältere Daten werden abgelehnt statt geliefert — die Abdeckung reicht vorwärts bis zum 31. Dezember 2028 und umfasst 23 Länder.

Jede Antwort enthält jetzt ein Objekt window, das den genau abgedeckten Zeitraum benennt. Es ist additiv und wird auch in v1 gesendet, wobei v1 sein festes 7-Tage-Fenster unverändert behält. Beachten Sie: include_ua_heat deckt immer die kommenden 7 Tage ab, unabhängig vom angefragten Fenster — es wird aus einer Wettervorhersage berechnet, nicht aus dem Verbotskalender. Denken Sie daran, dass v1 dieses Produkts am 8. September 2026 eingestellt wird.

Zwei verwandte Verbesserungen im gesamten API: Jeder Parameter, den ein Produkt nicht akzeptiert, wird jetzt in der Antwort unter ignored_params aufgeführt, statt stillschweigend verworfen zu werden, und Validierungsfehler des Datendienstes erreichen Sie im Wortlaut, mit dem maschinenlesbaren Code in error.reason.

Drei Verbesserungen der Antwortqualität aus einem Gateway-Audit (Ticket #43).

Der Header X-API-Key wird jetzt akzeptiert — neben Authorization: Bearer und ?key=. Wenn Ihr HTTP-Client Schlüssel über einen Header namens X-API-Key sendet, funktioniert das nun — zuvor wurde er stillschweigend ignoriert und der Aufruf als missing_api_key abgelehnt. Authorization: Bearer bleibt die dokumentierte, empfohlene Form.

Die Fehlermeldung bei fehlendem Schlüssel nennt jetzt alle drei Authentifizierungswege (Bearer-Header, X-API-Key-Header oder ?key=), statt nur auf die Registrierungsseite zu verlinken.

Das Verzeichnis checkpoints führt jetzt has_day_stats in jeder Zeile — ein zusätzlicher boolescher Wert, der angibt, ob die API „Beste Zeit für den Grenzübertritt“ (Day-Stats) Daten für diesen Grenzübergang hat. Day-Stats gibt es nur für einen Teil der überwachten Grenzübergänge; prüfen Sie dieses Flag vor dem Abfragen, um vorhersehbare 404 zu vermeiden. Bestehende Felder bleiben unverändert.

Ebenfalls in der Dokumentation korrigiert: Das Produkt road-conditions hat einen Parameter lang zur Lokalisierung der Beschriftungen immer berücksichtigt — er war nur nicht aufgeführt.

Zwei Korrekturen und eine neue Version für das Produkt truck-bans.

Kommagetrennte Länder funktionieren jetzt. ?country= akzeptiert eine Liste von bis zu 3 ISO-2-Codes, zum Beispiel ?country=DE,RO. Eine längere Liste wird mit 400 too_many_countries abgelehnt statt stillschweigend gekürzt — dies ist ein Sperrkalender je Land, kein Massen-Feed. Bisher funktionierte das nicht: Das Trennzeichen wurde entfernt, sodass DE,RO als einzelnes Token DERO gelesen wurde, auf nichts passte und success: true mit total_bans: 0 zurückgab — ein selbstbewusstes „keine Sperren“ für zwei Länder, die zusammen 22 hatten. Wenn Sie das mit je einer Anfrage pro Land umgangen haben, deckt eine einzige Anfrage nun alle ab und kostet einen Aufruf statt mehrerer.

Antworten melden jetzt ihre eigene Vollständigkeit. Drei zusätzliche Felder — returned, total_available und truncated — zeigen Ihnen, ob eine Antwort gekappt wurde. Insbesondere eine Anfrage ohne Scope liefert einen gekappten Ausschnitt, und bislang wies nichts in der Nutzlast darauf hin. total_bans behält seine bisherige Bedeutung (Zeilen in dieser Antwort), an dem, was Sie bereits parsen, ändert sich also nichts.

v2 ist je Land eingegrenzt. Unter /api/v2/data/truck-bans ist ?country= erforderlich, und eine Anfrage ohne Scope wird mit 400 scope_required abgelehnt — dieses Produkt ist ein Sperrkalender je Land, kein Massen-Feed. v1 bleibt heute unverändert — sie akzeptiert weiterhin eine Anfrage ohne Scope und liefert weiterhin dieselben gekappten 50 Zeilen wie immer, es bricht also gerade nichts, was bei Ihnen läuft. v1 dieses Produkts wird am 8. September 2026 eingestellt. Sie liefert bis einschließlich 7. September normal aus; ab dem 8. September wird eine v1-Anfrage mit 410 Gone und einem Hinweis auf v2 abgelehnt. Bis dahin trägt jede v1-Antwort Deprecation: true, einen Sunset-Header mit diesem Datum und einen Link-Header, der die Nachfolgeversion nennt, sodass eine Client-Bibliothek die Frist anzeigen kann, ohne dass jemand diese Seite liest. Zur Migration: Ändern Sie das Versionssegment auf /api/v2/data/truck-bans und übergeben Sie ?country=.

Eine Korrektur in der Dokumentation: Der Parameter date wurde entfernt. Er war lange aufgeführt, wurde vom Dienst aber nie gelesen, sodass jede Anfrage, die ihn sendete, stillschweigend das Standardfenster von 7 Tagen erhielt statt des angefragten Tages. Um einen Tag auszuwählen, filtern Sie das Array upcoming_bans nach seinem Feld date. Ein ISO-3-Code wie DEU wird in der Zusammenfassung ebenfalls nicht mehr zu einem Ländernamen aufgelöst, wo er das irreführende „No truck ban data for: Germany.“ erzeugte.

Das Produkt truck-bans liefert jetzt landesweite Fahrverbote für fünf weitere Länder: Belgien (BE), Belarus (BY), Montenegro (ME), Nordmazedonien (MK) und Schweden (SE). Die bestehende Abdeckung für Bulgarien, Griechenland und Portugal wurde erweitert und aktualisiert — griechische Verbote reichen nun bis September 2027, und Portugal ist wieder befüllt.

Die Antwortstruktur bleibt unverändert. Neue Einträge tragen dieselben Schlüssel wie jedes andere Fahrverbot: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons und details_url. Gilt ein Verbot nur unter einer Bedingung — belarussische Sommerverbote gelten etwa erst über 25 °C — steht diese Bedingung in restriction_details; lesen Sie dieses Feld also, bevor Sie einen Fahrer warnen. min_weight_tons ist null, wenn eine Regel eine Transportklasse (Gefahrgut) statt eines Gewichts betrifft.

Die Produkte fuel-stations und fuel-cheapest liefern jetzt Preise einzelner Tankstellen in Polen. Die Abdeckung ist teilweise — der Raum Dreistadt (Danzig, Gdingen, Zoppot) — deshalb wird Polen in einem neuen, additiven Array coverage.sparse_coverage neben der bestehenden Liste coverage.station_countries ausgewiesen. Ein in sparse_coverage genanntes Land hat Stationsdaten nur für einen Teil seines Gebiets; eine Abfrage andernorts in diesem Land liefert wie bisher eine leere Liste zusammen mit dem Abdeckungshinweis. Polnische Preise werden in PLN angegeben.

Auch die Fehlermeldung bei Massenabfragen ist klarer: Fehlt lat, verweist die Meldung scope_required jetzt auf das Produkt fuel (?country=XX) für landesweite Durchschnittspreise.

GET /api/v2/data/fuel-local?lat=&lon= löst den Preis jetzt über drei Ebenen statt zwei auf: station, dann region, dann country. Die neue mittlere Ebene gibt es für die Ukraine, wo es nirgends Preise einzelner Tankstellen gibt: Ein Punkt in der Ukraine erhält nun den Durchschnitt seiner Oblast statt des Landesdurchschnitts und fällt nur dann auf den Landesdurchschnitt zurück, wenn für die Oblast keine Notierung vorliegt.

Eine Antwort der Ebene region enthält den Oblast-Code (ein ISO-3166-2-Wert wie UA-46), region_name und region_center_dist_km sowie dieselben Preisschlüssel wie die Länderebene. Verzweigen Sie weiterhin über resolution, nie über die Form der Antwort; Antworten der Ebenen station und country bleiben unverändert.

Der neue Endpunkt GET /api/v2/data/fuel-local?lat=&lon= liefert den besten verfügbaren Kraftstoffpreis für jeden Punkt in Europa. Wo Tankstellendaten vorliegen, antwortet er mit den Preisen der nächstgelegenen Tankstellen, sonst mit dem Landesdurchschnitt des Landes, in dem der Punkt liegt – auch für die Ukraine, wo es nirgends Preise einzelner Tankstellen gibt.

Jede Antwort enthält das Feld resolution, das die antwortende Ebene nennt: station (eine Liste von Tankstellen mit distance_km, jeweils in eigener Währung) oder country (ein Objekt mit Landesdurchschnitten). Verzweigen Sie über resolution, nie über die Form der Antwort. Verfügbar ab /api/v2/; fuel, fuel-stations und fuel-cheapest bleiben unverändert.

Die Produkte fuel-stations und fuel-cheapest decken jetzt deutlich mehr Tankstellen in Deutschland ab, die Preise werden über den Tag hinweg aktualisiert — auch im ländlichen Raum. Der Parameter fuel_type akzeptiert 13 Kraftstoffarten: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 und lng. Passt keine Tankstelle zur Anfrage, enthält die Antwort ein coverage-Objekt mit den Ländern, für die Tankstellendaten vorliegen.

Der Parameter radius= wird jetzt in allen Produkten, die ihn dokumentieren, als kompatibler Alias für radius_km akzeptiert. Die Produkte fuel-stations und fuel-cheapest liefern ein additives coverage-Objekt (Liste der Länder mit Tankstellendaten plus Hinweis) statt eines stillen leeren Ergebnisses, wenn keine Tankstelle passt. Grenzobjekte in route-plan enthalten jetzt den additiven Schlüssel wait_basis (car_lane vs. vehicle_lane), sodass Clients erkennen, wann Lkw-Wartezeiten ersatzweise aus der Pkw-Spur stammen. Die Zuordnung von Lkw-Grenzübergängen entlang einer Route ist deutlich genauer: Pkw-Spur als Fallback für Grenzpaare ohne Lkw-Daten, ein Schutz gegen die falsche Richtung, ein engeres Distanzlimit und die Entduplizierung von Übergängen an derselben Position. Alle Änderungen sind additiv, es gibt keine Breaking Changes.

Die Entwickler-Landingpage verfügt jetzt über verankerte Abschnitte (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) mit Sprungnavigation, und jede Produktkarte verlinkt zu ihrer eigenen Dokumentationsseite. Der neue Abschnitt Mobile apps stellt Kordon Online und Truck Bans mit Google-Play-Links vor. Übersetzungs-Nacharbeit: Zahlungsverlauf, Anmeldefehler, Sandbox-Links und die Tarifauswahl-Schaltfläche sind jetzt in allen 25 Sprachen lokalisiert.

Die Fleet-Beacon-Antwort (POST /api/v1/fleet_position.php) enthält jetzt ein messages-Array, das ausstehende Nachrichten vom Besitzer an den Fahrer liefert. Neuer Live-JSON-Feed nur für Besitzer (?ajax=live) und eine Karte „Nachrichten an Fahrer“ im Flotten-Dashboard. Neue Fahrer-Einladungsseite /{lang}/get-nakbus (25 Sprachen).

Titel, Beschreibung und Parameter von product_fleet_vehicles/live/history sowie die Flottenverlauf-Parameter wurden in allen 25 Sprachen des Entwicklerportals lokalisiert.

/api/v1/data/truck-bans liefert jetzt unabhängig davon, welche Abfrage die Antwort ausgelöst hat, denselben Satz an Feldern der obersten Ebene. Bisher konnte eine Abfrage für ein Land ohne Kalenderverbote, eine nicht erkannte ppid oder ein normaler Datenbanktreffer jeweils unterschiedliche Felder auslassen (z. B. country, covered_countries, ppid). Jede Antwort enthält jetzt durchgängig as_of, bans_by_country, countries_not_covered, country, covered_countries, current_bans, is_ban_active, lang, page_url, ppid, relevant_countries, source, success, summary, total_bans und upcoming_bans (null oder leer, wenn nicht zutreffend), was das clientseitige Parsen vereinfacht.

Neun neue Produkte für einzelne Services. Die standortbasierten akzeptieren lat/lon oder city + country (wir geokodieren die Stadt für Sie): /api/v2/data/truck-parkings, /api/v2/data/shops, /api/v2/data/showers, /api/v2/data/restaurants, /api/v2/data/industrial, /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest (Stationen nach Preis für einen Kraftstofftyp gereiht) und /api/v2/data/internet-points; die Ergebnisse enthalten distance_km und sind durch radius begrenzt. /api/v2/data/vignettes beantwortet, ob ein Land eine Vignette benötigt, mit aktuellen Preisen. Das bestehende Produkt pois unterstützt jetzt wie dokumentiert lon und radius, und der Modus mode=nearest des Produkts fuel akzeptiert ebenfalls lon. Alle neun sind in der Sandbox verfügbar.

Jedes Verbot in /api/v1/data/truck-bans enthält jetzt restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (genauer Geltungsbereich oder betroffene Straßen) und min_weight_tons. details_url verweist jetzt auf länderspezifische Seiten auf nakordoni.eu. Ein neuer optionaler Parameter lang wählt die Sprache der Ländernamen und der Zusammenfassung; die Standardeinstellung ist jetzt Englisch.

Ein fehlerhaftes ?ppid= liefert jetzt den tatsächlichen Grund statt eines knappen "Request failed": Der Fehler nennt den Parameter, das erwartete Format id_<number> und verweist auf /api/v1/data/checkpoints. Die Parametertabellen für stats, forecast, update-info, weather und bus-carriers zeigen nun das Beispiel id_13 in allen 25 Sprachen.

Die überarbeitete Portaloberfläche (obere Leiste, Icon-Seitenleiste, KPI-Dashboard, kartenbasierte Layouts) ist jetzt der Standard für alle angemeldeten Entwicklerkonten — vorgezogen vom geplanten Rollout am 10. August. Mit ?v=1 können Sie jederzeit zum klassischen Layout zurückwechseln.

Alle Seiten des Entwicklerportals — Startseite, Dokumentation, Dashboard, AI Studio, Sandbox, Tickets, Anfragen, Export, Fuhrpark, News, Changelog und Kontoseiten — laden keinerlei Werbeskripte oder Werbeflächen mehr. Das gilt portalweit, nicht mehr nur für Login und Registrierung wie bisher.

Planen Sie die ganze Grenzfahrt mit einem Aufruf: /api/v2/data/route-plan liefert die Route, die tatsächlich darauf liegenden Grenzübergänge mit aktueller Warteschlange oder einer Prognose für Ihre Ankunftszeit und die Pausen, die ein Fahrer wirklich einlegt – Rast, Essen, Tanken – auf einer einzigen Zeitachse.

Die Grenze gehört zu dieser Zeitachse. Eine lange Warteschlange gilt als die ohnehin fällige Pause und setzt die Lenkzeit zurück, sodass drei Stunden Warten nie als drei Stunden plus ein volles Pausenprogramm erscheinen, das niemand genommen hat. Für Pkw gilt ein Modell sicheren Fahrens; Busse und Lkw erhalten die vorgeschriebene Ruhezeit nach EU 561/2006, und der Serviceaufwand von Bussen ist an über 1000 lizenzierten internationalen Fahrplänen kalibriert. Mit stop_places=1 bekommt jede Pause einen echten Rastplatz oder eine Tankstelle, mit via=lat,lon führt die Route über einen anderen Übergang.

Neu im Portalmenü: Präsentation — eine lebende, stets aktuelle Vorstellung der nakordoni-Datenplattform, zugeschnitten auf Ihren Markt (Versicherung, Reise, Logistik, Transportunternehmen, Medien, Navigation, Kraftstoff, Fintech, öffentlicher Sektor oder private Projekte). Sie zeigt echte Plattformvolumina der letzten 30 Tage, Ihre eigene API-Nutzung, Statistiken zu Antwortzeiten und Limits sowie eine Tarifempfehlung, sobald Ihre Aufrufe an die Grenzen des kostenlosen Tarifs stoßen. Wählen oder bestätigen Sie Ihre Märkte auf der Seite, in Ihrem Profil — oder bei der Registrierung. Beim ersten Besuch öffnet sie sich automatisch; das automatische Öffnen können Sie auf der Seite selbst abschalten.

Wenn bei einem Assistenten ein Feed aktiviert ist, der Aufruf aber den benötigten Kontext nicht mitliefert — etwa queue ohne ppid—, wird der Feed jetzt vor jeder Anfrage übersprungen und nicht berechnet. Bisher wurde er trotzdem aufgerufen, schlug fehl und kostete dennoch eine Einheit. Das Studio zeigt, was jeder Feed benötigt, berechnet den Preis beim Ausfüllen des Kontexts neu und kennzeichnet Ergebnisse als ✓ ausgeführt / ⊘ übersprungen, nicht berechnet / ✕ fehlgeschlagen; die API liefert data.feeds_skipped und nennt damit genau den zu übergebenden Parameter.

Antworten erwähnen keine Feeds, Datenquellen oder sonstige Technik mehr: Ein fehlender Feed ist höchstens ein schlichter Satz an den Endnutzer, nie ein interner Name. Feeds mit ausschließlich optionalen Filtern (etwa fuel eingegrenzt auf ein Land, zu dem wir keine Daten haben) greifen jetzt auf den breiten Datensatz zurück, statt nichts zu liefern.

Neu: /{lang}/developers/studio. Bauen Sie einen KI-Assistenten, der aus Ihren Inhalten und unseren Live-Grenzdaten antwortet. Geben Sie uns Ihr Markdown oder nennen Sie einfach die Seiten — wir holen und indizieren sie; Sie pflegen immer nur Ihre eigenen Dateien. Wählen Sie, welche unserer Feeds er nutzen darf (Warteschlange, Prognose, Alternativen, Tagesstatistik, Kraftstoff, Lkw-Fahrverbote, verkaufsoffene Sonntage, Feiertage, Straßenzustand, Busunternehmen, POIs, Währung), wählen Sie eine Modellstufe (schnell / ausgewogen / Pro — sie bestimmt den Preis), schreiben Sie eigene Anweisungen mit {{feed.slug}} -Platzhaltern, die genau festlegen, wo unsere Daten in der Antwort landen, und ergänzen Sie einen eigenen Schlusssatz, der jeder Antwort angehängt wird. Fertige Vorlagen: persönlicher Reiseassistent, Arbeits-/Frachtassistent, Vertriebsassistent für Versicherung & Grüne Karte.

Testen Sie ihn im Studio (30 Antworten/Tag, getrennt von Ihrem API-Kontingent) und rufen Sie ihn dann produktiv über GET /api/v2/data/assistant-custom?assistant_id=N&q=…auf. Preis pro Antwort = Einheiten der Modellstufe + 1 Einheit je aktiviertem Feed, zurückgegeben in X-Devapi-Units. Das Produkt gibt es nur in v2 — eine v1-URL liefert unsupported_version. Das bestehende Produkt assistant bleibt unverändert.

Jeder Assistent läuft unter einer Plattform-Inhaltsrichtlinie, die Ihren Anweisungen vorgeht: kein Auftreten als Amtsperson, keine Hilfe beim Umgehen der Grenz- oder Zollkontrolle, keine erfundenen Zahlen, keine Obszönitäten. Sowohl Anweisungen als auch Antworten werden geprüft; blockierte Aufrufe werden protokolliert.

Neu: ein echter MCP-Server unter https://nakordoni.eu/mcp, der eine sichere, schreibgeschützte Teilmenge der API (status, checkpoints, border queue, live queue, forecast) als MCP-Tools bereitstellt. Derselbe API-Schlüssel und dasselbe Kontingent wie bei der REST-API. Server-Card unter /.well-known/mcp/server-card.json. Siehe den Abschnitt MCP-Server in der Dokumentation.

Die unten beschriebene Umbenennung in „Live Queue & Freshness API“ erreichte die Doku -Seite tatsächlich nie. Die Seite gibt jeden Produkttitel über eine Übersetzungssuche aus, die nur dann auf den Titel des Endpunkts zurückgreift, wenn keine Übersetzung existiert — und eine Übersetzung existierte bereits, eingefroren auf dem alten Namen, in allen 25 Oberflächensprachen. Sie hat nun Vorrang vor jeder künftigen Änderung des zugrunde liegenden Titels, bis sie selbst aktualisiert wird.

Der Übersetzungsschlüssel wurde in allen 25 Sprachen umbenannt, sodass die Doku-Seite jetzt übereinstimmt. Keine Änderung an Endpunkt, Parametern oder Antwort — nur der Titeltext.

Wenn Sie Live-Warteschlangendaten häufig abfragen, verbrauchen Sie womöglich unnötig schweres Kontingent. /update-info gehört zur Standardklasse und liefert den Live-Wert bereits mit:

GET /api/v1/data/update-info?ppid=id_13

Zurück kommen queue_now, freshness, age_minutes, is_realtime, status, timestamp und timezone. Nutzen Sie ihn für das häufige Aktualisieren zulasten Ihres Standard-Tageskontingents und heben Sie sich /queue, /multi und /forecast (alle schwere Klasse) für die Fälle auf, in denen Sie wait_min, die Trendfelder oder Historie brauchen.

Am Endpunkt selbst hat sich nichts geändert — nur an seiner Dokumentation. Er war als „Data Freshness API“ geführt, und seine Beschreibung erwähnte nur die Aktualitätsbewertung, nie queue_now, sodass er leicht zu übersehen war. Jetzt heißt er „Live Queue & Freshness API“, mit ausgeschriebenen Rückgabefeldern. Danke an den Entwickler, der darauf hingewiesen hat.

Einige fehlgeschlagene Anfragen lieferten HTTP 200 mit ok: true und dem Fehler versteckt in data — das dokumentierte Muster if (!ok) throw konnte sie also nicht erkennen, und der Aufruf wurde trotzdem berechnet. Betroffene Aufrufe liefern jetzt HTTP 400 mit ok: false und einem ordentlichen error.code / error.message, wie dokumentiert. Beobachtet bei fuel-cities mit einem nicht unterstützten Land und bei travel-matrix mit fehlerhaften Koordinaten.

Davon getrennt: Ein fehlender Pflichtparameter lieferte 500 internal_error statt 400 bad_request (ein 4xx-Body des internen Dienstes wurde verworfen, bevor sein Status gelesen wurde). Jetzt kommt 400 bad_request mit der Meldung des internen Dienstes — z. B. search ohne ?name=.

Erfolgreiche Antworten sind Byte für Byte unverändert — dieselben Felder, dieselben Parameter, dieselben Kontingentkosten. Wenn Ihr Client bereits auf okverzweigt, ist nichts zu tun. Hat er ok ignoriert und data direkt gelesen, sieht er nun Fehler-Envelopes bei Aufrufen, die ohnehin immer fehlgeschlagen sind.

Behoben: /multi konnte eine falsche Warteschlangenzahl für einige Grenzübergänge liefern — vor allem auf dem Balkan und an der Grenze Ungarn–Serbien —, wann immer sein Cache kalt war. Der Fallback las eine Tabelle, die für diese Übergänge keine Warteschlangendaten enthält, und meldete unbeteiligte Werte als Fahrzeugzahlen. Gemessene Beispiele: Ein Übergang mit 12 Fahrzeugen meldete 6, und mehrere mit echten Warteschlangen meldeten 0.

Drei Änderungen, die Ihnen auffallen können:

• found: false bedeutet jetzt, dass wirklich keine aktuellen Warteschlangendaten vorliegen. Bisher konnten Sie found: true mit einem erfundenen queue_now: 0erhalten.
• wait_status, trend_percent und trend_direction werden jetzt auch bei kalten Anfragen geliefert — zuvor waren sie null .
• Der Endpunkt greift außerdem auf den Fallback zurück, wenn sein zwischengespeicherter Stand veraltet ist (älter als 24 h), nicht nur wenn er fehlt.

Keine Änderungen an Anfrageparametern, Kontingentkosten oder Antwortstruktur.

Ein Fehler wurde behoben, durch den jeder /multi-Aufruf doppelt abgerechnet wurde — einmal durch eine generische 1-Einheit-Prüfung und erneut durch die eigene variable Kostenformel des Endpunkts (N PPIDs × Unterprodukte). Ein Aufruf kostet jetzt exakt ⌈(N×M)/2⌉ Einheiten wie dokumentiert, ohne zusätzliche Belastung.

Außerdem wurde auf der Dokumentationsseite ein Standard/Heavy-Kontingentklassen-Badge zu jedem Produkt hinzugefügt, damit auf einen Blick klar ist, aus welchem Tageskontingent ein Endpunkt schöpft.

country und countries wurden zu einem Parameter zusammengeführt (1-15 kommagetrennte Codes). Neuer Parameter compare_to: Vergleich gleicher vs. unterschiedlicher Feiertage über Länder hinweg, kombinierbar mit upcoming+days. lang akzeptiert nun mehrere Sprachen (fügt ein names-Objekt hinzu). days=0 oder weggelassen bedeutet im upcoming-Modus jetzt keine Begrenzung.

Offizielle gesetzliche Feiertage je europäischem Land — Daten, lokale Bezeichnungen und Typ. Basiert auf demselben Nager.Date / OpenHolidaysAPI-Dienst (mit einem lokal berechneten Kosovo-Kalender), der auch die Feiertagskalender-Seite von nakordoni.eu und die Kalenderfaktoren des Prognosesystems speist.

• ?country=PL&year=2026 — vollständige Jahresliste der Feiertage für ein Land
• ?upcoming=1&days=30 — flache Liste der anstehenden Feiertage über mehrere Länder hinweg
• Keine Parameter — Index einer Kern-Ländergruppe mit dem jeweils nächsten Feiertag

Das Produkt currency wurde hinzugefügt — EUR-basierte Wechselkurse für PLN, CZK, HUF, USD, GBP, CHF, NOK und UAH, bezogen von Frankfurter (EZB) und 6 Stunden zwischengespeichert. Keine Parameter, gibt stets die vollständige Kurstabelle zurück. Siehe Dokumentation.

Betten Sie aktuelle europäische Lkw-Fahrverbote in Ihre eigene Website ein — ein kostenloses iframe-Widget mit 3 Designs (light, dark, board), 5 Sprachen (en, uk, pl, de, ru), einem optionalen Filter je Land und einem Live-Status «jetzt aktiv». Kein API-Schlüssel erforderlich. Konfigurieren und kopieren Sie den Code unter nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Lieber Rohdaten? Das API-Produkt truck-bans und der öffentliche JSON-Feed bleiben verfügbar.

Drei Ergänzungen, alle abwärtskompatibel — v1 bleibt unverändert.

Versionierung pro Endpunkt. Es gibt jetzt eine Basis-URL /api/v2/. Sie gilt pro Endpunkt: Nur Endpunkte, die sich tatsächlich geändert haben, verhalten sich unter v2 anders; jeder andere Endpunkt liefert transparent seine v1-Antwort (so ist /api/v2/data/queue = dieselben Daten wie v1, nur mit "api_version":"v2"). Endpunkte, die funktionieren, müssen nicht migriert werden.

border v2 ist direktional. Die Reihenfolge im Pfad entspricht der Fahrtrichtung:

GET /api/v2/data/border/1/2/6   → buses UA→PL (Ukrainian-side crossings)
GET /api/v2/data/border/2/1/6   → buses PL→UA (Polish-side crossings)

Jeder Checkpoint erhält zusätzlich ein direction {from,to}-Objekt und einen stale-Boolean, und ?max_age_min=N gibt nur kürzlich aktualisierte Übergänge zurück. (v1 border gibt weiterhin unabhängig von der Reihenfolge beide Seiten der Grenze zurück — unverändert.)

Interaktive Sandbox. Angemeldete Entwickler können nun jeden Endpunkt direkt im Browser ausprobieren unter Developers → Sandbox — wählen Sie einen Endpunkt, eine Version und einen Ihrer Schlüssel, passen Sie Parameter an und sehen Sie die Live-Antwort. Das Testen in der Sandbox hat ein eigenes separates Tageskontingent (50 Aufrufe/Tag) und berührt Ihr Live-API-Kontingent nie.

Die Dokumentation ist jetzt pro Endpunkt aufgeteilt (Developers → API Docs), mit einem Versionsauswähler bei Endpunkten mit mehr als einer Version.

Zwei neue Faktoren, die zusätzlich zu den bestehenden Anpassungen section_mode und Wetter in die Wartezeitformel einfließen:

• service_rate — aktuell gemessene abgefertigte Fahrzeuge/Min. im Verhältnis zur konfigurierten Basisrate des Checkpoints. Multiplikativ, begrenzt auf 0.5x-1.5x.
• shift_change — Auswirkung des lokalen Grenzschichtwechsels des Checkpoints um 08:00/20:00 Uhr. Additiv (Minuten), nicht multiplikativ — nur innerhalb von +/-60 Minuten um einen Schichtwechsel angewendet, erfordert eine Mindest-Stichprobenhistorie, begrenzt auf +/-120 Minuten.

advanced_wait_min ist nun round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Beide Faktoren spiegeln sich für historische Vergleiche auch in driver_reported.prognosed_advanced_wait_min wider.

Im Rahmen einer Sicherheits-/Datenschutzprüfung wurden die folgenden Felder entfernt — sie legten interne Implementierungsdetails offen (unsere Taxonomie der vorgelagerten Datenquellen, DB-Zeilen-IDs, interne Pipeline-Annotationen, ungenutzte/tote Felder) ohne echten Produktnutzen:

• id und corrected — aus den Zeilenobjekten von queue entfernt
• source (Rohstring, z. B. "line") — aus queue, multi und update-info entfernt. update-info und der update_info-Block von multi führen weiterhin source_category/source_label_en (ein kleines öffentliches Vokabular); der queue-Block von queue und multi führt überhaupt kein source-Feld mehr
• traffic_status — aus border entfernt; es war stets null und wurde von keinem Teil des Systems je befüllt

Falls Ihre Integration eines dieser Felder liest, aktualisieren Sie sie bitte — die aktuelle Feldliste finden Sie auf der Dokumentationsseite des jeweiligen Produkts.

Der tägliche Kontingentverbrauch (usage.used in jeder Antwort) kann jetzt ein Dezimalwert sein (z. B. 67.5) statt immer einer Ganzzahl. Dies ist eine Nebenwirkung davon, dass queue-advanced zu einem gebrochenen Satz abgerechnet wird — siehe unten. usage.limit ist nicht betroffen und stets eine Ganzzahl. Falls Ihr Client usage.used strikt als Ganzzahl typisiert, erweitern Sie den Typ bitte, sodass er einen Dezimalwert/Float akzeptiert.

Diese drei Produkte geben nun dieselben Live-Status-Felder zurück, die auch die Website anzeigt: wait_status (green/yellow/red, basierend auf der jüngsten Historie dieses Checkpoints) sowie trend_percent/trend_direction (up/up-slight/down/down-slight/stable, im Vergleich der letzten 3 Stunden). Rein additiv.

Die data[]-Zeilen von /api/v1/data/queue hatten zuvor bei den meisten Quellen wait_time: null — nur wenige vorgelagerte Feeds melden eine Wartezeit direkt. Zeilen ohne Wert erhalten nun die Standardschätzung , gekennzeichnet durch einen neuen wait_time_estimated-Boolean, sodass Sie einen tatsächlich gemeldeten Wert von einem berechneten unterscheiden können.

queue-advanced kostet nun 1.5 units pro Aufruf statt 1 (was die zusätzlichen Verkehrs-/Wetter-/Fahrermeldungs-Abfragen widerspiegelt) — siehe usage.used oben. Die Antwort enthält außerdem kein total_crossing_time mehr, und driver_reported ist jetzt nur noch {wait_min, ts, age_min} — die bisherigen Felder zum Vergleich von Prognose und Realität (prognosed_wait_min, diff_min, historical_section_mode, historical_weather usw.) wurden entfernt. section_mode, weather, advanced_wait_min und exceeds_crossing_time bleiben unverändert.

/api/v1/data/truck-bans gibt nun für jedes Land in bans_by_country einen status (active/clear) sowie active_window, next_window, local_time und tz zurück — berechnet in der jeweiligen Landeszeitzone, sodass Sie rohe Verbotsfenster nicht mehr selbst gegen die Uhr auswerten müssen. Die Antwort ergänzt außerdem eine covered_countries-Liste auf oberster Ebene und einen as_of-Zeitstempel in UTC.

GET /api/v1/data/truck-bans?country=PL

Rein additiv — die bestehenden Felder current_bans/upcoming_bans/bans_by_country bleiben unverändert. Ein unbekanntes ?country= gibt nun ein leeres Ergebnis mit countries_not_covered zurück statt der Verbote aller Länder.

Ein neues optionales Produkt, das die Standardwartezeit an den aktuellen Verkehrsfluss und das Wetter anpasst. Gibt die vollständige Aufschlüsselung jeder Anpassung zurück.

GET /api/v1/data/queue-advanced?ppid=id_13

Auf Anfrage freigeschaltet — öffnen Sie ein Data-Ticket in Ihrem Dashboard, um es zu aktivieren.

/api/v1/data/border berechnet nun korrekt wait_min für jeden Checkpoint in der Antwort, passend zu den Produkten queue und multi. Zuvor war dieses Feld stets null.

/api/v1/data/forecast verwendet nun zuverlässig das v4-Ensemble-Modell für jeden prediction_steps-Wert (zuvor konnten einige nicht standardmäßige Horizonte stillschweigend auf ein älteres Modell zurückfallen). Der Wetterfaktor, der in das Ensemble einfließt, wurde ebenfalls behoben und spiegelt nun tatsächlich die aktuellen Bedingungen wider (Regen, Schnee, Wind, Nebel), statt stets nicht verfügbar zu melden.

Freigeschaltete Entwickler können nun stündlich gemittelte historische Grenzwartedaten für bis zu 5 Checkpoints (gleitendes Fenster bis zu 90 Tage) als CSV oder NDJSON über den neuen Tab Data export herunterladen. Es werden nur veröffentlichte, qualitätsgeprüfte Daten bereitgestellt; Zeitstempel sind in UTC. Zugang benötigt? Öffnen Sie ein Data-Ticket.

Noch keine Website? Sie können jetzt ein Entwicklerkonto erstellen, indem Sie beschreiben, wo und wie Sie unsere Daten nutzen möchten, statt eine aktive Seiten-URL angeben zu müssen. Fügen Sie die echte URL später über Ihr Dashboard hinzu (Account & data → Ihr Projekt), sobald Ihre Website oder App live ist — ein sichtbarer Link zurück zu nakordoni.eu auf dieser Seite ist gemäß unseren Nutzungsbedingungen erforderlich.

Entwickler können nun eigene grenzbezogene News in die Nachrichtenlinie von Nakordoni einreichen. Wenn unsere Redaktion sie veröffentlicht, erhalten Sie einen indexierbaren Dofollow-Backlink zu Ihrem Dienst (Autorenzeile des Herausgebers + Quellenangabe) und wir übersetzen den Artikel kostenlos in alle 24 Sprachen.

Ein Artikel pro Woche ist kostenlos; weitere Artikel sind ein kostenpflichtiges Zusatzangebot. Wählen Sie 'wir dürfen leicht redigieren + interne Links ergänzen' oder 'unverändert veröffentlichen'. Einreichen und den Prüfstatus verfolgen unter Developers → Submit news.

Die Multi-Checkpoint API (/api/v1/data/multi) berechnet das Kontingent nun mit ⌈(N PPIDs × sub-products) / 2⌉ — die Hälfte der Kosten entsprechender Einzelaufrufe. Eine Anfrage für 10 Checkpoints mit beiden sub-products kostet nun 10 units statt 20. Der Header X-Devapi-Units und meta.units_consumed in der Antwort spiegeln den rabattierten Betrag wider.

Rufen Sie den aktuellen queue-Status und die Datenaktualität für bis zu 20 Checkpoints in einem einzigen API-Aufruf ab — konzipiert für Dashboard-Entwickler, die derzeit viele PPIDs in einer Schleife abfragen.

Das Kontingent zählt fair als N PPIDs × sub-products angefordert, sodass die Gesamtnutzung mit Einzelaufrufen identisch ist — jedoch mit einem Round-Trip statt vieler. GreenTravel-artige Muster sinken von 24+ Aufrufen/Stunde auf 2.

GET /api/v1/data/multi?ppids=id_2,id_13,id_15,id_59&include=queue,update-info&lang=en

• include=queue — aktuelles queue_now, geschätztes wait_min, Datenalter und Checkpoint-Name
• include=update-info — Datenaktualität, Quellenklassifizierung, Alter in Sekunden/Minuten
• Max. 20 PPIDs pro Anfrage; kombinieren Sie beide sub-products in einem einzigen Aufruf für vollständige Dashboard-Daten
• Die Antwort enthält meta.units_consumed, sodass Sie den Kontingentverbrauch präzise verfolgen können

Die Antwort des Produkts queue enthält nun ein snapshot-Objekt auf oberster Ebene mit den neuesten Echtzeitdaten und einer berechneten prognostizierten Wartezeit — dieselbe Formel wie im Hero-Bereich von nakordoni.eu:

snapshot.queue_now  — current cars in queue
snapshot.wait_min   — prognosed wait time (minutes)
snapshot.updated_at — when the queue data was recorded
snapshot.age_min    — minutes since last update
snapshot.source     — data source identifier

Das data-Array (historische Einträge) bleibt unverändert — dies ist eine rein additive Ergänzung. Clients, die snapshot nicht lesen, sind nicht betroffen.

Fragen Sie alle Checkpoints an einer bestimmten Grenze + einem Fahrzeugtyp in einem einzigen Aufruf ab, statt eine Anfrage pro PPID zu stellen.

GET /api/v1/data/border/{origin}/{destination}/{crossing_type}

• Unterstützt ein einzelnes Zielland, eine kommagetrennte Liste oder all, um auf einmal auf jeden überwachten Nachbarn zu erweitern.
• Ergebnisse aufsteigend nach queue_now sortiert (kürzeste Warteschlange zuerst).
• Vollständig lokalisiert: Fügen Sie ?lang=uk hinzu (oder eine unserer 22 unterstützten Sprachen), um Checkpoint-Namen in dieser Sprache zu erhalten.

Finden Sie die PPID-Werte von Checkpoints anhand des Namens, ohne das vollständige Verzeichnis zu durchsuchen.

GET /api/v1/data/search?name=Krakovets,Shehyni&lang=en

• Akzeptiert einen einzelnen Namen oder eine kommagetrennte Liste (bis zu 20).
• Durchsucht alle 24 Übersetzungssprachen — übergeben Sie einen Namen auf Ukrainisch, Polnisch, Deutsch oder in einer anderen unterstützten Sprache, und er wird gefunden.
• Gibt alle PPIDs an diesem Ort zurück, gruppiert nach Fahrzeugtyp (Pkw / Bus / Fußgänger / Lkw).

Das Produkt alternatives akzeptiert nun ?lang= in allen 22 unterstützten Sprachen (zuvor nur 12).

Der neue Parameter crossing_type ermöglicht es, den Fahrzeugtyp-Filter zu überschreiben — übergeben Sie z. B. crossing_type=4, um Pkw-Alternativen zu erhalten, auch wenn Sie von einer Bus-PPID aus abfragen.

Das Feld crossing_type_label in den Antworten von checkpoints, border und search wird nun in allen 22 unterstützten Sprachen in die angeforderte Sprache übersetzt. Die Ländernamen-Felder (origin_name, destination_name) folgen derselben Locale.

Das Nakordoni Developer API-Portal ist unter /en/developers live. Registrieren Sie sich für einen kostenlosen Explorer-Schlüssel (200 Anfragen/Tag), um auf Grenzwartedaten, Prognosen, Kraftstoffpreise, Fahrer-POIs und mehr zuzugreifen.

Zum Start verfügbare Produkte: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.