API-Änderungsprotokoll

On Fuel Prices, updated_at and the response's own age_hours/stale flag were running on different clocks: updated_at moves only when a price actually changes, but staleness was computed as if it moved on every confirmation. 46.7% of the priced index showed age_hours ≤48 and stale:false while updated_at was in fact more than 48 hours old, 12,620 stations over a week old. Each price now also carries confirmed_at — the last time we confirmed the price, hour-floored, never earlier than updated_at — and age_hours/stale are computed from it. updated_at's meaning is unchanged: use it when you want to know when the price last moved, use confirmed_at when you want to know how current it is right now. Not present on the frozen v1 contract.

Two language bugs, both silent: sending the canonical grade code as lang=pl (or any of the other 24 site languages) got fuel_type_local back in English regardless — only 10 languages were ever checked against the label table, so anything outside that list fell through to the default UI vocabulary rather than the language you asked for. Separately, lang=tr (or several other valid codes) answered station listings in Ukrainian, because an internal default of uk fired whenever the requested language did not sit in that same 10-language list. Both are fixed: the language you send is now the language you get, across all 25.

Also: brand on Nearby Fuel Stations no longer returns the raw ingest sentinel OTHER for the ~330 stations where we do not know the brand — it is null, consistent with every other unknown field in the response.

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   — (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.