API változásnapló

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.

A határ AI-asszisztens (/api/v1/data/assistant) 503 internal_error hibát adott — „Az asszisztens átmenetileg nem érhető el” —, ha ugyanaz a kulcs öt percen belül kétszer tette fel ugyanazt a kérdést. Valójában semmi nem volt elérhetetlen: az esetek többségében a válasz már ki volt számítva, és készen állt a kiadásra. Mostantól rendben visszakapja, ok: true és HTTP 200 értékkel.

Ha az ismétlés akkor érkezik, amikor az első válasz még készül, a hívás mostantól 429 kódot ad, az error.code mezőben duplicate_request értékkel az 503 helyett, így az újrapróbálkozási logika meg tudja különböztetni a „kérdezd meg újra egy pillanat múlva” esetet a valódi kimaradástól. Mindkét eset a fiók hibaarányába is beleszámított szerverhibaként; ez már nincs így. Magán a kérésen semmi nem változik — nincs új paraméter, nincs új verzió. A duplicate_request a referenciában a többi hibakóddal együtt szerepel.

A kamionparkolók (/api/v2/data/truck-parkings) olyan bejegyzéseket is visszaadtak, amelyeknél a name értéke null volt, az address pedig üres — Bensheim közelében 50-ből 20. Ezeket a helyeket csak koordinátaként tartjuk nyilván: nincs mit megjeleníteni, és nincs mihez illeszteni a saját POI-készletét. Már nem részei ennek a terméknek: mostantól csak névvel rendelkező helyeket ad vissza, jelenleg több mint 22 000-et Európa-szerte. Ha eddig maga szűrte ki a név nélküli bejegyzéseket, az a kód most felesleges, de ártalmatlan. A válaszok azonos radius és limit mellett rövidebbek lesznek, és minden visszakapott bejegyzés használható.

Ettől függetlenül mintegy 10 000 parkoló name mezőjében nyers koordinátapár állt, például 51.927301,10.14112, miközben a valódi megnevezés az address mezőben volt. Mostantól ezt a megnevezést viselik — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — mindenhol, ahol megjelennek, így a /api/v1/data/pois végponton is. Az egyes helyek id értéke változatlan, így a gyorsítótárazott megfeleltetés érvényes marad; csak a name más.

A snapshot.updated_at a /api/v1/data/queue és a /api/v1/data/multi végponton a határátkelő saját zónája szerinti helyi idő (például Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), és eddig a válaszban semmi nem jelezte, melyik zónáról van szó, így a hívó nem tudta konkrét időponthoz kötni. A snapshot kiegészül egy timezone mezővel (IANA-név) az updated_at mellett. Nincs új paraméter, nincs új verzió, a többi mező nem változik.

Eddig minden üzemanyag-végpont kézzel írt listával írta le a saját lefedettségét: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, és Lengyelország ebben a Trójmiasto térségére szűkült. Mindkét állítás régen elavult. A lefedettséget most az állomások élő indexéből mérjük, és hatóránként számoljuk újra: 39 országban van ma áras töltőállomás, köztük Lengyelországban országszerte, nem három városban. Magán a kérésen semmi sem változik: se paraméter, se verzió.

Közeli töltőállomások és Legolcsóbb üzemanyag: ha a keresés üresen tér vissza, a coverage blokk mostantól mért station_countries, station_counts, sparse_coverage és measured_at értékeket hoz, a kért fajtára szűkítve, nem az üzemanyagra általában. Egy ország akkor kerül a sparse_coverage listába, ha legfeljebb 25 áras állomásunk van ott — ez számolás, nem megítélés.

Új megjegyzés jelenik meg arra a fajtára, amelyet ismerünk, de amelyet ott, ahol kérdezett, senki sem áraz. Eddig a coverage.fuel_type_note csak akkor jelent meg, ha maga a kútnév volt ismeretlen számunkra. Mostantól akkor is megjelenik, ha a név helyesen feloldódik, de az adott országban egyszerűen nincs rá ár; megnevezi azokat az országokat, ahol az a fajta árazva van, és azokat a fajtákat, amelyeket a környezetében árazunk. A cseh Natural 100 kútnév a tiszta példa: feloldódik, de Csehországban egyetlen forrás sem ad rá árat. Az üres válasz így többé nem tűnik elrontott kérésnek.

Az Üzemanyagfajták (/api/v2/data/fuel-grades) minden fajtához megkapja a priced_countries és a priced_station_counts mezőt, továbbá a priced_here mezőt, ha megadja a ?country= paramétert. A két lista mást jelent: a countries alatti ország az, ahol elfogadjuk azt a kútnevet, a priced_countries pedig az, ahol egy forrás valóban árazza, ezért a priced_here nulla értéke valódi válasz, nem hiány a válaszban. A válasz emellett coverage_measured_at és coverage_note mezőt is hoz, a Cache-Control pedig 24 óráról 6-ra csökken, az újraszámítás gyakoriságához igazodva.

Több helyi kútnév is feloldódik, köztük a Klimadiesel 90 (HVO100) és a HVO Diesel, az Erdgas és a Metano, az Autogas és az Autogaz, a DEF az AdBlue-ra, valamint számos prémium dízel és benzin márkanév. A feloldás sorrendje változatlan, az egyeztetés pontos marad, így egyetlen korábban működő név sem jelent ma mást, egy új név pedig legfeljebb üres választ változtathat árakat tartalmazóvá. Ezzel egy időben a referenciadokumentációt és a végpontleírásokat a webhely mind a 25 nyelvén javítottuk.

Legolcsóbb üzemanyag (/api/v2/data/fuel-cheapest) a legközelebbi töltőállomásokat táv szerint rendezve adta vissza a legolcsóbbak helyett. Mivel a rangsorolás azelőtt történt, hogy az eredményt a limit értékre vágták volna, a sugáron belüli legolcsóbb töltőállomások teljesen hiányozhattak a válaszból. A rangsorolás ismét helyesen működik: elöl a kért üzemanyagfajta legolcsóbb ára, döntetlen esetén a közelebbi állomás nyer, és az adott fajtára árat nem közlő állomás kerül a végére. Magán a kérésen semmi nem változik — nincs új paraméter, nincs új verzió.

A v2 üzemanyag-válaszok szintén a tényleges kiszolgálásnak megfelelően vannak dokumentálva: az állomások a data.stations[] alatt érkeznek, fizikai állomásonként egy bejegyzéssel, minden üzemanyagfajta a prices objektumba ágyazva (price, currency, local_name, updated_at, age_hours, stale), valamint station_ref, grades, total_found és notices. A Közeli töltőállomások és a Legolcsóbb üzemanyag referenciája továbbra is a régi, lapos data.data[] sorlistát írta le.

A számlázási oldalon (havi fül) két kiegészítő érhető el bármelyik csomag mellé, a csomag módosítása nélkül: Extra előrejelzés-hívások — blokkonként +100 előrejelzés- és statisztikahívás naponta, blokkonként €2 havonta, legfeljebb 10 blokk; és Extra országok — egységenként +1 deklarálható ország, egyenként €2 havonta. A mennyiség módosításakor pontos, arányosított ajánlatot mutatunk, mielőtt bármit terhelnénk.

2026. november 10-től minden csomag meghatározott számú deklarált országot tartalmaz: Explorer és Student 4, Starter 10, Pro és afölött korlátlan. Ettől a dátumtól nem menthető olyan deklaráció, amely hosszabb a csomagnál plusz a megvásárolt extra országoknál; a Fiók fül már most mutatja a kereted, a keretet már meghaladó fiókok pedig javaslatot látnak az irányítópulton. November 10. előtt semmi nem változik.

Az API-sandbox mostantól minden végpontot megjelöl a választóban a kvótaosztályával (Nehéz / Alapvető), a kiválasztott verzió kvótaköltségét már futtatás előtt kiírja, hívás után pedig megmutatja, mennyibe került volna ugyanez a hívás az éles kvótádból — beleértve a ceil(N ppids × M sub-products / 2) képletet, amelyet a /multi alakú hívásokra használunk.

Ez csak olvasható előnézet: maguk a sandbox-hívások a különálló sandbox tesztkeretedből fogynak, soha nem az éles kvótádból.

A mai naptól minden, aminek a kivezetését nyilvánosan bejelentettük, zárva van a bejelentés napján vagy azt követően létrehozott fejlesztői fiókok előtt. Ha a fiókod már a bejelentés előtt létezett, semmi nem változik — megkapod a teljes türelmi időt, egészen a kivezetés dátumáig, amelyet a bejelentő bejegyzés megadott.

Miért van erre szabály. 2026. augusztus 24-én bejelentettük, hogy a truck-bans v1 2026. szeptember 8-án kivezetésre kerül. Két fiók a bejelentés után néhány nappal regisztrált, a v1-re építette az integrációját, és órákra került egy 410 hibától anélkül, hogy bármelyik levelünk elérte volna őket: a bejelentés és az értesítési kör is megelőzte a regisztrációjukat. Az API-ban semmi nem akadályozta meg őket abban, hogy olyan verziót vegyenek használatba, amelyről már megmondtuk, hogy megszűnik. Ez a mi hibánk volt, és ez a javítás — nem lehet újonnan használatba venni olyasmit, aminek az eltávolítása már be van ütemezve.

Hogyan néz ki. Az ilyen hívást a rendszer 410 Gone válasszal és version_closed_to_new_accounts hibakóddal utasítja el. Az üzenet megnevezi a kivezetés dátumát, a bejelentés dátumát és a helyette használandó verziót. Szándékosan más kód, mint a version_sunset, amelyet minden fiók megkap, miután maga a kivezetési dátum elmúlt — a támogatás így naplók olvasása nélkül is meg tudja különböztetni azt, hogy „túl későn érkeztél ahhoz, hogy elkezdd”, attól, hogy „ez mindenki számára megszűnt”.

A szerzett jogok a fiók létrehozásának dátumához igazodnak, nem az első híváshoz. Ha a bejelentés előtt regisztráltál, de csak most kezded az integrációt, akkor is megkapod a teljes türelmi időt: elképzelhető, hogy végig erre fejlesztettél.

Mostantól érvényes a truck-bans v1 esetében (bejelentve 2026. augusztus 24-én, kivezetés 2026. szeptember 8-án), és automatikusan minden ezután bejelentett kivezetésre. Semmi újat nem kell tenned: a kivezetés alatt álló verzión minden válasz már most hordozza a Deprecation, Sunset és Link: rel="successor-version" fejléceket, így egy új integráció a közelgő kivezetést ennek az oldalnak az elolvasása nélkül is látja.

A tegnapi v4-változás folytatása (fejlesztői jegy #105). A v1 és v2 vesszővel elválasztott destination listái továbbra is működnek, de mostantól ugyanaz a határidő vonatkozik rájuk, mint a destination=all értékre: mindkettő 2026-10-06 napján áll le (addig Deprecation/Sunset fejlécek, utána 400 destination_list_removed, amely a /api/v4/ végpontot nevezi meg pótlásként). A vesszős listák meglévő, 10 elemes korlátja addig a dátumig változatlan.

A v4 továbbra is hívásonként egy célt fogad — ez ma nem változott. Csak az változott, hogyan kommunikáljuk a v1/v2-t: a destination=all 400-as hibája már nem javasol vesszős listát migrációs útként (ugyanazon a napon szűnne meg), hanem egyenesen a v4-re mutat.

Dokumentációs javítás: a v4 példa ezen az oldalon korábban így szólt: /api/v4/data/border/1/2,3,4/9 — ez vesszős lista, amelyet a v4 elutasít. Mostantól /api/v4/data/border/1/2/9. Aki a régi példát másolta, az első hívásnál 400-as hibát kapott volna; elnézést kérünk.

Új fordított kulcs: a product_border_v4_p_destination az oldal mind a 25 nyelvén megjelenik, és kifejezetten kimondja a v4 egy-cél szabályát, ahelyett hogy a v1/v2 megfogalmazására esne vissza.

/api/v4/data/border/{origin}/{destination}/{crossing_type} mától élesben elérhető. A v2-höz képest három dolog változik, és együtt ezek adják az okát annak, hogy ez új verzió, nem pedig módosítás.

1. Nincs többé destination=all. Az adatainkat országonként licenceljük (Developer API Terms, 7. szakasz), és egy olyan helyettesítő érték, amely "minden szomszédra kiterjed, amelyről adatunk van", olyan országokat is visszaad, amelyekre a fiókja esetleg nincs jóváhagyva — anélkül, hogy a kérésben bármi jelezné ezt. A v4-ben Ön nevezi meg az országot.

2. Hívásonként egy célország. A /api/v4/data/border/1/2/9 egyetlen határt kérdez le. A vesszővel elválasztott listákat nem fogadjuk el: küldje az 1/2/9, 1/3/9 és 1/4/9 hívásokat külön. A vesszős lista vagy az all 400 választ ad, és megnevezi a pontosan elküldendő hívásokat, így semmi sem hiúsul meg némán.

3. Egyetlen teherautó-kód. A v1 és a v2 a teherforgalmat 8 (Freight Transport) és 9 (Freight Transport up to 7.5 t) kódra bontotta. Ez a bontás valóban létezik az átkelőn, de egyetlen integrátor sem tud mit kezdeni vele: a v2-től 9 kódra kérdezve az UA-PL határon a 70 teherautós átkelőből 21 érkezett vissza, és semmi nem jelezte ezt. A v4 a 9 kódra minden teherautós sávval válaszol, és a 8 kódot a 9 aliasaként fogadja el. Minden sor a saját crossing_type értékét hordozza, így az összevont válasz ellenőrizhető marad.

A v1-ben és a v2-ben a destination=all 2026. október 6-ig tovább működik, és addig Deprecation / Sunset fejléceket hordoz. Ettől a dátumtól ezek a verziók is 400 választ adnak az all értékre — a v1 és a v2 többi része érintetlen marad és elérhető marad. Ugyanez a dátum vonatkozik a többi minden-ország rövidítésre is: travel-matrix ?dest= nélkül, bus-carriers ?ppid=all paraméterrel és fuel-grades ?country= nélkül.

A ma korábban bejelentett v3-at a v4 váltja fel. A v3 csak abban tért el a v4-től, hogy továbbra is elfogadta a vesszős listát, és egyetlen integráció sem használja ezt a formát. A v3 URL-ek továbbra is válaszolnak, így nem törik el semmi, amit rájuk írtak, de a v3 nincs dokumentálva és nem fejlesztjük tovább — térjen át a v4-re.

A v4-ben minden más azonos a v2-vel: az útvonal irányfüggő sorrendje, a direction{from,to}, a stale és a ?max_age_min=.

A /border/{origin}/{destination}/{crossing_type} útvonalban szereplő numerikus azonosítókat soha nem tettük közzé táblázatként, így az integrátorok időzónákból és minta-URL-ekből állították össze őket. Mostantól megtalálhatók a dokumentációban, az Ország- és járműtípus-kódok részben, ugyanazokból a táblákból generálva, amelyekhez az API validál — az országazonosítók az általuk lefedett határokkal együtt, és minden crossing_type azzal a címkével, amelyet az API visszaad.

A közzététel közben derült ki, hogy a sandbox és a végpont metaadatai a 8 kódot "truck<7.5t", a 9 kódot pedig "truck" néven írták le. Ez fordítva van: az API a 8 kódot Freight Transport, a 9 kódot Freight Transport up to 7.5 tons néven jelöli, és mindig is így volt. Ha a teherautó-kódot a paraméter súgójából választotta ki, akkor a szándékolttal ellentétes sávra szűrt. Mindenhol javítva, a v3 pedig teljesen megszünteti ezt a választást.

Az API Terms v1.1 még azelőtt váltja fel a v1.0-t, hogy az hatályba lépett volna, és 2026. október 6-tól alkalmazandó. Kérjük, fogadja el a vezérlőpultján.

A 7. szakasz mostantól kimondja, mi a Piac: az az ország, amelynek adatait használja — ahol a lekérdezett átkelő vagy határ található —, nem pedig az az ország, ahol a felhasználói élnek. A vezérlőpultunk különböző helyeken mindkettőt állította; az érvényesítés mindig az elsőt jelentette.

Két változás az Ön javára. A fiókjához már jóváhagyott országok használhatók maradnak, amíg egy későbbi módosítás elbírálás alatt áll (egy ország hozzáadása többé nem függeszti fel a meglévőket). Ha pedig 5 munkanapon belül nem válaszoltunk egy piacbejelentésre, addig a teljes csomaglimitjei érvényesek.

A 10.3. szakasz mostantól megfelel annak, amit a vezérlőpult ténylegesen kér, a 13.2. szakasz pedig olyan rendelkezésre állási alapot rögzít, amelyet mérünk és meg tudunk mutatni Önnek.

Három termék mostantól kiegészítő data_quality mezőt (high vagy low) tartalmaz, amely jelzi, hogy egy leolvasás valós megfigyelés-e, vagy modellbecslés, amely mögött az adott átkelőn nincs élő számlálási forrás: queue (a legfelső szintű snapshot objektumon és a data[] tömb minden historikus sorában — az előrejelzési sorokon nem szerepel), update-info (a burkolón) és multi (átkelőnként a queue és az update_info alobjektumon egyaránt). Ez nem új jelzés — a mögöttes jelző belsőleg már létezett —, de soha nem tettük közzé, így egy teljesen modellezett átkelő ugyanúgy nézett ki, mint egy közvetlenül mért. Az is_realtime szándékosan változatlan: modellezett soroknál továbbra is true értéket ad, ennek a jelentésnek a megváltoztatása pedig v2-szintű törő változás lenne, amit itt nem hajtunk végre.

Szintén ebből a kiadásból: a queue-advanced termék többé nem osztja tovább a nyers, forrásoldali időjárási adatokat. A weather_main, a temperature és a wind_speed helyére egy származtatott condition_code (0–5 veszélyességi skála, null, ha nincs elérhető időjárási adat), a condition és a severity lép.

2026-08-30-tól egy /api/v1/data/multi kérés legfeljebb 5 határátkelőre kap választ. A több PPID-t felsoroló hívást nem utasítjuk el: továbbra is 200-at ad vissza, de csak a ?ppids= paraméterben szereplő első 5 azonosítóra érkezik válasz. A többi azonosítót figyelmen kívül hagyjuk, visszaadjuk a meta.ppid_cap.ignored mezőben, és nem terhelik a kvótádat — a hívás azt számlázza, amit ténylegesen visszaad.

Amíg egy hívás a limit felett van, a válasz tartalmazza az X-Devapi-Warning: multi_ppid_cap fejlécet és egy meta.ppid_cap blokkot a következő mezőkkel: cap, enforced_from, enforced, ppids_asked, ppids_answered és ignored[]. 2026-08-30-ig ezek a mezők enforced: false értékkel és a teljes eredményhalmazzal jelennek meg, így a közelgő változást a saját naplóidban is látod.

A felére szóló kvótakedvezmény változatlan. Oszd a határátkelőidet 5-ös csoportokra, és a szokásos frissítési ciklusodban csoportonként küldj egy hívást; ha gyakran csak a sorhosszt és az adatok frissességét kérdezed le, az update-info marad az olcsóbb, standard osztályú termék.

Az Ukrajnára számított hőségtilalom — az include_ua_heat paraméterrel, country=UA esetén pedig automatikusan érkezik — mostantól a kért dátumtartományra válaszol. Korábban a következő hét napot adta vissza, bármit is mondott a date_from és a date_to, így egy decemberi ablak csendben az e heti sorokat hozta. A tilalmat időjárás-előrejelzésből számítjuk, nem a tilalmi naptárból olvassuk, ezért két olyan határa van, amely a naptárnak nincs: nem néz vissza, és ott ér véget, ahol az előrejelzés. Az ablakot mostantól metsszük azzal, amit az előrejelzés valóban lefed, az új ua_heat_ban.forecast_horizon mező pedig megnevezi az utolsó elérhető dátumot. Az ezen a horizonton túli ablak nem ad vissza sort, és a summary mezőben megindokolja — ez nem azonos azzal, hogy „nincs tilalom”. A v1 válaszok változatlanok.

A válasz szerkezete eddig sehol nem volt leírva — csak hívással lehetett megtudni, mit ad vissza egy termék. Mostantól minden termék oldalán, a paramétertáblázat alatt szerepel egy Válaszmezők táblázat az egyes mezők rövid leírásával; a listaelemek mezői így jelennek meg: items[].name, a boríték szintjén álló mezők (usage, meta, snapshot, resolved_location) pedig előtag nélkül. 42 termékből 40 dokumentált: a két még el nem indított (weather, road-quality) szándékosan marad leírás nélkül. Ugyanez a táblázat kerül a nyilvános GitHub-dokumentációnkba is.

Minden üzemanyagtermékünk elfogadja mostantól az üzemanyagfajta helyi nevét, nemcsak a saját belső írásmódunkat: ON Lengyelországban, Nafta Csehországban, Gázolaj Magyarországon, Motorină Romániában, ДП Ukrajnában, Motorin Törökországban, Gasóleo Portugáliában és Spanyolországban. A nevet elsősorban ország szerint értelmezzük — a „95” egy dán kútnál E10, egy lengyelnél E5 —, ezért küldje a country paramétert a helyi névvel együtt, vagy olyan koordinátát, amely alapján elhelyezhetjük a pontot. A válasz tartalmazza a fuel_type (kanonikus), fuel_type_requested (ahogy beírta) és fuel_type_local mezőt. Amit nem tudunk elhelyezni, azt soha nem cseréljük alapértelmezett fajtára: a válasz üresen tér vissza, és ezt meg is mondja.

A teljes táblázat mostantól önálló termék — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — kanonikus üzemanyagfajtáink és helyi nevük 41 európai országban, azokat a piacokat is beleértve, ahonnan nem közlünk árat. A fuel és a fuel-local ország- és régiószintje ezenfelül kapott egy grades objektumot, amely minden árkulcsot a fajtájához és a kútnál használt nevéhez rendel.

A truck-bans termék mostantól adott dátumra vagy dátumtartományra is válaszol a következő végponton: /api/v2/data/truck-bans. Eddig mindig a következő 7 napot adta vissza, és figyelmen kívül hagyta a küldött dátumot, ezért egy naptár összeállításához naponta egy kérésre volt szükség — másodpercenként két kérést engedő csomagban pedig ezek nagy részét elutasítja a következő hibával: 429 qps_exceeded.

Használja a ?date=YYYY-MM-DD paramétert egyetlen naphoz, vagy a ?date_from= és ?date_to= párost tartományhoz. Mindkét végpont beleértendő, és bármelyik elhagyható: a kezdet alapértelmezés szerint a mai nap, a vég pedig a kezdet plusz 7 nap. Egy ablak legfeljebb 92 napot fedhet le — a hosszabbat elutasítja a 400 date_range_too_long hiba, ahelyett hogy csendben levágná. Ez előretekintő naptár: egy ablak legfeljebb 7 nappal ezelőtt kezdődhet, a régebbi dátumokat elutasítjuk, nem szolgáljuk ki — a lefedettség előre 2028. december 31-ig tart, 23 országra.

Minden válasz mostantól tartalmaz egy window objektumot, amely megnevezi a pontosan lefedett tartományt. Ez kiegészítő mező, és a v1-ben is elküldjük, ahol a v1 változatlanul megtartja a rögzített 7 napos ablakát. Figyelem: az include_ua_heat mindig a következő 7 napot fedi le, bármilyen ablakot kér — időjárás-előrejelzésből számítjuk, nem a tilalmi naptárból. Emlékeztetjük, hogy a termék v1 változata 2026. szeptember 8-án megszűnik.

Két kapcsolódó fejlesztés az egész API-ban: minden olyan paraméter, amelyet a termék nem fogad el, mostantól megjelenik a válasz ignored_params mezőjében, ahelyett hogy csendben elveszne; az adatszolgáltatás érvényesítési hibái pedig szó szerint jutnak el Önhöz, a géppel olvasható kóddal az error.reason mezőben.

Három válaszminőségi javítás egy átjáró-auditból (#43-as jegy).

Az X-API-Key fejlécet mostantól elfogadjuk az Authorization: Bearer és a ?key= mellett. Ha a HTTP-kliense X-API-Key nevű fejlécben küldi a kulcsokat, ez mostantól működik — korábban a rendszer csendben figyelmen kívül hagyta, és a hívást missing_api_key hibával utasította el. Az Authorization: Bearer marad a dokumentált, ajánlott forma.

A hiányzó kulcsról szóló hibaüzenet mostantól mindhárom hitelesítési módot megnevezi (Bearer fejléc, X-API-Key fejléc vagy ?key=), nem csak a regisztrációs oldalra hivatkozik.

A checkpoints katalógus minden sora mostantól tartalmazza a has_day_stats mezőt — ez egy kiegészítő logikai érték, amely megmutatja, van-e adata a „Legjobb átkelési idő” (day-stats) API-nak az adott határátkelőre. A day-stats csak a figyelt határátkelők egy részére létezik; lekérdezés előtt ellenőrizze ezt a jelzőt, hogy elkerülje a kiszámítható 404-eket. A meglévő mezők változatlanok.

A dokumentációban szintén javítottuk: a road-conditions termék mindig figyelembe vette a lang paramétert a címkék honosításához — csak nem volt felsorolva.

Két javítás és egy új verzió a truck-bans termékhez.

A vesszővel elválasztott országok mostantól működnek. A ?country= legfeljebb 3 ISO-2 kódból álló listát fogad el, például ?country=DE,RO. A hosszabb listát 400 too_many_countries hibával utasítjuk el, nem vágjuk le csendben — ez országonkénti tilalomnaptár, nem tömeges adatfolyam. Korábban ez nem működött: az elválasztó karakter eltűnt, így a DE,RO egyetlen DERO tokenként olvasódott be, semmire sem illeszkedett, és success: true választ adott total_bans: 0 értékkel — magabiztos „nincs tilalom” két olyan országra, amelyeknek együtt 22 volt. Ha ezt országonként külön kéréssel kerülte meg, most egyetlen kérés mindet lefedi, és több helyett egy hívásba kerül.

A válaszok mostantól jelzik saját teljességüket. Három kiegészítő mező — returned, total_available és truncated — megmutatja, hogy a válasz meg lett-e vágva. Különösen a hatókör nélküli kérés ad vissza megvágott szeletet, és eddig semmi nem utalt erre a válasz tartalmában. A total_bans megtartja eddigi jelentését (a válaszban szereplő sorok), így semmi nem változik abból, amit már feldolgoz.

A v2 országonkénti hatókörű. A /api/v2/data/truck-bans végponton a ?country= kötelező, a hatókör nélküli kérést pedig 400 scope_required hibával utasítjuk el — ez a termék országonkénti tilalomnaptár, nem tömeges adatfolyam. A v1 ma nem változik — továbbra is elfogadja a hatókör nélküli kérést, és továbbra is ugyanazt a megvágott 50 sort adja vissza, mint mindig, tehát semmi nem törik el abból, ami most fut Önnél. Ennek a terméknek a v1 verziója 2026. szeptember 8-án megszűnik. Szeptember 7-ig bezárólag normálisan kiszolgál; szeptember 8-tól a v1 kérést 410 Gone hibával utasítjuk el, a v2-re mutató üzenettel. Addig minden v1 válasz tartalmazza a Deprecation: true jelzést, egy Sunset fejlécet ezzel a dátummal, és egy Link fejlécet, amely megnevezi az utódverziót, így egy kliensoldali könyvtár a határidőt anélkül is meg tudja jeleníteni, hogy bárki elolvasná ezt az oldalt. A migráláshoz: módosítsa a verziószegmenst /api/v2/data/truck-bans értékre, és adja át a ?country= paramétert.

Egy dokumentációs javítás: a date paramétert eltávolítottuk. Hosszú ideje szerepelt a listán, de a szolgáltatás soha nem olvasta be, így minden kérés, amely elküldte, csendben az alapértelmezett 7 napos ablakot kapta a kért nap helyett. Egy nap kiválasztásához szűrje az upcoming_bans tömböt a date mezője szerint. Egy ISO-3 kód, például a DEU, szintén nem oldódik fel többé országnévvé az összegzésben, ahol a félrevezető „No truck ban data for: Germany.” szöveget eredményezte.

A truck-bans termék mostantól további öt ország országos forgalomkorlátozásait adja vissza: Belgium (BE), Belarusz (BY), Montenegró (ME), Észak-Macedónia (MK) és Svédország (SE). A Bulgáriára, Görögországra és Portugáliára vonatkozó meglévő lefedettség bővült és frissült — a görög korlátozások immár 2027 szeptemberéig tartanak, Portugália pedig ismét fel van töltve adatokkal.

A válasz szerkezete nem változott. Az új sorok ugyanazokat a kulcsokat tartalmazzák, mint bármely más korlátozás: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons és details_url. Ha egy korlátozás csak feltétellel érvényes — a belarusz nyári tilalmak például 25 °C felett lépnek életbe — a feltétel a restriction_details mezőben szerepel, ezért olvassa el ezt a mezőt, mielőtt figyelmeztetne egy sofőrt. A min_weight_tons értéke null, ha a szabály nem tonnázsra, hanem szállítási osztályra (veszélyes áru) vonatkozik.

A fuel-stations és a fuel-cheapest termék mostantól állomásszintű árakat ad vissza Lengyelországban. A lefedettség részleges — a Hármasváros térsége (Gdańsk, Gdynia, Sopot) — ezért Lengyelország egy új, kiegészítő coverage.sparse_coverage tömbben szerepel a meglévő coverage.station_countries lista mellett. A sparse_coverage listában szereplő országoknak csak a területük egy részére van állomásadatuk; az adott ország más pontján indított lekérdezés a korábbiakhoz hasonlóan üres listát ad vissza a lefedettségi megjegyzéssel együtt. A lengyel árak PLN pénznemben szerepelnek.

A tömeges lekérdezés hibaüzenete is világosabb: ha hiányzik a lat, a scope_required üzenet mostantól a fuel termékre (?country=XX) mutat az országos átlagárakhoz.

A(z) GET /api/v2/data/fuel-local?lat=&lon= mostantól két helyett három szinten oldja fel az árat: station, majd region, majd country. Az új középső szint Ukrajnához készült, ahol sehol nincs kutankénti ár: egy ukrajnai pont mostantól a saját megyéjének átlagát kapja az országos átlag helyett, és csak akkor esik vissza az országos átlagra, ha a megyére nincs jegyzés.

A(z) region szint válasza tartalmazza a megye kódját (ISO 3166-2 érték, például UA-46), a(z) region_name és region_center_dist_km mezőt, valamint ugyanazokat az árkulcsokat, mint az országszint. A kódot továbbra is a(z) resolution alapján ágaztassa el, soha ne a válasz alakja alapján; a(z) station és country válaszok változatlanok.

Az új GET /api/v2/data/fuel-local?lat=&lon= végpont Európa bármely pontjára visszaadja a legjobb elérhető üzemanyagárat. Ahol van kutankénti adat, a legközelebbi kutak áraival válaszol, egyébként annak az országnak az országos átlagával, amelyben a pont található – így Ukrajnáéval is, ahol sehol nincs kutankénti ár.

Minden válasz tartalmazza a resolution mezőt, amely megnevezi a válaszoló szintet: station (kutak listája distance_km értékkel, mindegyik a saját pénznemében) vagy country (egyetlen objektum az országos átlagokkal). A kódot a resolution alapján ágaztassa el, soha ne a válasz alakja alapján. A /api/v2/ verziótól érhető el; a fuel, a fuel-stations és a fuel-cheapest változatlan.

A fuel-stations és fuel-cheapest termékek mostantól jóval több németországi töltőállomást fednek le, az árak pedig egész nap frissülnek — a vidéki területeken is. A fuel_type paraméter 13 üzemanyagtípust fogad el: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 és lng. Ha egyetlen töltőállomás sem felel meg a lekérdezésnek, a válasz tartalmaz egy coverage objektumot azon országok listájával, amelyekhez van töltőállomás-adat.

A radius= paramétert mostantól kompatibilis aliasként fogadjuk el a radius_km helyett minden olyan termékben, amely dokumentálja. A fuel-stations és fuel-cheapest termékek néma üres válasz helyett egy additív coverage objektumot adnak vissza (a töltőállomás-adatokkal rendelkező országok listája és egy megjegyzés), ha egyetlen állomás sem illeszkedik. A route-plan határobjektumai mostantól tartalmazzák az additív wait_basis kulcsot (car_lane vagy vehicle_lane), így a kliensek látják, mikor helyettesíti a kamionos várakozási adatot a személyautósáv adata. Az útvonal menti kamionos határátkelők párosítása lényegesen pontosabb: a személyautósáv adatai tartalék megoldásként azoknál a határpároknál, ahol nincs kamionsáv-adat, védelem a rossz irány ellen, szigorúbb távolsághatár, valamint az azonos pozíciójú átkelők deduplikálása. Minden változás additív, nincs kompatibilitástörő módosítás.

A fejlesztői nyitóoldalon most horgonyzott szekciók vannak (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) ugrónavigációval, és minden termékkártya a saját dokumentációs oldalára mutat. Az új Mobile apps szekció bemutatja a Kordon Online-t és a Truck Bans-t Google Play linkekkel. Fordítási pótlás: a fizetési előzmények, a bejelentkezési hibák, a sandbox linkek és a csomagválasztó gomb mind a 25 nyelven lokalizálva vannak.

A flotta beacon válasza (POST /api/v1/fleet_position.php) most tartalmaz egy messages tömböt, amely a tulajdonostól a sofőrnek szóló függőben lévő üzeneteket kézbesíti. Új, csak tulajdonosoknak szóló élő JSON-hírfolyam (?ajax=live) és egy „Üzenetek a sofőröknek” kártya a flottapanelen. Új sofőrmeghívó oldal: /{lang}/get-nakbus (25 nyelven).

A product_fleet_vehicles/live/history cím, leírás és paraméterei, valamint a flottaelőzmény-paraméterek mind a 25 fejlesztői portál nyelven lokalizálva lettek.

A /api/v1/data/truck-bans mostantól ugyanazt a legfelső szintű mezőkészletet adja vissza, függetlenül attól, hogy melyik lekérdezés váltotta ki a választ. Korábban egy naptári tiltás nélküli országra vonatkozó lekérdezés, egy fel nem ismert ppid, vagy egy normál adatbázis-találat mindegyike eltérő mezőket hagyhatott ki (pl. country, covered_countries, ppid). Most minden válasz következetesen tartalmazza a következőket: 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 és upcoming_bans (null vagy üres, ahol nem alkalmazható), ami egyszerűsíti a kliensoldali feldolgozást.

Kilenc új, szolgáltatásonkénti termék. A helyalapúak lat/lon vagy city + country paramétert fogadnak (a várost mi geokódoljuk ön helyett): /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 (állomások az adott üzemanyagtípus ára szerint rangsorolva) és /api/v2/data/internet-points; az eredmények tartalmazzák a distance_km értéket, és a radius korlátozza őket. A /api/v2/data/vignettes megválaszolja, hogy egy ország igényel-e matricát, aktuális árakkal. A meglévő pois termék mostantól a dokumentáció szerint támogatja a lon és radius paramétereket, és a fuel termék mode=nearest módja is elfogadja a lon-t. Mind a kilenc elérhető a sandboxban.

Minden tilalom a /api/v1/data/truck-bans végpontban most tartalmazza a restriction_type-ot (General / Local / Sunday / Holiday / Seasonal), a restriction_details-t (pontos érintett terület vagy útvonalak) és a min_weight_tons-t. A details_url mostantól az egyes országokra vonatkozó nakordoni.eu oldalakra mutat. Egy új, opcionális lang paraméter választja ki az országnevek és az összefoglaló nyelvét; az alapértelmezett most az angol.

A hibás ?ppid= mostantól a valódi okot adja vissza a szűkszavú "Request failed" helyett: a hiba megnevezi a paramétert, a várt id_<number> formátumot, és a /api/v1/data/checkpoints címre mutat. A(z) stats, forecast, update-info, weather és bus-carriers paramétertáblái mostantól mind a 25 nyelven mutatják az id_13 példát.

Az újratervezett portálfelület (felső sáv, ikonos oldalsáv, KPI-irányítópult, kártyás elrendezés) mostantól az alapértelmezett minden bejelentkezett fejlesztői fióknál — a tervezett augusztus 10-i bevezetésnél korábban. A klasszikus elrendezéshez bármikor visszatérhet a ?v=1 használatával.

A fejlesztői portál összes oldala — nyitóoldal, dokumentáció, irányítópult, AI Studio, homokozó, hibajegyek, kérelmek, exportálás, flotta, hírek, változásnapló és fiókoldalak — többé nem tölt be semmilyen hirdetési szkriptet vagy hirdetési helyet. Ez a teljes portálra vonatkozik, nem csak a bejelentkezésre és a regisztrációra, mint korábban.

Tervezze meg az egész határátkelős utat egyetlen hívással: a /api/v2/data/route-plan visszaadja az útvonalat, a rajta ténylegesen fekvő átkelőket élő sorral vagy az érkezési idejére szóló előrejelzéssel, és a megállókat, amelyeket a sofőr valóban megtesz – pihenő, étkezés, tankolás – egyetlen idővonalon.

A határ része ennek az idővonalnak. A hosszú sor beszámít az amúgy is esedékes pihenőbe és nullázza a vezetési időt, így a háromórás várakozás soha nem jelenik meg három óraként plusz egy teljes, meg nem tartott pihenőcsomag. A személyautókra vezetési higiéniai modell vonatkozik; a buszokra és kamionokra az EU 561/2006 kötelező pihenőideje, a buszok szervizideje pedig több mint 1000 engedélyezett nemzetközi menetrenden van kalibrálva. A stop_places=1 minden megállóhoz valódi pihenőhelyet vagy benzinkutat nevez meg, a via=lat,lon pedig más átkelőn vezeti át az útvonalat.

Új a portál menüjében: Bemutató — a nakordoni adatplatform élő, mindig naprakész bemutatása, az Ön piacára szabva (biztosítás, utazás, logisztika, fuvarozók, média, navigáció, üzemanyag, fintech, közszféra vagy magánprojektek). Valós, 30 napos platformforgalmat, az Ön saját API-használatát, válaszidő- és limitstatisztikákat mutat, valamint csomagajánlást, amikor a hívások elérik az ingyenes szint határait. Válassza ki vagy erősítse meg piacát (piacait) az oldalon, a profiljában — vagy regisztrációkor. Az első látogatáskor automatikusan megnyílik; az automatikus megnyitás magán az oldalon kikapcsolható.

Ha egy asszisztensnél be van kapcsolva egy adatforrás, de a hívás nem hozza magával a hozzá szükséges kontextust — például queue a ppidnélkül —, az adatforrás mostantól már a kérés elküldése előtt kimarad, és nem kerül felszámításra. Korábban mégis meghívtuk, hibára futott, és így is egy egységbe került. A stúdió megmutatja, mire van szüksége az egyes adatforrásoknak, a kontextus kitöltésével újraszámolja az árat, és megjelöli az eredményeket: ✓ lefutott / ⊘ kimaradt, nincs díj / ✕ hibás; az API a data.feeds_skipped mezőt adja vissza, amely pontosan megmondja, melyik paramétert kell átadni.

A válaszok többé nem említenek adatforrásokat, adatforrás-neveket vagy bármi technikait: egy hiányzó adatforrás legfeljebb egyetlen egyszerű mondat a végfelhasználónak, soha nem belső név. A csak opcionális szűrőkkel rendelkező adatforrások (például a fuel , olyan országra szűkítve, amelyről nincs adatunk) mostantól a teljes adathalmazra esnek vissza ahelyett, hogy semmit sem adnának vissza.

Új: /{lang}/developers/studio. Építsen olyan MI-asszisztenst, amely az Ön tartalmából és a mi élő határadatainkból válaszol. Adja át a markdown fájljait, vagy csak nevezze meg az oldalakat, és mi letöltjük és indexeljük őket — Önnek csak a saját fájljait kell karbantartania. Válassza ki, mely adatforrásainkat használhatja (sor, előrejelzés, alternatívák, napi statisztika, üzemanyag, kamionstop, nyitvatartó vasárnapok, ünnepnapok, útviszonyok, buszos fuvarozók, POI-k, valuta), válasszon modellszintet (gyors / kiegyensúlyozott / pro — ez határozza meg az árat), írja meg saját utasításait {{feed.slug}} helyőrzőkkel, amelyek pontosan megadják, hova kerülnek adataink a válaszban, és fűzzön hozzá saját zárómondatot, amely minden válasz végére kerül. Kész sablonok: személyes utazási asszisztens, munka-/fuvarasszisztens, biztosítás- és zöldkártya-értékesítési asszisztens.

Tesztelje a stúdióban (napi 30 válasz, az API-kvótájától függetlenül), majd élesben hívja a GET /api/v2/data/assistant-custom?assistant_id=N&q=…címen. Válaszonkénti ár = a modellszint egységei + 1 egység minden bekapcsolt adatforrásért, az X-Devapi-Unitsfejlécben visszaadva. A termék csak v2-ben érhető el — egy v1-es URL unsupported_versionhibát ad. A meglévő assistant termék változatlan.

Minden asszisztens a platform tartalmi szabályzata alatt fut, amely megelőzi az Ön utasításait: tilos hatósági személynek kiadni magát, tilos segíteni a határ- vagy vámellenőrzés kijátszásában, tilosak a kitalált számok és a trágárság. Az utasításokat és a válaszokat is átvizsgáljuk; a blokkolt hívásokat naplózzuk.

Új: egy valódi MCP-szerver a https://nakordoni.eu/mcp címen, amely az API biztonságos, csak olvasható részhalmazát (status, checkpoints, border queue, live queue, forecast) MCP-eszközökként teszi elérhetővé. Ugyanaz az API-kulcs és kvóta, mint a REST API-nál. Szerverkártya a /.well-known/mcp/server-card.json címen. Lásd az MCP-szerver szakaszt a dokumentációban.

Az alább leírt átnevezés „Live Queue & Freshness API”-ra valójában nem jutott el a dokumentációs oldalra. Az oldal minden terméknevet fordításkereséssel jelenít meg, amely csak akkor esik vissza a végpont címére, ha nincs fordítás — fordítás pedig már létezett, a régi néven befagyasztva, mind a 25 felületi nyelven. Mostantól ez elsőbbséget élvez az alapcím bármely jövőbeli módosításával szemben, amíg magát a fordítást is nem frissítik.

A fordítási kulcsot mind a 25 nyelven átneveztük, így a dokumentációs oldal már egyezik. A végpont, a paraméterek és a válasz változatlan — csak a címszöveg módosult.

Ha gyakran kérdezi le az élő sor adatait, könnyen lehet, hogy fölöslegesen költi a nehéz kvótát. A /update-info normál osztályú , és már most is visszaadja az élő értéket:

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

Visszaadja a következőket: queue_now, freshness, age_minutes, is_realtime, status, timestamp és timezone. Használja a gyakori frissítéshez a normál napi kvóta terhére, a /queue, /multi és /forecast végpontokat (mind nehéz osztályúak) pedig tartsa fenn arra az esetre, amikor wait_minkell, illetve a trendmezők vagy az előzmények.

Magában a végpontban semmi nem változott — csak a dokumentációjában. „Data Freshness API” néven szerepelt, és a leírása csak a frissességi értékelést említette, a queue_nowmezőt soha, így könnyű volt átsiklani felette. Mostantól „Live Queue & Freshness API” a neve, a visszaadott mezők tételes felsorolásával. Köszönjük a fejlesztőnek, aki ezt jelezte.

Néhány sikertelen kérés HTTP 200 választ adott ok: true értékkel, a hibát pedig a data mezőbe rejtette — így a dokumentált if (!ok) throw minta nem tudta észlelni őket, a hívás mégis díjköteles volt. Az érintett hívások mostantól HTTP 400 választ adnak ok: false értékkel, valamint rendes error.code / error.messagemezőkkel, a dokumentáció szerint. Előfordult a fuel-cities terméknél nem támogatott országgal és a travel-matrix terméknél hibás koordinátákkal.

Ettől függetlenül: hiányzó kötelező paraméter esetén 500 internal_error jött vissza 400 bad_request helyett (a belső szolgáltatás 4xx törzsét eldobtuk, mielőtt a státuszát kiolvastuk volna). Mostantól 400 bad_request érkezik a belső szolgáltatás üzenetével — például search a ?name=nélkül.

A sikeres válaszok bájtra pontosan változatlanok — ugyanazok a mezők, ugyanazok a paraméterek, ugyanaz a kvótaköltség. Ha a kliense már az okértéke szerint ágazik el, nincs teendő. Ha viszont figyelmen kívül hagyta az ok mezőt, és közvetlenül a data mezőt olvasta, mostantól hibaborítékot fog látni azoknál a hívásoknál, amelyek eddig is mindig sikertelenek voltak.

Javítottunk egy hibát, amely miatt a /multi hibás sorhosszt adhatott vissza egyes határátkelőknél — főként a balkáni és a magyar–szerb átkelőknél —, valahányszor a gyorsítótára hideg volt. A tartalék útvonal olyan táblát olvasott, amely ezeknél az átkelőknél nem tartalmaz soradatot, és nem oda tartozó értékeket jelentett autószámként. Mért példák: egy 12 autós átkelő 6-ot jelentett, több valódi sorral rendelkező pedig 0-t.

Három változás, amely feltűnhet:

• found: false mostantól azt jelenti, hogy valóban nincs friss soradat. Korábban előfordulhatott, hogy found: true értéket kapott kitalált queue_now: 0mezővel.
• wait_status, trend_percent és trend_direction mostantól hideg kéréseknél is visszatér — korábban null volt az értékük.
• A végpont akkor is a tartalék útvonalra vált, ha a gyorsítótárazott pillanatképe elavult (24 óránál régebbi), nem csak akkor, ha hiányzik.

A kérés paraméterei, a kvótaköltség és a válasz szerkezete nem változott.

Kijavítottunk egy hibát, amely miatt minden /multi hívás kétszer került leszámlázásra — egyszer egy általános 1 egységes ellenőrzéssel, majd az endpoint saját, változó költségű képletével (N PPID × al-termékek). Egy hívás mostantól pontosan ⌈(N×M)/2⌉ egységbe kerül a dokumentációnak megfelelően, extra terhelés nélkül.

Emellett a dokumentáció oldalon minden termékhez hozzáadtunk egy Standard/Heavy kvótaosztály-jelvényt, hogy első pillantásra látszódjon, melyik napi kvótát terheli az adott endpoint.

A country és a countries egy paraméterré lett összevonva (1-15 vesszővel elválasztott kód). Új compare_to paraméter: azonos vs. eltérő ünnepek összehasonlítása országok között, kombinálható az upcoming+days paraméterekkel. A lang mostantól több nyelvet is elfogad (egy names objektumot ad hozzá). A days=0 vagy elhagyva az upcoming módban mostantól korlátlan mennyiséget jelent.

Hivatalos munkaszüneti napok európai országonként — dátumok, helyi elnevezések és típus. Ugyanaz a Nager.Date / OpenHolidaysAPI szolgáltatás áll mögötte (helyben számított koszovói naptárral), amely a nakordoni.eu ünnepnaptár oldalát és az előrejelző rendszer naptári tényezőit is táplálja.

• ?country=PL&year=2026 — egy ország teljes évi ünneplistája
• ?upcoming=1&days=30 — a közelgő ünnepek egyszerű listája több országon átívelően
• Paraméterek nélkül — egy alap országcsoport indexe a soron következő ünneppel

Hozzáadtuk a currency terméket — EUR-alapú árfolyamok PLN, CZK, HUF, USD, GBP, CHF, NOK és UAH devizákhoz, a Frankfurter (EKB) forrásból, 6 órán át gyorsítótárazva. Paraméterek nélkül, mindig a teljes árfolyamtáblát adja vissza. Lásd a dokumentációt.

Ágyazza be az élő európai kamionközlekedési tilalmakat a saját webhelyére — ingyenes iframe widget 3 dizájnnal (light, dark, board), 5 nyelven (en, uk, pl, de, ru), opcionális országonkénti szűrővel és élő «most aktív» státusszal. Nincs szükség API-kulcsra. Állítsa be és másolja a kódot itt: nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Inkább nyers adatokat szeretne? A truck-bans API-termék és a nyilvános JSON-feed továbbra is elérhető.

Három bővítés, mind visszafelé kompatibilis — a v1 változatlan.

Végpontonkénti verziózás. Mostantól létezik egy /api/v2/ alap-URL. Végpontonként működik: csak azok a végpontok viselkednek másképp a v2 alatt, amelyek ténylegesen megváltoztak; minden más végpont átlátszóan a v1 válaszát adja vissza (így a /api/v2/data/queue = ugyanaz az adat, mint a v1-nél, csak "api_version":"v2" értékkel). A működő végpontokat nem kell migrálni.

A border v2 irányfüggő. Az útvonalban a sorrend a haladási irányt jelenti:

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)

Minden checkpoint kap egy direction {from,to} objektumot és egy stale logikai értéket is, a ?max_age_min=N pedig csak a nemrég frissített átkelőket adja vissza. (A v1 border a sorrendtől függetlenül továbbra is a határ mindkét oldalát visszaadja — változatlanul.)

Interaktív Sandbox. A bejelentkezett fejlesztők mostantól bármely végpontot kipróbálhatnak a böngészőből itt: Developers → Sandbox — válasszon egy végpontot, verziót és egy saját kulcsát, módosítsa a paramétereket, és nézze meg az élő választ. A Sandbox-tesztelésnek saját, külön napi kerete van (50 hívás/nap), és soha nem érinti az élő API-kvótáját.

A dokumentáció mostantól végpontonként van felosztva (Developers → API Docs), verzióválasztóval azoknál a végpontoknál, amelyeknek több verziója van.

Két új tényező épült be a várakozásiidő-képletbe a meglévő section_mode és időjárási korrekciók mellé:

• service_rate — a jelenleg feldolgozott mért autó/perc a checkpoint konfigurált alaprátájához viszonyítva. Multiplikatív, 0.5x-1.5x közé korlátozva.
• shift_change — a checkpoint saját helyi 08:00/20:00 határőr-váltásának hatása. Additív (perc), nem multiplikatív — csak a váltás körüli +/-60 percen belül alkalmazva, minimális mintaelőzményt igényel, +/-120 percre korlátozva.

Az advanced_wait_min mostantól round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Mindkét tényező megjelenik a driver_reported.prognosed_advanced_wait_min mezőben is a korábbi összehasonlításokhoz.

Egy biztonsági/adatvédelmi felülvizsgálat keretében a következő mezőket eltávolítottuk — belső megvalósítási részleteket tártak fel (a forrásadatok taxonómiája, adatbázis-sorazonosítók, belső pipeline-annotációk, nem használt/holt mezők) valódi termékérték nélkül:

• id és corrected — eltávolítva a queue sorobjektumaiból
• source (nyers string, pl. "line") — eltávolítva a queue, multi és update-info végpontokból. Az update-info és a multi update_info blokkja továbbra is tartalmazza a source_category/source_label_en mezőket (egy kis nyilvános szótár); a queue és a multi queue blokkja már egyáltalán nem tartalmaz source mezőt
• traffic_status — eltávolítva a border végpontból; mindig null volt, és a rendszer egyetlen része sem töltötte fel soha

Ha az integrációja ezen mezők bármelyikét olvassa, kérjük, frissítse — az aktuális mezőlistát az adott termék dokumentációs oldalán találja.

A napi kvótafelhasználás (usage.used minden válaszban) mostantól tizedes érték is lehet (pl. 67.5) a korábbi mindig egész szám helyett. Ez annak a mellékhatása, hogy a queue-advanced tört ráta szerint kerül elszámolásra — lásd alább. A usage.limit nem érintett, és mindig egész szám. Ha a kliense szigorúan egész számként típusozza a usage.used mezőt, kérjük, bővítse ki, hogy tizedes/lebegőpontos értéket is elfogadjon.

Ez a három termék mostantól ugyanazokat az élő állapotmezőket adja vissza, amelyeket a webhely is mutat: wait_status (green/yellow/red, e checkpoint saját közelmúltbeli előzményei alapján), valamint trend_percent/trend_direction (up/up-slight/down/down-slight/stable, az elmúlt 3 óra összehasonlításával). Tisztán additív.

A /api/v1/data/queue data[] sorainál korábban a legtöbb forrásnál wait_time: null szerepelt — csak néhány forrásfeed jelent várakozási időt közvetlenül. Az ilyen érték nélküli sorok mostantól a szabványos becslést kapják, amelyet egy új wait_time_estimated logikai érték jelöl, így megkülönböztetheti a ténylegesen jelentett értéket a számítotttól.

A queue-advanced mostantól hívásonként 1.5 units értékbe kerül 1 helyett (tükrözve a plusz forgalmi/időjárási/sofőrjelentés-lekérdezéseket, amelyeket elvégez) — lásd a fenti usage.used mezőt. A válasz továbbá már nem tartalmazza a total_crossing_time mezőket, a driver_reported pedig mostantól csak {wait_min, ts, age_min} — a korábbi, előrejelzést a valósággal összehasonlító mezők (prognosed_wait_min, diff_min, historical_section_mode, historical_weather stb.) eltávolításra kerültek. A section_mode, weather, advanced_wait_min és exceeds_crossing_time változatlan.

A /api/v1/data/truck-bans mostantól minden országnál a bans_by_country alatt visszaad egy status értéket (active/clear), valamint az active_window, next_window, local_time és tz mezőket — az adott ország saját időzónájában számítva, így többé nem kell magának a nyers tilalmi időablakokat az órához mérnie. A válasz továbbá kiegészül egy legfelső szintű covered_countries listával és egy as_of UTC időbélyeggel.

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

Tisztán additív — a meglévő current_bans/upcoming_bans/bans_by_country mezők változatlanok. Egy ismeretlen ?country= mostantól üres eredményt ad vissza a countries_not_covered mezővel az összes ország tilalmai helyett.

Egy új, opcionális termék, amely a szabványos várakozási időt az élő forgalmi áramláshoz és az időjáráshoz igazítja. Minden korrekció teljes lebontását visszaadja.

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

Kérésre engedélyezve — nyisson egy Data ticketet az irányítópultjáról az aktiváláshoz.

A /api/v1/data/border mostantól helyesen számítja ki a wait_min értéket a válasz minden checkpointjához, összhangban a queue és multi termékekkel. Korábban ez a mező mindig null volt.

A /api/v1/data/forecast mostantól megbízhatóan a v4 ensemble modellt használja bármely prediction_steps értékhez (korábban néhány nem szabványos időtáv csendben egy régebbi modellre válthatott vissza). Az ensemble-t tápláló időjárási tényező is javítva lett, és mostantól valóban tükrözi az élő körülményeket (eső, hó, szél, köd) ahelyett, hogy mindig nem elérhetőt jelentene.

A jóváhagyott fejlesztők mostantól letölthetik az óránként átlagolt előzményi határsor-adatokat legfeljebb 5 checkpointra (legfeljebb 90 napos gördülő ablak) CSV vagy NDJSON formátumban az új Data export fülről. Csak közzétett és minőség-ellenőrzött adatok érhetők el; az időbélyegek UTC szerintiek. Hozzáférésre van szüksége? Nyisson egy Data ticketet.

Még nincs webhelye? Mostantól úgy is létrehozhat fejlesztői fiókot, hogy leírja, hol és hogyan tervezi használni az adatainkat, ahelyett, hogy egy élő oldal URL-jét kellene megadnia. A valódi URL-t később is hozzáadhatja az irányítópultjáról (Account & data → Az Ön projektje), amint a webhelye vagy alkalmazása élővé válik — a Feltételeink szerint az adott oldalon egy látható, nakordoni.eu-ra visszamutató link szükséges.

A fejlesztők mostantól beküldhetik saját, határral kapcsolatos híreiket a Nakordoni hírfolyamába. Ha szerkesztőink közzéteszik, indexelhető dofollow backlinket kap a szolgáltatásához (közzétevői szerzősor + forrássor), és ingyenesen lefordítjuk a cikket mind a 24 nyelvre.

Hetente egy cikk ingyenes; a további cikkek fizetős kiegészítők. Válassza a 'enyhén szerkeszthetjük + belső linkeket adhatunk hozzá' vagy a 'változatlanul közzétesszük' lehetőséget. Beküldés és az ellenőrzési állapot követése itt: Developers → Submit news.

A Multi-Checkpoint API (/api/v1/data/multi) mostantól ⌈(N PPIDs × sub-products) / 2⌉ szerint számolja a kvótát — az egyenértékű egyedi hívások költségének fele. Egy 10 checkpointra vonatkozó, mindkét sub-productot tartalmazó kérés mostantól 20 helyett 10 units. A válaszban az X-Devapi-Units fejléc és a meta.units_consumed a kedvezményes összeget tükrözi.

Kérje le az élő queue-állapotot és az adatfrissességet legfeljebb 20 checkpointra egyetlen API-hívásban — az irányítópult-fejlesztők számára tervezve, akik jelenleg sok PPID-t kérdeznek le ciklusban.

A kvóta méltányosan az igényelt N PPIDs × sub-products szerint számolódik, így a teljes felhasználás megegyezik az egyedi hívásokéval — de sok helyett egyetlen körüljárással. A GreenTravel-jellegű minták 24+ hívás/óra helyett 2-re csökkennek.

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

• include=queue — aktuális queue_now, becsült wait_min, adatkor és checkpoint-név
• include=update-info — adatfrissesség, forrásbesorolás, kor másodpercben/percben
• Kérésenként legfeljebb 20 PPID; kombinálja mindkét sub-productot egyetlen hívásban a teljes irányítópult-adatért
• A válasz tartalmazza a meta.units_consumed mezőt, így pontosan követheti a kvótafelhasználást

A queue termék válasza mostantól tartalmaz egy legfelső szintű snapshot objektumot a legfrissebb valós idejű adatokkal és egy kiszámított, prognosztizált várakozási idővel — ugyanaz a képlet, mint a nakordoni.eu hero szekciójában:

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

A data tömb (előzményi bejegyzések) változatlan — ez tisztán additív kiegészítés. Azok a kliensek, amelyek nem olvassák a snapshot mezőt, nem érintettek.

Kérdezze le egy adott határ + járműtípus összes checkpointját egyetlen hívásban, ahelyett, hogy PPID-nként külön kérést indítana.

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

• Támogat egyetlen célországot, vesszővel elválasztott listát, vagy az all értéket, amely egyszerre kiterjed minden figyelt szomszédra.
• Az eredmények a queue_now szerint növekvő sorrendben (legrövidebb sor elöl).
• Teljesen lokalizált: adja hozzá a ?lang=uk paramétert (vagy a 22 támogatott nyelv bármelyikét), hogy a checkpoint-neveket az adott nyelven kapja meg.

Fedezze fel a checkpointok PPID-értékeit név alapján a teljes könyvtár böngészése nélkül.

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

• Egyetlen nevet vagy vesszővel elválasztott listát fogad el (legfeljebb 20).
• Mind a 24 fordítási nyelven keres — adjon meg egy nevet ukránul, lengyelül, németül vagy bármely támogatott nyelven, és megtalálja.
• Visszaadja az adott helyszín összes PPID-jét járműtípus szerint csoportosítva (autó / busz / gyalogos / kamion).

Az alternatives termék mostantól mind a 22 támogatott nyelven elfogadja a ?lang= paramétert (korábban csak 12-t).

Az új crossing_type paraméterrel felülbírálhatja a járműtípus-szűrőt — pl. adja meg a crossing_type=4 értéket, hogy autós alternatívákat kapjon akkor is, ha busz PPID-ről kérdez le.

A crossing_type_label mező a checkpoints, border és search válaszaiban mostantól mind a 22 támogatott nyelven a kért nyelvre van fordítva. Az országnév-mezők (origin_name, destination_name) ugyanazt a nyelvi beállítást követik.

A Nakordoni Developer API portál elérhető itt: /en/developers. Regisztráljon egy ingyenes Explorer kulcsért (200 kérés/nap), hogy hozzáférjen a határsor-adatokhoz, előrejelzésekhez, üzemanyagárakhoz, sofőr-POI-khoz és még többhöz.

Az induláskor elérhető termékek: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.