Historiku i ndryshimeve të API

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.

Border AI Assistant (/api/v1/data/assistant) kthente 503 internal_error — „Assistant temporarily unavailable“ — kur i njëjti çelës bënte të njëjtën pyetje dy herë brenda pesë minutash. Në fakt asgjë nuk ishte e padisponueshme: në shumicën e atyre rasteve përgjigjja ishte tashmë e llogaritur dhe gati për t'u kthyer. Tani ajo kthehet normalisht, me ok: true dhe HTTP 200.

Kur kërkesa e përsëritur mbërrin ndërsa përgjigjja e parë është ende duke u shkruar, thirrja tani kthen 429 me error.code të barabartë me duplicate_request në vend të një 503, kështu që një politikë ritentimi mund të dallojë „pyet sërish pas pak“ nga një ndërprerje e vërtetë. Të dyja rastet numëroheshin gjithashtu si gabime serveri në normën e gabimeve të llogarisë suaj; tani nuk numërohen më. Asgjë nuk ndryshon në kërkesë — asnjë parametër, asnjë version. duplicate_request është listuar bashkë me kodet e tjera të gabimit në dokumentacionin e referencës.

Truck Parking (/api/v2/data/truck-parkings) kthente hyrje me name të barabartë me null dhe address bosh — pranë Bensheim-it, 20 nga 50. Këto janë vende që i mbajmë vetëm si koordinatë, pa asgjë për t'u shfaqur dhe pa asgjë për t'u përputhur me grupin tuaj të POI-ve. Ato nuk janë më pjesë e këtij produkti: ai tani kthen vetëm vendndodhje me emër, aktualisht mbi 22.000 në të gjithë Evropën. Nëse i filtronit vetë hyrjet pa emër, ai kod tani është i tepërt, por i padëmshëm. Përgjigjet bëhen më të shkurtra për të njëjtin radius dhe limit, dhe çdo hyrje që kthehet është e përdorshme.

Veçmas, rreth 10.000 parkingje mbanin një çift koordinatash të papërpunuara si name, për shembull 51.927301,10.14112, ndërsa etiketa e vërtetë ndodhej te address. Tani ato mbajnë atë etiketë — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — kudo ku shfaqen, përfshirë /api/v1/data/pois. id i çdo vendi mbetet i pandryshuar, prandaj një hartëzim i ruajtur në cache mbetet i vlefshëm; ndryshon vetëm name.

snapshot.updated_at te /api/v1/data/queue dhe /api/v1/data/multi është kohë lokale në zonën e vetë pikës kufitare (për shembull Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), dhe deri tani asgjë në përgjigje nuk tregonte se cila ishte ajo zonë, kështu që thirrësi nuk mund ta kthente atë në një çast të saktë. snapshot merr një fushë shtesë timezone (emri IANA) përkrah updated_at. Asnjë parametër, asnjë version, asnjë ndryshim tjetër fushe.

Deri tani çdo endpoint karburanti e përshkruante mbulimin e vet me një listë të shkruar me dorë: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, ku Polonia ishte reduktuar në zonën e Trójmiasto-s. Të dyja pohimet kishin kohë që ishin vjetruar. Mbulimi tani matet nga indeksi i gjallë i stacioneve dhe rillogaritet çdo gjashtë orë: 39 vende kanë sot stacione me çmime, mes tyre Polonia në të gjithë vendin e jo në tre qytete. Në vetë kërkesën nuk ndryshon asgjë: as parametër, as version.

Nearby Fuel Stations dhe Cheapest Fuel: kur një kërkim kthehet bosh, blloku coverage tani mban vlerat e matura station_countries, station_counts, sparse_coverage dhe measured_at, të ngushtuara te cilësia e karburantit që kërkuat e jo te karburanti në përgjithësi. Një vend hyn në sparse_coverage kur atje kemi 25 stacione me çmim ose më pak — kjo është numërim, jo gjykim.

Ka një shënim të ri për një cilësi që e njohim, por që askush nuk e kuoton aty ku pyetët. Deri tani coverage.fuel_type_note shfaqej vetëm kur vetë emri i pompës na ishte i panjohur. Tani shfaqet edhe kur emri njihet saktë, por në atë vend thjesht nuk ka çmim për të; ai emërton vendet ku ajo cilësi kuotohet dhe cilësitë që kuotojmë rreth jush. Emri çek Natural 100 është shembulli i pastër: njihet, por asnjë burim nuk i jep çmim në Çeki. Një përgjigje bosh nuk duket më si kërkesë e prishur.

Fuel Grades (/api/v2/data/fuel-grades) fiton priced_countries dhe priced_station_counts për çdo cilësi, plus priced_here kur dërgoni ?country=. Dy listat kanë kuptime të ndryshme: një vend te countries është ai ku e pranojmë atë emër pompe, ndërsa priced_countries tregon ku e kuoton vërtet një burim, prandaj priced_here i barabartë me 0 është përgjigje e vërtetë dhe jo zbrazëti në përgjigje. Përgjigjja mban edhe coverage_measured_at dhe coverage_note, ndërsa Cache-Control bie nga 24 orë në 6, për t'iu përshtatur shpeshtësisë së rillogaritjes.

Njihen edhe më shumë emra vendorë pompash, mes tyre Klimadiesel 90 (HVO100) dhe HVO Diesel, Erdgas dhe Metano, Autogas dhe Autogaz, DEF për AdBlue, si dhe një varg emrash tregtarë naftash dhe benzinash premium. Radha e njohjes nuk ka ndryshuar dhe përputhja mbetet e saktë, ndaj asnjë emër që funksiononte më parë nuk do të thotë sot diçka tjetër, kurse një emër i ri mund të kthejë së shumti një përgjigje bosh në një përgjigje me çmime. Në të njëjtën kohë, dokumentacioni referues dhe përshkrimet e endpointeve u korrigjuan në të 25 gjuhët e faqes.

Cheapest Fuel (/api/v2/data/fuel-cheapest) kthente stacionet më të afërta sipas radhës së distancës në vend të atyre më të lira. Meqenëse renditja aplikohej para se rezultati të pritej sipas limit-it tuaj, stacionet më të lira brenda rrezes suaj mund të mungonin plotësisht nga përgjigja. Renditja tani është e saktë: më e lira e para për llojin e karburantit që kërkuat, në rast barazimi fiton stacioni më i afërt, dhe një stacion pa çmim për atë lloj karburanti renditet i fundit. Asgjë në kërkesë nuk ndryshon — asnjë parametër, asnjë version.

Përgjigjet e karburantit v2 dokumentohen gjithashtu ashtu siç shërbehen në të vërtetë: stacionet vijnë nën data.stations[], një rresht për çdo stacion fizik, me çdo lloj karburanti të vendosur brenda objektit prices (price, currency, local_name, updated_at, age_hours, stale) plus station_ref, grades, total_found dhe notices. Dokumentacioni referues për Nearby Fuel Stations dhe Cheapest Fuel ende përshkruante listën e vjetër të sheshtë të rreshtave data.data[].

Në faqen e faturimit (skeda mujore) janë të disponueshme dy shtesa mbi çdo plan, pa e ndryshuar atë: Thirrje shtesë parashikimesh — +100 thirrje parashikimesh dhe statistikash në ditë për çdo bllok, €2 në muaj për bllok, deri në 10 blloqe; dhe Vende shtesë — +1 vend i deklarueshëm për njësi, €2 në muaj secili. Ndryshimi i sasisë shfaq një ofertë të saktë proporcionale përpara se të tarifohet çfarëdo.

Nga 10 nëntori 2026 çdo plan përfshin një numër të caktuar vendesh të deklaruara: Explorer dhe Student 4, Starter 10, Pro e lart pa kufi. Nga ajo datë nuk do të mund të ruhet një deklarim më i gjatë se plani plus vendet shtesë të blera; skeda Llogaria e tregon tashmë kuotën tuaj, ndërsa llogaritë që e kalojnë atë shohin një sugjerim në panel. Përpara 10 nëntorit nuk ndryshon asgjë.

Sandbox-i i API-t tani e etiketon çdo endpoint në listë me klasën e tij të kuotës (I rëndë / Standard), tregon koston e kuotës për versionin e zgjedhur përpara se të ekzekutoni ndonjë gjë dhe, pas një thirrjeje, tregon sa do të kishte kushtuar e njëjta thirrje nga kuota juaj reale — përfshirë formulën ceil(N ppids × M sub-products / 2) të përdorur për thirrjet e formës /multi.

Kjo është një pamje vetëm për lexim: vetë thirrjet e sandbox-it zbriten nga buxheti juaj i veçantë i testimit, kurrë nga kuota juaj reale.

Nga sot, çdo gjë që kemi njoftuar publikisht se do të hiqet nga përdorimi është e mbyllur për llogaritë e zhvilluesve të krijuara në datën e njoftimit ose më pas. Nëse llogaria juaj ekzistonte para njoftimit, nuk ndryshon asgjë — ju ruani periudhën e plotë të tolerancës, deri në datën e heqjes të dhënë në hyrjen që e njoftoi atë.

Pse ekziston ky rregull. Më 24 gusht 2026 njoftuam se truck-bans v1 hiqet nga përdorimi më 8 shtator 2026. Dy llogari u regjistruan pak ditë pas atij njoftimi, e ndërtuan integrimin e tyre mbi v1 dhe erdhën brenda pak orësh nga një 410 pa u mbërritur asnjë email yni: si njoftimi, ashtu edhe grupi i njoftimeve me email ishin nisur para regjistrimit të tyre. Asgjë në API nuk i ndaloi të merrnin një version për të cilin kishim thënë tashmë se po hiqej. Ky ishte faji ynë, dhe ky është rregullimi — nuk mund të filloni të përdorni diçka që tashmë është planifikuar të hiqet.

Si duket. Një thirrje e tillë refuzohet me 410 Gone dhe kodin e gabimit version_closed_to_new_accounts. Mesazhi jep datën e heqjes, datën e njoftimit dhe versionin që duhet përdorur në vend të tij. Është qëllimisht një kod i ndryshëm nga version_sunset, i cili u kthehet të gjitha llogarive pasi ka kaluar vetë data e heqjes — mbështetja mund ta dallojë «erdhët shumë vonë për të filluar» nga «kjo është hequr për të gjithë» pa lexuar asnjë regjistër.

Ruajtja e të drejtave llogaritet sipas datës së krijimit të llogarisë, jo sipas thirrjes së parë. Nëse jeni regjistruar para njoftimit, por e filloni integrimin vetëm tani, prapëseprapë përfitoni periudhën e plotë të tolerancës: mund të keni qenë duke ndërtuar mbi të që nga fillimi.

Në fuqi tani për truck-bans v1 (njoftuar më 24 gusht 2026, hiqet më 8 shtator 2026), dhe automatikisht për çdo heqje që njoftojmë nga tani e tutje. Nuk kërkohet asgjë e re nga ju: çdo përgjigje në një version që po hiqet mbart tashmë kokat Deprecation, Sunset dhe Link: rel="successor-version", kështu që një integrim i ri mund ta shohë heqjen që po vjen pa e lexuar këtë faqe.

Vazhdim i ndryshimit të djeshëm në v4 (bileta e zhvilluesve #105). Listat destination të ndara me presje në v1 dhe v2 vazhdojnë të funksionojnë, por tani i nënshtrohen të njëjtit afat si destination=all: të dyja ndalen më 2026-10-06 (deri atëherë kokat Deprecation/Sunset, më pas 400 destination_list_removed, që tregon /api/v4/ si zëvendësim). Kontrolli ekzistues i kufirit prej 10 elementesh për listat me presje mbetet i pandryshuar përpara asaj date.

v4 mbetet me një destinacion për thirrje — kjo nuk ndryshoi sot. Ndryshoi vetëm mënyra si komunikohen v1/v2: gabimi 400 për destination=all nuk sugjeron më një listë me presje si rrugë migrimi (do të shuhej po atë datë), por drejton menjëherë te v4.

Korrigjim në dokumentacion: shembulli i v4 në këtë faqe më parë ishte /api/v4/data/border/1/2,3,4/9 — një listë me presje, të cilën v4 e refuzon. Tani është /api/v4/data/border/1/2/9. Kushdo që kopjoi shembullin e vjetër do të merrte një 400 që në thirrjen e parë; na vjen keq.

Çelës i ri i përkthyer product_border_v4_p_destination del në të 25 gjuhët e faqes dhe e thotë shprehimisht rregullin e një destinacioni në v4, në vend që të mbështetet te formulimi i v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} është aktiv që sot. Tri gjëra ndryshojnë krahasuar me v2, dhe së bashku ato janë arsyeja pse ky është version i ri e jo thjesht një redaktim.

1. Nuk ka më destination=all. Të dhënat tona licencohen sipas vendit (Kushtet e Developer API, seksioni 7), dhe një shprehje e përgjithshme që zgjerohet në "çdo fqinj për të cilin mbajmë të dhëna" kthen vende për të cilat llogaria jote mund të mos jetë e miratuar, pa asgjë në kërkesë që ta tregojë këtë. Në v4 vendin e emërton ti.

2. Një vend destinacioni për çdo kërkesë. /api/v4/data/border/1/2/9 kërkon një kufi të vetëm. Listat me presje nuk pranohen: dërgo 1/2/9, 1/3/9 dhe 1/4/9 si kërkesa të veçanta. Një listë me presje ose all përgjigjet me 400 dhe emërton kërkesat e sakta që duhen dërguar, kështu që asgjë nuk dështon në heshtje.

3. Një kod i vetëm për kamionët. v1 dhe v2 e ndanin transportin e mallrave në 8 (Transport mallrash) dhe 9 (Transport mallrash deri në 7.5 t). Kjo ndarje ekziston vërtet në pikën e kalimit, por asnjë integrues nuk mund të veprojë mbi të: kërkesa te v2 për 9 në kufirin UA-PL kthente 21 nga 70 pikat e kalimit për kamionë dhe asgjë nuk e thoshte këtë. v4 i përgjigjet 9 me të gjitha korsitë e kamionëve, dhe e pranon 8 si alias të 9. Çdo rresht mban crossing_type e vet, kështu që një përgjigje e bashkuar mbetet e verifikueshme.

Në v1 dhe v2, destination=all vazhdon të funksionojë deri më 2026-10-06 dhe deri atëherë mban kokat Deprecation / Sunset. Nga ajo datë këto versione përgjigjen me 400 edhe për all, ndërsa pjesa tjetër e v1 dhe v2 mbetet e paprekur dhe e disponueshme. E njëjta datë vlen edhe për shkurtoret e tjera që mbulojnë të gjitha vendet: travel-matrix pa ?dest=, bus-carriers me ?ppid=all, dhe fuel-grades pa ?country=.

v3, i njoftuar më herët sot, zëvendësohet nga v4. v3 ndryshonte nga v4 vetëm sepse ende pranonte një listë me presje, dhe asnjë integrim nuk e përdor atë formë. URL-të e v3 vazhdojnë të përgjigjen, kështu që asgjë e shkruar mbi to nuk prishet, por v3 nuk dokumentohet dhe nuk do të zhvillohet më tej: migro te v4.

Gjithçka tjetër në v4 është si në v2: rendi drejtimor i shtegut, direction{from,to}, stale, dhe ?max_age_min=.

Identifikuesit numerikë në /border/{origin}/{destination}/{crossing_type} nuk ishin publikuar kurrë si tabelë, ndaj integruesit i rindërtonin nga zonat kohore dhe nga URL-të shembull. Tani ata janë në dokumentacion te Kodet e vendeve dhe të llojeve të mjeteve, të gjeneruara nga të njëjtat tabela ndaj të cilave API-ja bën validimin: identifikuesit e vendeve me kufijtë në të cilët zgjerohet secili, dhe çdo crossing_type me etiketën që kthen API-ja.

Gjatë publikimit të tyre gjetëm se sandbox-i dhe metadata e endpoint-it e përshkruanin 8 si "truck<7.5t" dhe 9 si "truck". Kjo është e përmbysur: API-ja e etiketon 8 Transport mallrash dhe 9 Transport mallrash deri në 7.5 tonë, dhe gjithmonë ka qenë kështu. Nëse e ke zgjedhur kodin e kamionit nga sugjerimi i parametrit, po filtroje korsinë e kundërt nga ajo që kishe në mendje. Është korrigjuar kudo, dhe v3 e heq krejtësisht këtë zgjedhje.

Kushtet e API v1.1 zëvendësojnë v1.0 përpara se ai të hynte në fuqi, dhe zbatohen nga 2026-10-06. Të lutemi pranoji në panelin tënd.

Seksioni 7 tani thotë se çfarë është një Treg: vendi të dhënat e të cilit përdor, aty ku ndodhet pika e kalimit ose kufiri që kërkon, jo vendi ku jetojnë përdoruesit e tu. Paneli ynë i kishte thënë të dyja gjërat në vende të ndryshme; zbatimi ka nënkuptuar gjithmonë të parën.

Dy ndryshime në favorin tënd. Vendet e miratuara tashmë për llogarinë tënde mbeten të përdorshme ndërsa një ndryshim i mëvonshëm është në shqyrtim (shtimi i një vendi nuk i pezullon më ato që ke). Dhe nëse nuk i jemi përgjigjur një deklarimi tregu brenda 5 ditëve pune, kufijtë e plotë të planit tënd zbatohen derisa ta bëjmë.

Seksioni 10.3 tani përputhet me atë që paneli kërkon në të vërtetë, dhe seksioni 13.2 përcakton një bazë disponueshmërie që ne e masim dhe mund ta tregojmë.

Tre produkte tani mbajnë një fushë shtesë data_quality (high ose low) që tregon nëse një lexim është vëzhgim real apo vlerësim i modeluar pa burim numërimi të drejtpërdrejtë në atë pikë kalimi: queue (te snapshot i nivelit të parë dhe te çdo rresht historik në data[], mungon te rreshtat e parashikimit), update-info (te zarfi), dhe multi (te të dy nën-objektet queue dhe update_info për çdo pikë kalimi). Ky nuk është sinjal i ri, flamuri bazë ekzistonte tashmë brenda sistemit, por nuk ishte ekspozuar kurrë, kështu që një pikë kalimi plotësisht e modeluar dukej identike me një të matur drejtpërdrejt. is_realtime është lënë qëllimisht i pandryshuar: ai vazhdon të lexohet true për rreshtat e modeluar, dhe ndryshimi i atij kuptimi është një ndryshim thyes i nivelit v2 që nuk po e bëjmë këtu.

Gjithashtu nga ky lëshim: produkti queue-advanced nuk rishpërndan më të dhëna moti të papërpunuara nga burimi. weather_main, temperature dhe wind_speed zëvendësohen nga një condition_code i derivuar (shkallë rreziku 0–5, null kur nuk ka të dhëna moti), condition dhe severity.

Nga 2026-08-30 një kërkesë /api/v1/data/multi merr përgjigje për maksimumi 5 pika kalimi kufitar. Një thirrje që liston më shumë PPID nuk refuzohet: ajo vazhdon të kthejë 200, por përgjigjen e marrin vetëm 5 ID-të e para në ?ppids=. ID-të e mbetura shpërfillen, kthehen në meta.ppid_cap.ignored dhe nuk zbriten nga kuota juaj — thirrja faturohet sipas asaj që kthen në të vërtetë.

Përderisa një thirrje e kalon kufirin, përgjigjja përmban kokën X-Devapi-Warning: multi_ppid_cap dhe një bllok meta.ppid_cap me fushat cap, enforced_from, enforced, ppids_asked, ppids_answered dhe ignored[]. Deri më 2026-08-30 këto fusha shfaqen me enforced: false dhe me grupin e plotë të rezultateve, që ndryshimin që po vjen ta shihni në regjistrat tuaj.

Zbritja e kuotës në gjysmë mbetet e pandryshuar. Ndajini pikat tuaja të kalimit në grupe nga 5 dhe dërgoni një thirrje për çdo grup në ciklin tuaj të zakonshëm të rifreskimit; për kontroll të shpeshtë vetëm të gjatësisë së radhës dhe freskisë së të dhënave, update-info mbetet produkti më i lirë i klasës standarde.

Ndalimi i llogaritur ukrainas për vapën — kthehet me include_ua_heat dhe automatikisht për country=UA — tani përgjigjet për intervalin e datave që kërkoni. Më parë kthente shtatë ditët e ardhshme pavarësisht se çfarë thoshin date_from dhe date_to, prandaj një interval në dhjetor kthente në heshtje rreshtat e kësaj jave. Ndalimi llogaritet nga parashikimi i motit dhe nuk lexohet nga kalendari i ndalimeve, ndaj ka dy kufij që kalendari nuk i ka: nuk shikon prapa dhe përfundon aty ku përfundon parashikimi. Intervali juaj tani kryqëzohet me atë që parashikimi mbulon vërtet, dhe fusha e re ua_heat_ban.forecast_horizon tregon datën e fundit të arritshme. Një interval përtej atij horizonti nuk kthen asnjë rresht dhe e shpjegon arsyen te summary — që nuk është e njëjta gjë me «asnjë ndalim». Përgjigjet v1 mbeten të pandryshuara.

Forma e përgjigjes nuk ishte e dokumentuar askund: e vetmja mënyrë për të mësuar çfarë kthente një produkt ishte ta thirrje. Tani faqja e çdo produkti shfaq, poshtë tabelës së parametrave, një tabelë Fushat e përgjigjes me një përshkrim të shkurtër të secilës fushë; fushat e elementeve të një liste shfaqen si items[].name, ndërsa fushat në nivelin e zarfit (usage, meta, snapshot, resolved_location) shfaqen pa parashtesë. Janë dokumentuar 40 nga 42 produkte: dy që nuk janë nisur ende (weather, road-quality) mbeten qëllimisht pa përshkrim. E njëjta tabelë publikohet edhe në pasqyrën tonë publike të dokumentacionit në GitHub.

Çdo produkt karburanti tani pranon emrin vendas të një karburanti, jo vetëm shkrimin tonë të brendshëm: ON në Poloni, Nafta në Çeki, Gázolaj në Hungari, Motorină në Rumani, ДП në Ukrainë, Motorin në Turqi, Gasóleo në Portugali dhe Spanjë. Emri interpretohet së pari sipas vendit — „95“ është E10 në një pompë daneze dhe E5 në një polake — prandaj dërgoni country bashkë me emrin vendas, ose koordinata me të cilat mund ta vendosim pikën. Përgjigja kthen fuel_type (kanonik), fuel_type_requested (ashtu siç e shkruat) dhe fuel_type_local. Një emër që nuk arrijmë ta vendosim nuk zëvendësohet kurrë me një karburant të parazgjedhur: përgjigja kthehet bosh dhe e thotë këtë.

I gjithë tabeli tani është produkt më vete — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — karburantet tona kanonike dhe emrat e tyre vendas në 41 vende evropiane, përfshirë tregje për të cilat nuk japim çmime. Përveç kësaj, nivelet e vendit dhe të rajonit te fuel dhe fuel-local morën një objekt grades që lidh çdo çelës çmimi me karburantin dhe me emrin e tij në pompë.

Produkti truck-bans tani përgjigjet për një datë të caktuar ose një interval datash në /api/v2/data/truck-bans. Deri tani ai kthente gjithmonë 7 ditët e ardhshme dhe shpërfillte çdo datë të dërguar, prandaj ndërtimi i një kalendari kërkonte një kërkesë për çdo ditë — dhe në një plan me dy kërkesa në sekondë shumica e tyre refuzohen me 429 qps_exceeded.

Përdorni ?date=YYYY-MM-DD për një ditë të vetme, ose ?date_from= dhe ?date_to= për një interval. Të dy skajet përfshihen dhe secili mund të lihet jashtë: fillimi është si parazgjedhje sot, fundi është fillimi plus 7 ditë. Një dritare mund të mbulojë më së shumti 92 ditë — një më e gjatë refuzohet me 400 date_range_too_long në vend që të pritet në heshtje. Ky është një kalendar i drejtuar nga e ardhmja: një dritare mund të nisë më së shumti 7 ditë më parë, dhe datat më të vjetra refuzohen në vend që të shërbehen — mbulimi shtrihet përpara deri më 31 dhjetor 2028 në 23 vende.

Çdo përgjigje tani përmban një objekt window që emërton saktësisht intervalin e mbuluar. Është fushë shtesë dhe dërgohet edhe në v1, ku v1 e ruan të pandryshuar dritaren e saj fikse prej 7 ditësh. Vini re: include_ua_heat mbulon gjithmonë 7 ditët e ardhshme, cilëndo dritare që kërkoni — llogaritet nga një parashikim moti, jo nga kalendari i ndalimeve. Ju kujtojmë se v1 e këtij produkti tërhiqet më 8 shtator 2026.

Dy përmirësime të lidhura në të gjithë API-n: çdo parametër që një produkt nuk e pranon tani renditet te ignored_params në përgjigje, në vend që të hidhet poshtë në heshtje, dhe gabimet e vlerësimit nga shërbimi i të dhënave ju arrijnë ashtu siç janë shkruar, me kodin e lexueshëm nga makina te error.reason.

Tre përmirësime të cilësisë së përgjigjeve nga një auditim i gateway-t (bileta #43).

Kreu X-API-Key tani pranohet krahas Authorization: Bearer dhe ?key=. Nëse klienti juaj HTTP i dërgon çelësat përmes një kreu me emrin X-API-Key, kjo tani funksionon — më parë ai injorohej pa njoftim dhe thirrja refuzohej si missing_api_key. Authorization: Bearer mbetet forma e dokumentuar dhe e rekomanduar.

Mesazhi i gabimit për çelësin që mungon tani i emërton të tria mënyrat e autentikimit (kreu Bearer, kreu X-API-Key, ose ?key=) në vend që vetëm të lidhet me faqen e regjistrimit.

Direktoria checkpoints tani mban has_day_stats në çdo rresht — një vlerë logjike shtesë që tregon nëse API-ja Best Time to Cross (day-stats) ka të dhëna për atë pikëkalim. Day-stats ekziston vetëm për një nëngrup të pikëkalimeve të monitoruara; kontrolloni këtë flamur para se të bëni kërkesa, për të shmangur 404 të parashikueshme. Fushat ekzistuese nuk kanë ndryshuar.

U korrigjua gjithashtu në dokumentacion: produkti road-conditions e ka respektuar gjithmonë parametrin lang për lokalizimin e etiketave — thjesht nuk ishte i listuar.

Dy rregullime dhe një version i ri për produktin truck-bans.

Shtetet e ndara me presje tani funksionojnë. ?country= pranon një listë me deri në 3 kode ISO-2, për shembull ?country=DE,RO. Një listë më e gjatë refuzohet me 400 too_many_countries në vend që të shkurtohet pa njoftim — ky është një kalendar ndalimesh sipas shtetit, jo një burim masiv të dhënash. Kjo më parë nuk funksiononte: ndarësi hiqej, kështu që DE,RO lexohej si një token i vetëm DERO, nuk përputhej me asgjë dhe kthente success: true me total_bans: 0 — një “asnjë ndalim” i sigurt për dy shtete që së bashku kishin 22. Nëse e keni anashkaluar duke bërë një kërkesë për çdo shtet, tani një kërkesë e vetme i mbulon të gjitha dhe kushton një thirrje në vend të disave.

Përgjigjet tani raportojnë plotësinë e tyre. Tri fusha shtesë — returned, total_available dhe truncated — ju tregojnë nëse një përgjigje është kufizuar. Në veçanti, një thirrje pa fushëveprim kthen një pjesë të kufizuar, dhe deri tani asgjë në përmbajtje nuk e tregonte këtë. total_bans ruan kuptimin e tij ekzistues (rreshtat në këtë përgjigje), pra asgjë që tashmë analizoni nuk ndryshon.

v2 ka fushëveprim sipas shtetit. Në /api/v2/data/truck-bans, ?country= është i detyrueshëm dhe një kërkesë pa fushëveprim refuzohet me 400 scope_required — ky produkt është një kalendar ndalimesh sipas shtetit, jo një burim masiv të dhënash. v1 nuk ndryshon sot — ai ende pranon një thirrje pa fushëveprim dhe ende kthen të njëjtët 50 rreshta të kufizuar si gjithmonë, pra asgjë nga ajo që keni në punë nuk prishet tani. v1 i këtij produkti tërhiqet më 8 shtator 2026. Ai shërben normalisht deri më 7 shtator; nga 8 shtatori një kërkesë v1 refuzohet me 410 Gone dhe një mesazh që tregon drejt v2. Deri atëherë çdo përgjigje v1 mban Deprecation: true, një kokë Sunset me atë datë dhe një kokë Link që emërton versionin pasardhës, kështu që një bibliotekë klienti mund ta shfaqë afatin pa e lexuar askush këtë faqe. Për migrimin: ndryshoni segmentin e versionit në /api/v2/data/truck-bans dhe kaloni ?country=.

Një korrigjim në dokumentacion: parametri date është hequr. Ai ishte i listuar për një kohë të gjatë, por nuk lexohej kurrë nga shërbimi, prandaj çdo kërkesë që e dërgonte merrte pa njoftim dritaren e parazgjedhur 7-ditore në vend të ditës që kërkonte. Për të zgjedhur një ditë, filtroni vargun upcoming_bans sipas fushës së tij date. Një kod ISO-3 si DEU gjithashtu nuk shndërrohet më në emër shteti në përmbledhje, ku prodhonte të ngatërrueshmen “No truck ban data for: Germany.”

Produkti truck-bans tani kthen kufizime kombëtare të qarkullimit për pesë vende të tjera: Belgjikë (BE), Bjellorusi (BY), Mal të Zi (ME), Maqedoni të Veriut (MK) dhe Suedi (SE). Mbulimi ekzistues për Bullgarinë, Greqinë dhe Portugalinë është zgjeruar dhe rifreskuar — kufizimet greke tani shkojnë deri në shtator 2027, ndërsa Portugalia është sërish e populluar me të dhëna.

Struktura e përgjigjes nuk ka ndryshuar. Rreshtat e rinj mbajnë të njëjtat çelësa si çdo ndalim tjetër: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons dhe details_url. Kur një kufizim zbatohet vetëm nën një kusht — ndalimet verore bjelloruse, për shembull, zbatohen mbi 25 °C — ky kusht shënohet te restriction_details, ndaj lexoni këtë fushë para se të paralajmëroni një shofer. min_weight_tons është null kur një rregull ka të bëjë me një klasë transporti (mallra të rrezikshme) dhe jo me tonazhin.

Produktet fuel-stations dhe fuel-cheapest tani kthejnë çmime sipas stacionit në Poloni. Mbulimi është i pjesshëm — zona e Trequtetit (Gdansk, Gdinja, Sopot) — prandaj Polonia raportohet në një varg të ri shtesë coverage.sparse_coverage krahas listës ekzistuese coverage.station_countries. Një vend i listuar te sparse_coverage ka të dhëna stacionesh vetëm për një pjesë të territorit; një kërkesë diku tjetër në atë vend kthen një listë bosh së bashku me shënimin e mbulimit, njësoj si më parë. Çmimet polake jepen në PLN.

Edhe gabimi për kërkesat masive është më i qartë: kur mungon lat, mesazhi scope_required tani drejton te produkti fuel (?country=XX) për çmime mesatare në nivel vendi.

GET /api/v2/data/fuel-local?lat=&lon= tani e zgjidh çmimin në tre nivele në vend të dy: station, pastaj region, pastaj country. Niveli i ri i ndërmjetëm ekziston për Ukrainën, ku çmimet për pikë karburanti nuk ekzistojnë askund: një pikë në Ukrainë tani merr mesataren e rajonit të vet në vend të mesatares kombëtare dhe kthehet te mesatarja kombëtare vetëm kur rajoni nuk është i kuotuar.

Një përgjigje nga niveli region përmban kodin e rajonit (një vlerë ISO 3166-2 si UA-46), region_name dhe region_center_dist_km, si dhe të njëjtat fusha çmimesh si niveli i vendit. Vazhdoni ta degëzoni kodin sipas resolution, kurrë sipas formës së përgjigjes; përgjigjet station dhe country mbeten të pandryshuara.

Endpoint-i i ri GET /api/v2/data/fuel-local?lat=&lon= kthen çmimin më të mirë të disponueshëm të karburantit për çdo pikë në Evropë. Aty ku kemi të dhëna për secilën pikë karburanti përgjigjet me çmimet e pikave më të afërta, përndryshe me mesataren kombëtare të vendit ku ndodhet pika — përfshirë Ukrainën, ku çmimet për pikë karburanti nuk ekzistojnë askund.

Çdo përgjigje përmban fushën resolution, që tregon nivelin që u përgjigj: station (një listë pikash me distance_km, secila në monedhën e vet) ose country (një objekt me mesataret kombëtare). Degëzojeni kodin sipas resolution, kurrë sipas formës së përgjigjes. I disponueshëm nga /api/v2/ e tutje; fuel, fuel-stations dhe fuel-cheapest mbeten të pandryshuara.

Produktet fuel-stations dhe fuel-cheapest mbulojnë tani shumë më shumë pika karburanti në Gjermani, me çmime që rifreskohen gjatë gjithë ditës — përfshirë zonat rurale. Parametri fuel_type pranon 13 lloje karburanti: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 dhe lng. Kur asnjë pikë karburanti nuk përputhet me kërkesën, përgjigja përfshin një objekt coverage me listën e vendeve për të cilat ka të dhëna për pikat.

Parametri radius= pranohet tani si alias i pajtueshëm për radius_km në çdo produkt që e dokumenton. Produktet fuel-stations dhe fuel-cheapest kthejnë një objekt shtesë coverage (lista e vendeve me pika karburanti dhe një shënim) në vend të një rezultati bosh pa shpjegim kur asnjë pikë nuk përputhet. Objektet e pikave kufitare në route-plan tani përmbajnë çelësin shtesë wait_basis (car_lane kundrejt vehicle_lane), që klientët të dallojnë kur të dhënat e pritjes për kamionët vijnë në fakt nga korsia e makinave. Përputhja e pikave kufitare për kamionë përgjatë një rruge është dukshëm më e saktë: kthimi te korsia e makinave për çiftet e pikave pa të dhëna për korsinë e kamionëve, mbrojtje ndaj drejtimit të gabuar, një prag distance më i rreptë dhe heqja e kalimeve të dyfishta në të njëjtin pozicion. Të gjitha ndryshimet janë shtesë, pa ndryshime që prishin pajtueshmërinë.

Faqja hyrëse për zhvilluesit tani ka seksione të ankoruara (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) me navigim kërcimi, dhe çdo kartë produkti lidhet me faqen e vet të dokumentacionit. Seksioni i ri Mobile apps paraqet Kordon Online dhe Truck Bans me lidhje për Google Play. Plotësim përkthimesh: historiku i faturimit, gabimet e hyrjes, lidhjet sandbox dhe butoni i zgjedhjes së planit tani janë të lokalizuara në të gjitha 25 gjuhët.

Përgjigja e beacon-it të flotës (POST /api/v1/fleet_position.php) tani përfshin një varg messages që dorëzon mesazhet në pritje nga pronari te shoferi. Rrjedhë e re JSON live vetëm për pronarët (?ajax=live) dhe një kartë "Mesazhe për shoferët" në panelin e flotës. Faqe e re ftese për shoferët /{lang}/get-nakbus (25 gjuhë).

U lokalizuan titulli, përshkrimi (title, desc) i product_fleet_vehicles/live/history dhe parametrat fleet-history në të gjitha 25 gjuhët e portalit të zhvilluesve.

/api/v1/data/truck-bans tani kthen të njëjtin grup fushash të nivelit të lartë, pavarësisht se cila kërkesë e ka shkaktuar përgjigjen. Më parë, një kërkesë për një vend pa ndalime kalendarike, një ppid të parregjistruar, ose një përputhje normale në bazën e të dhënave mund të linte jashtë fusha të ndryshme (p.sh. country, covered_countries, ppid). Tani çdo përgjigje përfshin vazhdimisht 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 dhe upcoming_bans (null ose bosh kur nuk zbatohet), duke thjeshtuar analizimin në anën e klientit.

Nëntë produkte të reja për shërbim. Ato të bazuara në vendndodhje pranojnë lat/lon ose city + country (ne e gjeokodojmë qytetin për ju): /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 (stacione të renditura sipas çmimit për një lloj karburanti) dhe /api/v2/data/internet-points; rezultatet përmbajnë distance_km dhe kufizohen nga radius. /api/v2/data/vignettes përgjigjet nëse një vend kërkon vinjetë, me çmimet aktuale. Produkti ekzistues pois tani mbështet lon dhe radius siç dokumentohet, dhe modaliteti mode=nearest i produktit fuel gjithashtu pranon lon. Të nëntë janë të disponueshme në sandbox.

Çdo ndalim në /api/v1/data/truck-bans tani përfshin restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (fushëveprimin e saktë ose rrugët e prekura) dhe min_weight_tons. details_url tani çon te faqet për çdo vend në nakordoni.eu. Një parametër i ri opsional lang zgjedh gjuhën e emrave të vendeve dhe përmbledhjes; gjuha e parazgjedhur tani është anglishtja.

Një ?ppid= i gabuar tani kthen arsyen e vërtetë në vend të një "Request failed" të thatë: gabimi emërton parametrin, formatin e pritur id_<number> dhe drejton te /api/v1/data/checkpoints. Tabelat e parametrave për stats, forecast, update-info, weather dhe bus-carriers tani shfaqin shembullin id_13 në të 25 gjuhët.

Ndërfaqja e ridizajnuar e portalit (shirit i sipërm, shirit anësor me ikona, panel KPI, faqosje me karta) tani është përvoja e parazgjedhur për të gjitha llogaritë e zhvilluesve të kyçur — më herët se data e planifikuar e nisjes më 10 gusht. Përdorni ?v=1 për t'u kthyer në faqosjen klasike në çdo moment.

Të gjitha faqet e portalit të zhvilluesve — faqja hyrëse, dokumentacioni, paneli, AI Studio, mjedisi i provës, biletat, kërkesat, eksporti, flota, lajmet, regjistri i ndryshimeve dhe faqet e llogarisë — nuk ngarkojnë më asnjë skript ose hapësirë reklamash. Kjo vlen në të gjithë portalin, jo vetëm te hyrja dhe regjistrimi si më parë.

Planifikoni gjithë udhëtimin kufitar me një thirrje: /api/v2/data/route-plan kthen itinerarin, pikat kufitare që ndodhen vërtet mbi të me radhën e drejtpërdrejtë ose një parashikim për orën e mbërritjes suaj, dhe ndalesat që shoferi i bën vërtet — pushim, ushqim, karburant — në një vijë të vetme kohore.

Kufiri është pjesë e asaj vije. Një radhë e gjatë llogaritet si pushimi që tashmë duhej bërë dhe rivendos kohën në timon, ndaj tri orë pritje nuk paraqiten kurrë si tri orë plus një grup i plotë pushimesh që s'i bëri askush. Makinat ndjekin një model drejtimi të sigurt; autobusët dhe kamionët marrin pushimin e detyrueshëm sipas BE 561/2006, ndërsa koha e shërbimit të autobusëve është kalibruar mbi më shumë se 1000 orare ndërkombëtare të licencuara. Shtoni stop_places=1 që çdo ndalesë të marrë një zonë pushimi ose pikë karburanti reale, dhe via=lat,lon për të kaluar nga një pikë tjetër kufitare.

E re në menynë e portalit: Prezantimi — një prezantim i gjallë dhe gjithmonë i përditësuar i platformës së të dhënave nakordoni, i personalizuar për tregun tuaj (sigurime, udhëtime, logjistikë, transportues, media, navigim, karburant, fintech, sektor publik ose projekte personale). Ai tregon vëllime reale 30-ditore të platformës, përdorimin tuaj të API-t, statistika për kohën e përgjigjes dhe kufijtë, si dhe një rekomandim plani kur thirrjet tuaja arrijnë kufijtë e nivelit falas. Zgjidhni ose konfirmoni tregun (ose tregjet) tuaja në faqe, në profilin tuaj — ose gjatë regjistrimit. Hapet automatikisht në vizitën e parë; hapjen automatike mund ta çaktivizoni në vetë faqen.

Nëse një asistent ka një burim të aktivizuar por thirrja nuk sjell kontekstin që i duhet atij burimi — për shembull queue pa ppid—, burimi tani anashkalohet përpara çdo kërkese dhe nuk faturohet. Më parë thirrej gjithsesi, dështonte dhe prapëseprapë kushtonte një njësi. Studio tregon çfarë i duhet secilit burim, rillogarit çmimin ndërsa plotësoni kontekstin dhe i shënon rezultatet ✓ u ekzekutua / ⊘ u anashkalua, pa pagesë / ✕ dështoi; API-ja kthen data.feeds_skipped , që ju thotë saktësisht cilin parametër të kaloni.

Përgjigjet nuk përmendin më burime, origjina të dhënash apo asgjë teknike: një burim që mungon është së shumti një fjali e thjeshtë për përdoruesin fundor, kurrë një emër i brendshëm. Burimet me vetëm filtra opsionalë (si fuel i ngushtuar në një vend për të cilin nuk kemi të dhëna) tani kthehen te grupi i gjerë i të dhënave në vend që të mos kthejnë asgjë.

E re: /{lang}/developers/studio. Ndërtoni një asistent AI që përgjigjet nga përmbajtja juaj dhe të dhënat tona kufitare të drejtpërdrejta. Na jepni markdown-in tuaj ose thjesht tregoni faqet dhe ne i marrim e i indeksojmë — ju mirëmbani vetëm skedarët tuaj. Zgjidhni cilat prej burimeve tona mund të përdorë (radha, parashikimi, alternativat, statistikat ditore, karburanti, ndalimet për kamionë, të dielat tregtare, festat, gjendja e rrugëve, transportuesit me autobus, POI, valuta), zgjidhni një nivel modeli (i shpejtë / i baraspeshuar / pro — pikërisht ai e cakton çmimin), shkruani udhëzimet tuaja me vendmbajtëse {{feed.slug}} që tregojnë saktësisht ku përfundojnë të dhënat tona në përgjigje, dhe shtoni një fjali përmbyllëse tuajën që i bashkëngjitet çdo përgjigjeje. Modele të gatshme: asistent personal udhëtimi, asistent pune/mallrash, asistent shitjeje sigurimesh dhe Karte Jeshile.

Testojeni në studio (30 përgjigje në ditë, veçmas nga kuota juaj e API-t), pastaj thirreni në prodhim te GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Çmimi për përgjigje = njësitë e nivelit të modelit + 1 njësi për çdo burim të aktivizuar, kthyer në X-Devapi-Units. Produkti është vetëm v2 — një URL v1 kthen unsupported_version. Produkti ekzistues assistant mbetet i pandryshuar.

Çdo asistent funksionon nën një politikë përmbajtjeje të platformës që ka përparësi ndaj udhëzimeve tuaja: pa u paraqitur si zyrtar, pa ndihmë për shmangien e kontrollit kufitar ose doganor, pa shifra të sajuara, pa fjalor vulgar. Kontrollohen si udhëzimet, ashtu edhe përgjigjet; thirrjet e bllokuara regjistrohen.

E re: një server i vërtetë MCP në https://nakordoni.eu/mcp, që ekspozon një nënbashkësi të sigurt, vetëm-lexim, të API-së (status, checkpoints, border queue, live queue, forecast) si mjete MCP. E njëjta çelës API dhe kuotë si te API-ja REST. Karta e serverit në /.well-known/mcp/server-card.json. Shihni seksionin Server MCP në dokumentacion.

Riemërtimi në „Live Queue & Freshness API“ i përshkruar më poshtë në të vërtetë nuk arriti te faqja e dokumentacionit . Faqja e shfaq titullin e çdo produkti përmes një kërkimi përkthimi që i drejtohet titullit të pikës fundore vetëm kur nuk ekziston përkthim — ndërsa një përkthim ekzistonte tashmë, i ngrirë në emrin e vjetër, në të 25 gjuhët e ndërfaqes. Tani ai ka përparësi ndaj çdo përditësimi të ardhshëm të titullit bazë, derisa të përditësohet edhe vetë.

Çelësi i përkthimit u riemërtua në të 25 gjuhët, kështu që faqja e dokumentacionit tani përputhet. Asnjë ndryshim në pikën fundore, parametrat ose përgjigjen — vetëm teksti i titullit.

Nëse i merrni shpesh të dhënat e radhës së drejtpërdrejtë, mund të jeni duke shpenzuar kuotë të rëndë pa nevojë. /update-info është e klasës standarde dhe e kthen tashmë vlerën e drejtpërdrejtë:

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

Kthen queue_now, freshness, age_minutes, is_realtime, status, timestamp dhe timezone. Përdoreni për rifreskimin e shpeshtë në ngarkim të kuotës suaj standarde ditore dhe ruani /queue, /multi dhe /forecast (të gjitha të klasës së rëndë) për rastet kur ju duhen wait_min, fushat e prirjes ose historiku.

Në vetë pikën fundore nuk ka ndryshuar asgjë — vetëm në dokumentacionin e saj. Ishte listuar si „Data Freshness API“ dhe përshkrimi i saj përmendte vetëm vlerësimin e freskisë, kurrë queue_now, ndaj ishte e lehtë të kalonte pa u vënë re. Tani quhet „Live Queue & Freshness API“, me fushat e kthyera të renditura qartë. Faleminderit zhvilluesit që e ngriti këtë çështje.

Disa kërkesa të dështuara ktheheshin me HTTP 200 dhe ok: true , ndërsa gabimi ishte i varrosur brenda data — kështu modeli i dokumentuar if (!ok) throw nuk mund t'i dallonte dhe thirrja faturohej gjithsesi. Thirrjet e prekura tani kthejnë HTTP 400 me ok: false dhe një error.code / error.messagetë rregullt, siç është dokumentuar. Vërejtur te fuel-cities me një vend të pambështetur dhe te travel-matrix me koordinata të gabuara.

Veçmas: një parametër i detyrueshëm që mungonte kthente 500 internal_error në vend të 400 bad_request (trupi i një përgjigjeje 4xx nga shërbimi i brendshëm hidhej tej para se t'i lexohej statusi). Tani kthen 400 bad_request me mesazhin e shërbimit të brendshëm — p.sh. search pa ?name=.

Përgjigjet e suksesshme janë të pandryshuara bajt për bajt — të njëjtat fusha, të njëjtët parametra, i njëjti kosto kuote. Nëse klienti juaj degëzohet tashmë sipas ok, nuk nevojitet asnjë ndryshim. Nëse e shpërfillte ok dhe lexonte data drejtpërdrejt, tani do të shohë zarfe gabimi te thirrjet që gjithsesi kishin dështuar përherë.

U ndreq një defekt ku /multi mund të kthente një numër të gabuar radhe për disa pika kalimi — kryesisht ballkanike dhe në kufirin Hungari–Serbi — sa herë që kesh-i i tij ishte i ftohtë. Rruga rezervë lexonte një tabelë që, për ato kalime, nuk mban të dhëna radhe, dhe raportonte vlera të palidhura si numër makinash. Shembuj të matur: një pikë me 12 makina raportonte 6, ndërsa disa me radhë reale raportonin 0.

Tri ndryshime që mund t'i vini re:

• found: false tani do të thotë se vërtet nuk ka të dhëna të freskëta radhe. Më parë mund të merrnit found: true me një queue_now: 0të sajuar.
• wait_status, trend_percent dhe trend_direction tani kthehen edhe në kërkesat e ftohta — më parë ishin null .
• Pika fundore kalon te rruga rezervë edhe kur fotografia e saj në kesh është e vjetruar (më e vjetër se 24 orë), jo vetëm kur mungon.

Asnjë ndryshim në parametrat e kërkesës, koston e kuotës apo strukturën e përgjigjes.

U rregullua një gabim për shkak të të cilit çdo thirrje /multi faturohej dy herë — një herë nga një kontroll gjenerik i 1 njësie dhe përsëri nga formula e vet e kostos së ndryshueshme të endpoint-it (N PPID × nënprodukte). Një thirrje tani kushton saktësisht ⌈(N×M)/2⌉ njësi siç është dokumentuar, pa ngarkesë shtesë.

Gjithashtu u shtua një distinktiv i klasës së kuotës (Standard/Heavy) për çdo produkt në faqen e dokumentacionit, që të jetë e qartë me një shikim se cilën kuotë ditore përdor një endpoint.

country dhe countries u bashkuan në një parametër të vetëm (1-15 kode të ndara me presje). Parametër i ri compare_to: krahasim i festave të njëjta ose të ndryshme midis vendeve, kombinohet me upcoming+days. lang tani pranon disa gjuhë (shton një objekt names). days=0 ose i lënë jashtë tani do të thotë pa kufi në modalitetin upcoming.

Festat zyrtare publike për çdo vend evropian — datat, emrat vendorë dhe lloji. Mbështetur nga i njëjti shërbim Nager.Date / OpenHolidaysAPI (me një kalendar të Kosovës të llogaritur në nivel vendor) që fuqizon faqen e kalendarit të festave të nakordoni.eu dhe faktorët kalendarikë të sistemit të parashikimit.

• ?country=PL&year=2026 — lista e festave për të gjithë vitin për një vend
• ?upcoming=1&days=30 — listë e thjeshtë e festave të ardhshme ndër vende
• Pa parametra — indeks i një grupi kryesor vendesh me festën e radhës për secilin

U shtua produkti currency — kurse këmbimi të bazuara në EUR për PLN, CZK, HUF, USD, GBP, CHF, NOK dhe UAH, të marra nga Frankfurter (ECB) dhe të ruajtura në cache për 6 orë. Pa parametra, gjithmonë kthen tabelën e plotë të kurseve. Shih dokumentacionin.

Integroni ndalimet e qarkullimit të kamionëve në Evropë në kohë reale në faqen tuaj të internetit — një widget iframe falas me 3 dizajne (light, dark, board), 5 gjuhë (en, uk, pl, de, ru), një filtër opsional sipas vendit dhe një status «aktiv tani» në kohë reale. Nuk nevojitet çelës API. Konfiguroni dhe kopjoni kodin te nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Preferoni të dhënat e papërpunuara? Produkti API truck-bans dhe feed-i publik JSON mbeten të disponueshëm.

Tri shtesa, të gjitha të pajtueshme me versionet e mëparshme — v1 është e pandryshuar.

Versionim për çdo endpoint. Tani ekziston një URL bazë /api/v2/. Është për çdo endpoint: vetëm endpoint-et që kanë ndryshuar vërtet sillen ndryshe në v2; çdo endpoint tjetër shërben në mënyrë transparente përgjigjen e vet v1 (pra /api/v2/data/queue = të njëjtat të dhëna si v1, thjesht me "api_version":"v2"). Nuk ka nevojë të migroni endpoint-et që funksionojnë.

border v2 është me drejtim. Rendi i shtegut është drejtimi i udhëtimit:

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)

Çdo checkpoint fiton gjithashtu një objekt direction {from,to} dhe një boolean stale, dhe ?max_age_min=N kthen vetëm kalimet e përditësuara së fundmi. (Në v1, border vazhdon të kthejë të dyja anët e kufirit pavarësisht nga rendi — i pandryshuar.)

Sandbox interaktiv. Zhvilluesit e kyçur tani mund të provojnë çdo endpoint nga shfletuesi te Zhvilluesit → Sandbox — zgjidhni një endpoint, një version dhe një nga çelësat tuaj, ndryshoni parametrat dhe shihni përgjigjen në kohë reale. Testimi në Sandbox ka buxhetin e vet ditor të veçantë (50 thirrje/ditë) dhe nuk prek kurrë kuotën tuaj reale të API-t.

Dokumentacioni tani është i ndarë sipas endpoint-it (Zhvilluesit → Dokumentacioni i API-t) me një përzgjedhës versioni te endpoint-et që kanë më shumë se një version.

Dy faktorë të rinj të integruar në formulën e kohës së pritjes, krahas rregullimeve ekzistuese section_mode dhe atyre të motit:

• service_rate — makina/min që po përpunohen aktualisht, të matura kundrejt normës bazë të konfiguruar të checkpoint-it. Shumëzues, i kufizuar midis 0.5x dhe 1.5x.
• shift_change — ndikimi i ndërrimit të turnit të rojeve kufitare në 08:00/20:00, specifik për çdo checkpoint. Mbledhës (minuta), jo shumëzues — zbatohet vetëm brenda +/-60 minutash nga një ndërrim turni, kërkon një histori minimale mostrash, i kufizuar në +/-120 minuta.

advanced_wait_min tani është round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Të dy faktorët pasqyrohen gjithashtu në driver_reported.prognosed_advanced_wait_min për krahasimet historike.

Si pjesë e një rishikimi sigurie dhe privatësie, fushat e mëposhtme janë hequr — ato ekspozonin detaje të brendshme të implementimit (taksonomia jonë e burimeve të të dhënave në rrjedhën e sipërme, ID-të e rreshtave të DB-së, shënime të brendshme të pipeline-it, fusha të papërdorura ose të vdekura) pa vlerë reale për produktin:

• id dhe corrected — hequr nga objektet e rreshtit të queue
• source (varg i papërpunuar, p.sh. "line") — hequr nga queue, multi dhe update-info. Blloku update_info i update-info dhe i multi ende përmban source_category/source_label_en (një fjalor i vogël publik); blloku queue i queue dhe i multi nuk përmban më asnjë fushë source
• traffic_status — hequr nga border; ishte gjithmonë null dhe nuk mbushej kurrë nga asnjë pjesë e sistemit

Nëse integrimi juaj lexon ndonjë nga këto fusha, ju lutemi përditësojeni — shihni listën aktuale të fushave në faqen e dokumentacionit të produktit përkatës.

Përdorimi i kuotës ditore (usage.used në çdo përgjigje) tani mund të jetë një vlerë dhjetore (p.sh. 67.5) në vend që të jetë gjithmonë një numër i plotë. Kjo është një efekt anësor i faturimit të queue-advanced me një normë thyesore — shih më poshtë. usage.limit nuk preket dhe është gjithmonë një numër i plotë. Nëse klienti juaj e tipizon rreptësisht usage.used si numër të plotë, ju lutemi zgjeroni atë për të pranuar një dhjetor / float.

Këto tre produkte tani kthejnë të njëjtat fusha të statusit në kohë reale që shfaq faqja e internetit: wait_status (green/yellow/red, bazuar në historinë e fundit të vetë këtij checkpoint-i) dhe trend_percent/trend_direction (up/up-slight/down/down-slight/stable, duke krahasuar 3 orët e fundit). Thjesht shtesë.

Rreshtat data[] të /api/v1/data/queue më parë kishin wait_time: null për shumicën e burimeve — vetëm disa feed-e në rrjedhën e sipërme raportojnë drejtpërdrejt një kohë pritjeje. Rreshtat pa një të tillë tani marrin vlerësimin standard , të shënuar me një boolean të ri wait_time_estimated që të mund të dallosh një shifër të raportuar realisht nga një e llogaritur.

queue-advanced tani kushton 1.5 units për thirrje në vend të 1 (duke pasqyruar kërkimet shtesë të trafikut, motit dhe raporteve të shoferëve që kryen) — shih usage.used më sipër. Përgjigja gjithashtu nuk përfshin më total_crossing_time, dhe driver_reported tani është vetëm {wait_min, ts, age_min} — fushat e mëparshme të krahasimit parashikim/realitet (prognosed_wait_min, diff_min, historical_section_mode, historical_weather, etj.) janë hequr. section_mode, weather, advanced_wait_min dhe exceeds_crossing_time janë të pandryshuara.

/api/v1/data/truck-bans tani kthen, për çdo vend në bans_by_country, një status (active/clear) plus active_window, next_window, local_time dhe tz — të llogaritura në zonën kohore të vetë atij vendi, kështu që nuk keni më nevojë të vlerësoni vetë dritaret e papërpunuara të ndalimit kundrejt një ore. Përgjigja shton gjithashtu një listë covered_countries të nivelit të lartë dhe një vulë kohore UTC as_of.

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

Thjesht shtesë — fushat ekzistuese current_bans/upcoming_bans/bans_by_country janë të pandryshuara. Një ?country= i panjohur tani kthen një rezultat bosh me countries_not_covered në vend të ndalimeve të çdo vendi.

Një produkt i ri opsional që rregullon kohën standarde të pritjes sipas fluksit të trafikut në kohë reale dhe motit. Kthen zbërthimin e plotë të çdo rregullimi.

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

Jepet me kërkesë — hapni një tiket Data nga paneli juaj për ta aktivizuar.

/api/v1/data/border tani llogarit saktë wait_min për çdo checkpoint në përgjigje, njësoj si produktet queue dhe multi. Më parë kjo fushë ishte gjithmonë null.

/api/v1/data/forecast tani përdor në mënyrë të besueshme modelin ensemble v4 për çdo vlerë të prediction_steps (më parë disa horizonte jostandarde mund të riktheheshin në heshtje te një model më i vjetër). Faktori i motit që ushqen ensemble-in është gjithashtu i korrigjuar dhe tani pasqyron vërtet kushtet në kohë reale (shi, borë, erë, mjegull) në vend që të raportojë gjithmonë si të padisponueshëm.

Zhvilluesit e miratuar tani mund të shkarkojnë të dhëna historike të radhëve në kufi, të mesatarizuara për orë, për deri në 5 checkpoint (dritare rrotulluese deri në 90 ditë) në formatin CSV ose NDJSON nga skeda e re Data export. Të dhënat janë vetëm të publikuara dhe të kontrolluara për cilësi; vulat kohore janë në UTC. Ju nevojitet qasje? Hapni një tiket Data.

Ende nuk keni faqe interneti? Tani mund të krijoni një llogari zhvilluesi duke përshkruar ku dhe si planifikoni të përdorni të dhënat tona, në vend që të detyroheni të vendosni URL-në e një faqeje aktive. Shtoni URL-në reale më vonë nga paneli juaj (Llogaria & të dhënat → Projekti juaj) sapo faqja ose aplikacioni juaj të jetë online — një link i dukshëm që kthehet te nakordoni.eu në atë faqe kërkohet nga Kushtet tona.

Zhvilluesit tani mund të dërgojnë lajmet e tyre të lidhura me kufirin te linja e lajmeve të Nakordoni. Nëse redaktorët tanë e publikojnë, ju merrni një backlink dofollow të indeksueshëm drejt shërbimit tuaj (firma e botuesit + rreshti i burimit) dhe ne e përkthejmë artikullin në të gjitha 24 gjuhët falas.

Një artikull në javë është falas; artikujt shtesë janë një shtesë me pagesë. Zgjidhni 'mund ta redaktojmë lehtë + të shtojmë lidhje të brendshme' ose 'publikoje siç është'. Dërgoni dhe ndiqni statusin e rishikimit te Zhvilluesit → Dërgo lajm.

Multi-Checkpoint API (/api/v1/data/multi) tani fatura kuotën me ⌈(N PPIDs × nën-produkte) / 2⌉ — gjysma e kostos së thirrjeve individuale ekuivalente. Një kërkesë për 10 checkpoint me të dy nën-produktet tani kushton 10 units në vend të 20. Header-i X-Devapi-Units dhe meta.units_consumed në përgjigje pasqyrojnë shumën e zbritur.

Merrni statusin e radhëve në kohë reale dhe freskinë e të dhënave për deri në 20 checkpoint në një thirrje të vetme API — projektuar për ndërtuesit e paneleve që aktualisht kontrollojnë shumë PPIDs në një cikël.

Kuota numërohet në mënyrë të drejtë si N PPIDs × nën-produkte të kërkuara, kështu që përdorimi total është identik me thirrjet individuale — por me një udhëtim vajtje-ardhje në vend të shumëve. Modelet e tipit GreenTravel bien nga mbi 24 thirrje/orë në 2.

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

• include=queue — queue_now aktual, wait_min i vlerësuar, mosha e të dhënave dhe emri i checkpoint-it
• include=update-info — freskia e të dhënave, klasifikimi i burimit, mosha në sekonda/minuta
• Maksimumi 20 PPIDs për kërkesë; kombinoni të dy nën-produktet në një thirrje të vetme për të gjitha të dhënat e panelit
• Përgjigja përfshin meta.units_consumed që të mund të ndiqni me saktësi përdorimin e kuotës

Përgjigja e produktit queue tani përfshin një objekt snapshot të nivelit të lartë me të dhënat më të fundit në kohë reale dhe një kohë pritjeje të parashikuar e të llogaritur — të njëjtën formulë të përdorur në seksionin hero të nakordoni.eu:

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

Vargu data (hyrjet historike) është i pandryshuar — kjo është një shtesë thjesht shtuese. Klientët që nuk lexojnë snapshot nuk preken.

Kërkoni të gjitha checkpoint-et në një kufi + lloj automjeti të dhënë në një thirrje të vetme në vend që të bëni një kërkesë për çdo PPID.

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

• Mbështet një vend të vetëm destinacioni, një listë të ndarë me presje, ose all për ta zgjeruar te çdo fqinj i monitoruar njëherësh.
• Rezultatet të renditura sipas queue_now në rritje (radha më e shkurtër e para).
• Plotësisht i lokalizuar: shtoni ?lang=uk (ose ndonjë nga 22 gjuhët tona të mbështetura) për të marrë emrat e checkpoint-eve në atë gjuhë.

Zbuloni vlerat PPID të checkpoint-eve sipas emrit pa shfletuar të gjithë direktorinë.

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

• Pranon një emër të vetëm ose një listë të ndarë me presje (deri në 20).
• Kërkon në të gjitha 24 gjuhët e përkthimit — jepni një emër në ukrainisht, polonisht, gjermanisht ose çdo gjuhë të mbështetur dhe do të përputhet.
• Kthen të gjitha PPIDs në atë vendndodhje të grupuara sipas llojit të automjetit (makinë / autobus / këmbësor / kamion).

Produkti alternatives tani pranon ?lang= në të gjitha 22 gjuhët e mbështetura (më parë ishin vetëm 12).

Parametri i ri crossing_type ju lejon të mbivendosni filtrin e llojit të automjetit — p.sh. jepni crossing_type=4 për të marrë alternativa makine edhe kur kërkoni nga një PPID autobusi.

Fusha crossing_type_label në përgjigjet e checkpoints, border dhe search tani përkthehet në gjuhën e kërkuar, në të gjitha 22 gjuhët e mbështetura. Fushat e emrit të vendit (origin_name, destination_name) ndjekin të njëjtën locale.

Portali API i zhvilluesve i Nakordoni është online në adresën /en/developers. Regjistrohuni për një çelës Explorer falas (200 kërkesa/ditë) për të aksesuar të dhënat e radhëve në kufi, parashikimet, çmimet e karburantit, POIs për shoferët dhe më shumë.

Produktet e disponueshme në lançim: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.