API változásnapló

Új termék: lane-cost-index (GET /api/v2/data/lane-cost-index). Egy megrakott kamionos fuvar költségindexét adja A-ból B-be Európában: üzemanyag, útdíj, sofőridő és napidíj.

• Bemenet: from és to "lat,lng" formában vagy városazonosítóként, vehicle (például artic_40t), opcionálisan euro, co2_class és empty_return.
• Országonként: km, útdíj, gázolaj literben és üzemanyagköltség (ÁFA nélkül), valamint az útdíjhoz használt járműkategória.
• Sofőridő: a vezetés, a szünetek és a pihenők az EU 561/2006 szabályait követik. A sofőrköltség és a napidíj a kiindulási ország díjtételével számol. Spanyolország és Olaszország most kollektív szerződésekből származó sofőrdíjat és napidíjat kapott.
• Trend: trend megadja az aktuális és az előző két hónap költségindexét.
• Hiányos adatok: ha egy útvonalon lévő országra nincs útdíj- vagy üzemanyagadat, vagy a kiindulási országnak nincs sofőrdíja, incomplete értéke true, és az összeg alsó határ. missing_countries és missing_components mutatja, mi hiányzik.

Ez költségindex, nem fuvardíj: a jármű tőkeköltsége, a biztosítás, az általános költségek és a haszonkulcs nincs benne.

Kvóta: egy kérés a route osztály 1 egységének számít, ugyanúgy, mint a truck-route.

Dokumentáció: Lane Cost Index.

A toll-cost termék pontosabban számol Franciaországra, Spanyolországra és Olaszországra.

• Franciaország és Spanyolország: az útvonalon két díjfizető állomás közötti autópálya-szakaszt az autópálya-üzemeltető be- és kihajtási díja alapján számoljuk. Új tételtípusként jelenik meg: motorway_section, az üzemeltetővel vagy úttal, a két állomással, valamint toll_km és cost_eur értékkel. Az ország többi díjköteles km-e továbbra is a km-enkénti átlagot használja.
• Járműkategória: Franciaország: 3. kategória 2 tengelyhez és 4. kategória 3 vagy több tengelyhez. Spanyolország: Pesados 1 2 vagy 3 tengelyhez és Pesados 2 4 vagy több tengelyhez.
• Olaszország: a 2 és 3 tengelyes tehergépkocsiknak most saját km-díjuk van.
• Euro- és CO2-osztály: a francia, olasz és spanyol díjak nem függnek ezektől az osztályoktól. Ha euro vagy co2_class értéket küld, class_fallback értéke ezekben az országokban false, és class_note megadja az okát.
• Nincs fizetős út: egy spanyolországi útvonal fizetős út nélkül (például Zaragoza–Barcelona) Spanyolországot cost_eur 0 és scheme not_tolled értékkel adja vissza.

A többi ország nem változik. Dokumentáció: Truck Toll Cost.

Új termék: toll-cost (POST /api/v2/data/toll-cost, JSON törzs). Egy európai útvonal kamion útdíját adja vissza.

• Bemenet: az útvonal vonala coordinates formában (például a truck-route geometriája), vagy waypoints, amelyekre a saját kamionos útvonaltervezésünkkel számolunk útvonalat.
• Jármű: axles, gross_weight_t, euro és co2_class. Opcionálisan date a díjtételekhez és currency a végösszeghez.
• Országonként: díjköteles km, tényleges EUR/km díj, költség, a díjazott járműkategória és a díjtétel dátuma. Az adott Euro- és CO2-osztály díjtételeit használjuk, ahol arra az osztályra hivatalos díjtétel áll rendelkezésre. Egyébként az alapértelmezett osztály díjtételét használjuk, és a class_fallback értéke true.
• Külön tételek: koncessziós autópálya-szakaszok, valamint saját kamionos díjú alagutak és hidak (például Calafat-Vidin).

Kvóta: egy kérés a route osztály 1 egységének számít, ugyanúgy, mint a truck-route.

Dokumentáció: Truck Toll Cost.

Két új termék itt: /api/v2. Egy buszos utazásnál megmutatják, melyik oldalra süt a nap és melyik van árnyékban, és mely ülések a legjobbak árnyékhoz vagy kilátáshoz.

• bus-sun-side (/api/v2/data/bus-sun-side), GET: útvonal a buszútvonal-nyilvántartásunkból (route_id, dir, date) vagy szabad utazás (from, to, depart).
• bus-sun-side, POST: küldje el saját útvonalát megállók listájaként, GeoJSON vonalként vagy kódolt polyline-ként. Adjon meg buszparamétereket (sorok, ülésrend, ajtóoldal, ablakok, szint), vagy válasszon modellt a katalógusból ezzel: bus_model.
• Időjárás: a következő 3 nap utazásainál az útvonal menti óránkénti előrejelzést használjuk. A későbbi utazásokat derült égre számoljuk. Küldje el ezt: weather=0, ha mindig a derült égre számolt eredményt szeretné.
• Képek (POST): ülésrend, útvonaltérkép és idővonal URL-ként PNG, WebP vagy JPG formátumban. A képeket 12 óráig tároljuk. Kap egy embed_html kódot is az eredmény beágyazásához. A képek URL-jei ezzel kezdődnek: https://api.nakordoni.dev/images/.
• Animáció: a(z) animation blokk 5 percenként egy képkockát tartalmaz a busz helyzetével, haladási irányával, a nap azimutjával és magasságával és a napos oldallal, az Ön nyelvén megadott feliratokkal, oldalankénti összesítéssel és jelmagyarázattal. Küldje el ezt: animation=0, ha nincs rá szüksége.
• Widget: jelenítse meg az eredményt bármely weboldalon, WordPressben is, script taggel vagy iframe-mel. A widget nyilvános kulcsot használ, amely csak az Ön által engedélyezett originökön működik, és saját térképcsempéinket. Elérhető WordPress-bővítmény (zip).
• bus-sun-catalog (/api/v2/data/bus-sun-catalog): a bus-sun-side által elfogadott buszmodellek, ülésrenddel és ablakokkal.

Kvóta: a képeket kérő POST kérés 2 egységnek számít. Minden más kérés 1 egység.

Dokumentáció: Bus Sun Side.

A fleet-compliance-validate mostantól az (EU) 2020/1054 rendelettel módosított 561/2006/EK rendelet több rendelkezését is lefedi. A meglévő válaszmezők nem változnak; új mezők kerülnek hozzáadásra.

• 12. cikk szerinti kivétel: a vezetési tevékenységeket jelölje meg az art12_exceed: true értékkel. Kivételes esetekben a járművezető a napi és heti vezetési időkorlátot legfeljebb 1 órával túllépheti, hogy elérje a vállalkozás működési központját vagy a lakóhelyét a heti pihenőidő eltöltéséhez, illetve legfeljebb 2 órával egy 30 perces szünet után, ha ezt rendszeres heti pihenőidő követi. Az ellenőrző ezt elfogadja, és a járó kompenzációt, valamint annak határidejét (a harmadik rákövetkező hét vége) a remaining.driving.art12_compensation és az exceptions.art12 mezőben adja vissza.
• 8. cikk (8a) bekezdés, visszatérés a telephelyre: a heti pihenőidőknél küldje el a location mezőt (residence, operational_centre vagy elsewhere). Figyelmeztetést kap, ha 4 egymást követő héten nincs rendszeres heti pihenőidő otthon vagy a működési központban.
• 8. cikk (6a) bekezdés, 12 napos eltérés: passenger_12day: true egyetlen alkalmi nemzetközi autóbuszos szolgáltatásra. A heti pihenőidő ilyenkor a rendszeres heti pihenőidő után legfeljebb tizenkét 24 órás időszakkal következhet. Az azt követő pihenőidőket és az éjszakai vezetést (22:00-06:00) ellenőrzi a rendszer. Az AETR 8. cikk (6) bekezdés b) pontját ugyanígy alkalmazza.
• Nemzeti éjszakai időszakok (2002/15/EK irányelv 3. cikk h) pont): a nemzeti éjszakai időszak alkalmazásához használja a country vagy a wtd.country mezőt. Ellenőrzött: AT, IE (az utasszállítás külön) és SE. Más EU/EGT-országok a 00:00-04:00 időszakot használják, és night_window_verified: false értéket adnak vissza.
• fleet-compliance-limits: az AETR mostantól felsorolja a 2010 utáni, ellenőrzött módosításokat. Ezek csak a 14. cikket érintik, a vezetési és pihenőidő-szabályokat nem.

Dokumentáció: Fleet Compliance.

Négy új termék, amelyek az /api/v2 végpontról érhetők el, és saját ünnepnap-szabálymotorunk számítja őket 51 országra (Európa és az Öböl-térség: SA, AE, QA, KW, BH, OM), 2020-2035 között:

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — állami, banki, regionális, vallási ünnepnapok és emléknapok legfeljebb 10 országra egy évre vagy egy dátumtartományra. Minden ünnepnapnál megadjuk, hogy munkaszüneti nap-e, banki ünnep-e vagy iskolai szünetre esik-e, hogy a hétvégére eső ünnepet áthelyezték-e másik napra, hogy az iszlám naptár szerinti dátum még becsült-e, és hogy érvényes-e aznap teherautós behajtási tilalom (truck_ban). Szűrhető régió (region=DE-BY), típus, nyelv és név szerint; a school=1 hozzáadja az iskolai szüneteket.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — munkanapok számolása két dátum között, munkanapok hozzáadása vagy kivonása, dátum ellenőrzése, illetve a következő vagy előző munkanap keresése. Az adott ország hétvégéjét (szombat-vasárnap, az Öböl-térségben péntek-szombat és más hétvégék), az országos és regionális munkaszüneti napokat, valamint a rendeleti munkanap-áthelyezéseket veszi figyelembe.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — a lefedett országok hétvégi napokkal, időzónával, régiókkal és ünnepnap-típusokkal; a country= megadásával évenkénti munkanapokat és a következő öt ünnepnapot is visszaadja.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, Pro csomag és magasabb) — modellel becsült üzleti hatás: ünnepnaponként 0-100 közötti hatáspontszám, üzletbezárás valószínűsége, keresleti kategóriák, a hosszú hétvégén és áthidaló napon belüli pozíció, valamint keresletnövekedési időszakok. A holiday-calendar-holidays végponton a Pro és magasabb csomagok ezt a blokkot az include=impact paraméterrel kapják meg, és szűrhetnek a min_impact paraméterrel.

A meglévő holiday-calendar termék nem változik. Dokumentáció: Holiday Calendar.

Három új termék a vezetési idő megfelelőségének ellenőrzésére, az /api/v2 végpontról kiszolgálva:

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, JSON törzs) — a rögzített járművezetői tevékenységet ellenőrzi az EU 561/2006 vagy az AETR, valamint a Directive 2002/15/EC szerinti munkaidő alapján. Visszaadja az egyes szabálysértéseket a szabály cikkével és súlyossági kategóriájával, valamint azt, hogy a járművezetőnek mennyi van még hátra: napi vezetés, a gördülő heti 56 órás és kéthetes 90 órás korlát, a következő szünet, a napi és a heti pihenőidő. Lefedi a megosztott szüneteket, a csökkentett és meghosszabbított napokat, a csökkentett heti pihenőidő kompenzálását, az éjszakai munkát, a kettős személyzetet, valamint a komp vagy vonat által megszakított pihenőidőt.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — a szabályparaméterek az EU 561, az AETR (az 561-től való eltéréseivel) és a 2002/15 esetén, valamint a Regulation (EU) 2016/403 szerinti súlyossági kategóriák.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, JSON törzs) — a tervezett műszakokat ellenőrzi a kiküldés előtt az útvonal országaiban érvényes teherautós behajtási tilalmak, állami ünnepnapok és hétvégi napok alapján, továbbá az EU 561, az AETR és a 2002/15 szabályai szerint. Minden műszak megkapja a legkorábbi jogszerű kezdési időpontot.

Dokumentáció: Fleet Compliance.

A v3-tól a napi és heti pihenők megállói a következő mezőket kapják: in_vehicle_allowed, accommodation_required és rule (route-plan rest_rules=eu561 beállítással és truck-route). A (EU) 2020/1054 rendelet módosította az EU 561/2006 8. cikk (8) bekezdését: a rendszeres heti pihenőt és minden 45 óránál hosszabb heti pihenőt tilos a járműben tölteni. Ezeknél a megállóknál in_vehicle_allowed = false. A csökkentett heti pihenő (24 órától 45 óránál kevesebbig) és a napi pihenő álló, alvóhellyel felszerelt járműben is tölthető.

A heti pihenők megállói accommodation[] listát is kapnak — szobákkal rendelkező parkolókat a megálló közelében —, a megálló parkolója pedig has_accommodation mezőt. Ez csak tájékoztatás: a megálló, ideje és kamionparkolója nem változik. Ha nem ismert szobákkal rendelkező hely, a megálló warning = no_accommodation_found értéket kap. A v1 és v2 válaszok nem változnak.

A(z) /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local és /api/v2/data/fuel (mode=nearest) kúti árainak mostantól legfeljebb 90 nap a koruk. Azt az árat, amelyet utoljára több mint 90 napja erősítettünk meg, már nem adjuk vissza. Korábban az ilyen ár stale = true jelzéssel érkezett.

Mi változik a válaszokban: az az üzemanyagfajta, amelynek csak régebbi ára van, hiányzik a(z) prices mezőből; az ár nélkül maradt kút nem szerepel a listában, vagy üres prices objektumot kap ott, ahol ár nélküli kutak is megjelennek; a válasz pedig üres lehet ott, ahol korábban régi árakat tartalmazott. Az üres válasz a szokásos módon tartalmazza a(z) empty_reason mezőt. A(z) fuel-local ilyenkor régiós vagy országos szintről válaszolhat. A(z) stale jelző nem változik: értéke true, ha az árat utoljára több mint 7 napja erősítettük meg. Az ártörténetet megőrizzük. A(z) fuel-cities, fuel-cost, az országos átlagok és a(z) fuel-grades esetében nincs gyakorlati változás. Részletek: Az ár kora.

A GET /api/v2/data/route-plan a v2-ben bővített megállómodellt kap (csak kiegészítés: semmi nem törlődött vagy nevezték át), a v3-ban pedig új alapértékeket (/api/v3/data/route-plan).

v2, kiegészítés. stop_places=1 esetén minden megálló (szünet, étkezés, éjszakázás, heti pihenő) tartalmaz places[] mezőt: jelölt parkolók a megálló körüli vezetési időablakban, mindegyik a következő mezőkkel: name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 és type_rank. A keresést a places_before_min, places_after_min, places_radius_km és rest_radius_km paraméterekkel hangolhatja; a 25 km feletti sugár korlátozva van, és a radius_clamped figyelmeztetés jelzi. A rest_rules=legacy|eu561 választja ki a pihenőmodellt, eu561 esetén pedig megadhatja a sofőr állapotát: driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used és allow_reduced. Új megállótípusok: ban_wait (ban mezővel: name, country, from, until) és weekly_rest; a szünetet vagy pihenőt helyettesítő várakozást a counts_as jelöli. Az elektronikus sorral rendelkező, Ukrajnából kilépő teherautós átkelők kiegészülnek ezekkel: registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note és registration_url, valamint a figyelmeztetésekkel: echerha_registration és echerha_wait_unverified.

v3, új alapértékek. A rest_rules alapértéke eu561; a helynevek szigorúak (csak valódi parkolók és pihenőhelyek); az eCherha által közzétett várakozási idő (friss adat, korlátozás nélkül) lesz a határi várakozás, és a határi várakozás az esedékes szünetnek vagy pihenőnek számít. A v2 megtartja a régi pihenőmodellt és az eredeti helyszűrőt, így a meglévő integrációk nem változnak. Részletek: Route Planner API.

A GET /api/v3/data/truck-route mostantól az eCherha határi várakozási idejét használja. A v3-ban a border_crossings[] az Ukrajnából kilépő, elektronikus sorral rendelkező teherautósávoknál a wait_min értéket az eCherha által közzétett várakozási időből veszik (csak friss adat, korlátozás nélkül; elavult adatnál a wait_min értéke null, és a echerha_wait_unverified figyelmeztetés kerül be), és tartalmazzák ezeket: registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note és registration_url, a echerha_registration figyelmeztetéssel.

A pihenőterv a határi várakozást a határon töltött időnek tekinti: a hosszú sor az esedékes szünetnek, napi vagy heti pihenőnek számít (counts_as a waits[] sorban), ahelyett hogy ráadásként hozzáadódna. A v2 változatlan. Részletek: Truck Route API.

Ha a /api/v2/data/fuel-stations vagy a /api/v2/data/fuel-cheapest nem talál kutat, a válasz továbbra is HTTP 200 üres listával, de mostantól megmondja az okát. Kizárólag üres válasz esetén a data tartalmazza az empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type vagy no_fresh_price_in_radius), a nearest_station_km (a legközelebbi, az Ön típusát áruló kút, nearest_search_km = 50 km-ig keresve; null, ha nincs), a country és a suggestion mezőt — egyetlen rövid mondat az Ön lang nyelvén, például: Nincs kút 5 km-en belül — a legközelebbi 6,4 km-re van; próbálja a radius_km=10 értéket.

A kódját az empty_reason és a nearest_station_km alapján ágaztassa el. A suggestion embereknek szóló tanács, a megfogalmazása változhat. A sugarat soha nem növeljük meg Ön helyett. Ha egy területet vagy útvonalat rácson mintavételez, használjon 10–15 közötti radius_km értéket. A kutakat tartalmazó válaszok nem változtak. Részletek: Üres válaszok.

Keresési sugár. A /api/v2/data/fuel-stations végpont radius_km paramétere mostantól egy tizedesjegyet megőriz. Egy olyan sugarat, mint a 4.8, korábban értesítés nélkül 4-re vágtunk, így minden keresés akár harmadával kisebb területet fedett le a kértnél, és kevesebb kutat vagy egyet sem adhatott vissza. Az anchor.radius_km a ténylegesen alkalmazott sugarat mutatja; az egész számok a korábbiak szerint térnek vissza.

Márkanevek. Ugyanaz a márka mostantól mindig ugyanúgy szerepel a brand mezőben — például az ORLEN és az orlen Orlen néven, a CircleK pedig Circle K néven tér vissza. A kutak, árak, azonosítók és mezők nem változtak. Ha a márkákat pontos írásmód szerint párosítja (logókhoz vagy szűrőkhöz), kérjük, ellenőrizze a listáját az új nevekkel szemben.

A GET /api/v2/data/truck-route egy új, opcionális traffic paramétert fogad. Ez határozza meg, hogyan vesszük figyelembe a forgalmat az ETA-nál, a pihenőtervnél, a határátlépési érkezési időknél és a teherautós korlátozásoknál mért időpontoknál:

• forecast (alapértelmezett): visszatérő torlódás abban az órában, amikor a teherautó az egyes szakaszokon áthalad, az érkezésig csökkenő aktuális dugók, a nyomvonalon lévő útépítések és lezárások, valamint az időjárás, ahol van adatunk. A válasz egy traffic_forecast blokkot tartalmaz, a késéssel okok szerint bontva.
• live: csak az aktuális forgalom, visszatérő torlódás nélkül.
• off: nincs forgalmi korrekció; az idők a szabad forgalmú teherautós útvonaltervező idői. A traffic_forecast ilyenkor csak a model és a mode mezőt tartalmazza.

Bármely más érték 400 bad_request hibát ad a következő üzenettel: Invalid traffic: forecast, live or off. A paraméter nélküli kérések az alapértelmezett forecast értéket kapják.

Teherautós korlátozások az előre jelzett érkezési időpontban: forecast vagy live esetén a truck_bans[].active értékét mostantól arra az időpontra ítéljük meg, amikor a teherautó az előrejelzés szerint eléri az adott korlátozást (a depart_at időponttól, vagy ha nem küld ilyet, a mostanitól), az adott korlátozásnál esetleg szükséges várakozás előtt. Az új truck_bans[].active_at mező a megítélt időpontot adja meg a korlátozás országának helyi idejében. A bans_summary, a restriction_hits és a legal ugyanezeket az ítéleteket követi, és az a korlátozás, amelybe az előre jelzett késés újonnan beleütközik (például egy későbbi napon vagy másik országban), szintén szerepel a truck_bans listában. traffic=off esetén az active értékét a szabad forgalmú idővonalon ítéljük meg, az active_at pedig megegyezik az eta_at_ban értékével.

Új termék: Truck Route API (GET /api/v2/data/truck-route, csak v2). Egyetlen hívás teherautóra engedélyezett útvonalat ad vissza, mellette mindazzal, amire egy diszpécsernek szüksége van az út mentén. Az útvonalat ugyanaz az útvonaltervező mag számítja, mint a TruckTurn kamionos navigációs alkalmazásunkban, saját térképadatainkon.

• Jármű: height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (ADR-osztályok) és adr_tunnel (B–E). A teherautó-forgalmi tilalmakat és a korlátozott zónákat a visszaadott vonalon ellenőrizzük.
• Az útvonal mentén: benzinkutak aktuális árakkal, teherautó-parkolók és mérlegállomások, mindegyik km_from_start értékkel és kerülővel.
• Gépjárművezetői pihenőterv az 561/2006/EK rendelet alapján: szünetek (a megosztott 15+30 is), napi és heti pihenőidő (a csökkentett is), egy vezető vagy kétfős személyzet (crew=2), a vezető aktuális állapotából indulva, ha megadja. Minden megálló valós parkolóba kerül az útvonal mentén. Tervezési segédeszköz, nem tachográf-nyilvántartás.
• ETA a pihenőkkel, a teherautó-forgalmi tilalmakkal és a határi várakozással együtt. Tervezés depart_at vagy arrive_at alapján.
• Útdíjbecslés országonként (EUR, tengelyszám és károsanyag-kibocsátási osztály szerint); a díjtétel nélküli országokat a tolls.coverage_note sorolja fel. Emellett avoid (útdíjak, kompok, autópályák, határok, alagutak, burkolatlan utak, alacsony kibocsátású zónák), legfeljebb 2 alternatíva, országonkénti bontás, és geometry polyline5, polyline6 vagy GeoJSON formátumban.

Keret: külön teherautó-útvonal keret: fiókonként napi 10 hívás, fizetős csomagokban több, valamint a További teherautó-útvonal hívások kiegészítő. A sandboxban naponta 10 teherautó-útvonalat futtathat, az eredményt a teljes útvonaltervvel a térképen megtekintheti, és exportálhatja GPX, KML, GeoJSON, CSV, naptár (.ics) vagy ITN formátumban. Lásd a termékoldalt és a referenciát.

Az API Feltételei szerint a Market az az ország, amelynek adatait használja, és a kulcsa a fiókjához jóváhagyott országokra terjed ki. Eddig a koordináta alapú termékek (lat/lon — pl. Nearby Shops, Truck Parkings, Fuel Stations) Európa bármely pontjára választ adtak. 2026. október 13-tól, ezt a kérés kiszolgálásakor ellenőrizzük:

• Az a kérés, amelynek lat/lon koordinátája a fiókjához nem jóváhagyott országban van, 403 hibát ad vissza error.code market_not_allowed kóddal. Az üzenet megnevezi az országot és a jóváhagyott listáját.
• Ha a sugár átlépi a határt, az olyan találatok, amelyek country_code mezője a jóváhagyott országain kívül esik, eltávolításra kerülnek. A válasz ekkor tartalmazza a markets_filtered (hány elem lett eltávolítva) és markets_notice mezőt, a total_found pedig csak a megkapott találatokat számolja.

Ez azokra a fiókokra vonatkozik, amelyek országait ellenőrizték (approved vagy partial státusz). A kérésben semmi sem változik — nincs új paraméter, nincs új verzió. Ha az alkalmazásának másik országra van szüksége, adja hozzá a fejlesztői portálon október 13. előtt. A market_not_allowed a többi hibakóddal együtt szerepel a referenciában.

A Nakordoni Partners fiókhoz ugyanazzal az e-mail-címmel kapcsolt fejlesztői fiókok mostantól híreket küldhetnek be és kezelhetik NakBus flottájukat (NakDriver / NakManager) a partners.nakordoni.eu oldalon, csapatszerepekkel (Owner, Manager, Viewer) és egykattintásos bejelentkezéssel a két portál között. A fejlesztői portál oldalai, az API-kulcsok, a flottavégpontok és az alkalmazások változatlanok maradnak.

A Fuel Prices esetében az updated_at és a válasz saját age_hours/stale jelzője eltérő órák szerint járt: az updated_at csak akkor változik, ha az ár ténylegesen megváltozik, az elavultságot viszont úgy számoltuk, mintha minden megerősítéskor változna. Az árindex 46.7%-ánál age_hours ≤48 és stale:false szerepelt, miközben az updated_at valójában több mint 48 órás volt, 12,620 állomásnál pedig egy hétnél is régebbi. Mostantól minden ár tartalmazza a confirmed_at mezőt is — az ár utolsó megerősítésének időpontját, órára lefelé kerekítve, és soha nem korábbit, mint az updated_at —, az age_hours/stale pedig ebből számolódik. Az updated_at jelentése nem változott: akkor használja, ha tudni szeretné, mikor mozdult utoljára az ár, a confirmed_at-t pedig akkor, ha azt, mennyire friss most. A befagyasztott v1 szerződésben nem szerepel.

Két nyelvi hiba, mindkettő csendes: ha a kanonikus üzemanyagtípus-kódot lang=pl értékkel (vagy az oldal bármely másik 24 nyelvével) küldte, a fuel_type_local a kéréstől függetlenül angolul érkezett vissza — a címketáblával csak 10 nyelvet ellenőriztek, így minden, ami kívül esett ezen a listán, a kért nyelv helyett az alapértelmezett felületi szókincsre esett vissza. Külön, a lang=tr (vagy több más érvényes kód) az állomáslistákat ukránul adta vissza, mert egy belső uk alapértelmezés lépett életbe, valahányszor a kért nyelv nem szerepelt ugyanebben a 10 nyelvet tartalmazó listában. Mindkettő javítva: a megadott nyelv az, amelyet kap, mind a 25 nyelven.

Továbbá: a brand a Nearby Fuel Stations esetében a ~330 állomásnál, amelynek márkáját nem ismerjük, már nem a nyers betöltési jelzőértéket (OTHER) adja vissza, hanem null értéket — összhangban a válasz minden más ismeretlen mezőjével.

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   — prognosed wait time (minutes)
snapshot.updated_at — when the queue data was recorded
snapshot.age_min    — minutes since last update
snapshot.source     — data source identifier

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.