API-Änderungsprotokoll

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.

The retitle to "Live Queue & Freshness API" below did not actually reach the docs page. The page renders each product title through a translation lookup that falls back to the endpoint's title only when no translation exists — and a translation already existed, frozen at the old name, in all 25 UI languages. It now wins over any future update to the underlying title until it is updated too.

Retitled the translation key in all 25 languages so the docs page matches. No endpoint, parameter or response change — title text only.

If you poll live queue data frequently, you may be spending heavy quota you do not need to. /update-info is standard-class and already returns the live figure:

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

It returns queue_now, freshness, age_minutes, is_realtime, status, timestamp and timezone. Use it for the frequent refresh against your standard daily quota, and keep /queue, /multi and /forecast (all heavy-class) for when you need wait_min, the trend fields or history.

Nothing changed in the endpoint itself — only its documentation. It was listed as the "Data Freshness API" and its description mentioned only the freshness rating, never queue_now, so it was easy to miss. It is now titled "Live Queue & Freshness API" with the returned fields spelled out. Thanks to the developer who raised this.

Some failed requests were returning HTTP 200 with ok: true and the error buried inside data — so the documented if (!ok) throw pattern could not detect them, and the call was still billed. Affected calls now return HTTP 400 with ok: false and a proper error.code / error.message, as documented. Seen on fuel-cities with an unsupported country and travel-matrix with malformed coordinates.

Separately, a missing required parameter returned 500 internal_error instead of 400 bad_request (an upstream 4xx body was being discarded before its status was read). It now returns 400 bad_request with the upstream message — e.g. search without ?name=.

Successful responses are byte-for-byte unchanged — same fields, same params, same quota cost. If your client already branches on ok, no change is needed. If it ignored ok and read data directly, it will now see error envelopes on calls that were always failing.

Fixed a bug where /multi could return a wrong queue count for some checkpoints — mainly Balkan and Hungary–Serbia crossings — whenever its cache was cold. The fallback read a table that, for those crossings, holds no queue data, and reported unrelated values as car counts. Measured examples: a checkpoint with 12 cars reported 6, and several with real queues reported 0.

Three changes you may notice:

• found: false now means there is genuinely no recent queue data. Previously you could receive found: true with a fabricated queue_now: 0.
• wait_status, trend_percent and trend_direction are now returned on cold requests — they were null before.
• The endpoint also falls back when its cached snapshot is stale (older than 24h), not only when it is missing.

No changes to request parameters, quota cost or response shape.

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
• tmin/tpercar — aus queue, border und multi entfernt (die Konstanten der Wartezeitformel; das bereits berechnete wait_min/wait_time ist nicht betroffen)
• 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 tmin + queue×tpercar, 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 tmin, tpercar oder 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 (und gibt tmin/tpercar zurück) 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   — tmin + queue_now × tpercar (minutes)
snapshot.tmin       — minimum crossing time (minutes)
snapshot.tpercar    — added time per vehicle (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.