Historiku i ndryshimeve të API

Produkt i ri lane-cost-index (GET /api/v2/data/lane-cost-index). Kthen indeksin e kostos së një udhëtimi me ngarkesë të një kamioni nga A në B në Evropë: karburant, pagesa rrugore, kohë e shoferit dhe dieta.

• Hyrja: from dhe to si "lat,lng" ose id qyteti, vehicle (për shembull artic_40t), sipas dëshirës euro, co2_class dhe empty_return.
• Sipas vendit: km, pagesa rrugore, litra nafte dhe kosto e karburantit (pa TVSH), si dhe klasa e mjetit e përdorur për pagesën.
• Koha e shoferit: drejtimi, pushimet dhe ndalesat ndjekin rregullat e BE 561/2006. Kosto e shoferit dhe dieta përdorin tarifën e vendit të nisjes. Spanja dhe Italia tani kanë një tarifë shoferi dhe dietë nga kontratat kolektive.
• Trendi: trend jep indeksin e kostos për muajin aktual dhe dy muajt e mëparshëm.
• Të dhëna jo të plota: kur një vend në rrugë nuk ka të dhëna për pagesat rrugore ose karburantin, ose vendi i nisjes nuk ka tarifë shoferi, incomplete është true dhe totali është kufi i poshtëm. missing_countries dhe missing_components tregojnë çfarë mungon.

Ky është indeks kostoje, jo çmim transporti: kapitali i mjetit, sigurimi, shpenzimet e përgjithshme dhe marzhi nuk përfshihen.

Kuota: një kërkesë llogaritet si 1 njësi e klasës route, njësoj si truck-route.

Dokumentacioni: Lane Cost Index.

Produkti toll-cost tani llogarit më saktë Francën, Spanjën dhe Italinë.

• Franca dhe Spanja: një pjesë autostrade midis dy pikave të pagesës në rrugë llogaritet sipas tarifës hyrje/dalje të operatorit të autostradës. Shfaqet si lloj i ri elementi motorway_section me operatorin ose rrugën, dy pikat, toll_km dhe cost_eur. Km e tjera me pagesë të vendit përdorin ende mesataren për km.
• Klasa e mjetit: Franca: klasa 3 për 2 akse dhe klasa 4 për 3 ose më shumë akse. Spanja: Pesados 1 për 2 ose 3 akse dhe Pesados 2 për 4 ose më shumë akse.
• Italia: kamionët me 2 dhe 3 akse tani kanë tarifat e tyre për km.
• Klasa Euro dhe CO2: tarifat franceze, italiane dhe spanjolle nuk varen nga këto klasa. Kur dërgoni euro ose co2_class, class_fallback është false për këto vende dhe class_note tregon arsyen.
• Pa rrugë me pagesë: një rrugë në Spanjë pa rrugë me pagesë (për shembull Zaragoza – Barcelona) kthen Spanjën me cost_eur 0 dhe scheme not_tolled.

Vendet e tjera nuk ndryshojnë. Dokumentacioni: Truck Toll Cost.

Produkt i ri toll-cost (POST /api/v2/data/toll-cost, trup JSON). Kthen koston e pagesave rrugore për kamion në një itinerar nëpër Evropë.

• Hyrja: vija e itinerarit si coordinates (për shembull gjeometria nga truck-route) ose waypoints për të cilat llogarisim itinerarin me rrugëzimin tonë për kamionë.
• Mjeti: axles, gross_weight_t, euro dhe co2_class. Opsionale date për tarifat dhe currency për totalin.
• Sipas vendeve: km me pagesë, tarifa efektive në EUR për km, kostoja, klasa e mjetit e tarifuar dhe data e tarifës. Tarifat për një klasë të caktuar Euro dhe CO2 përdoren aty ku ka një tarifë zyrtare për atë klasë. Përndryshe përdoret tarifa e klasës së paracaktuar dhe class_fallback është true.
• Zëra të veçantë: seksione autostrade me koncesion, si dhe tunele dhe ura me pagesën e tyre për kamionë (për shembull Calafat-Vidin).

Kuota: një kërkesë llogaritet si 1 njësi e klasës route, njësoj si truck-route.

Dokumentacioni: Truck Toll Cost.

Dy produkte të reja në /api/v2. Për një udhëtim me autobus tregojnë cila anë ka diell ose hije dhe cilat vende janë më të mirat për hije ose për pamje.

• bus-sun-side (/api/v2/data/bus-sun-side), GET: një rrugë nga regjistri ynë i linjave të autobusëve (route_id, dir, date) ose një udhëtim i lirë (from, to, depart).
• bus-sun-side, POST: dërgoni rrugën tuaj si listë ndalesash, vijë GeoJSON ose polivijë të koduar. Shtoni parametrat e autobusit (rreshtat, rregullimi i ndenjëseve, ana e derës, dritaret, kati) ose zgjidhni një model nga katalogu me bus_model.
• Moti: për udhëtimet në 3 ditët e ardhshme përdoret parashikimi për çdo orë përgjatë rrugës. Udhëtimet më të vona llogariten për qiell të kthjellët. Dërgoni weather=0 për të marrë gjithmonë rezultatin për qiell të kthjellët.
• Imazhet (POST): harta e vendeve, harta e rrugës dhe kronologjia si URL në PNG, WebP ose JPG. Imazhet ruhen 12 orë. Merrni edhe embed_html për ta shfaqur rezultatin në faqen tuaj. URL-të e imazheve fillojnë me https://api.nakordoni.dev/images/.
• Animacioni: blloku animation ka një kuadër çdo 5 minuta me pozicionin e autobusit, drejtimin, azimutin dhe lartësinë e diellit dhe anën me diell, me etiketa në gjuhën tuaj, totale për çdo anë dhe një legjendë. Dërgoni animation=0 për ta hequr.
• Widget: shfaqni rezultatin në çdo faqe interneti, përfshirë WordPress, me një etiketë script ose një iframe. Widget-i përdor një çelës publik që funksionon vetëm në origjinat që lejoni, dhe pllakat tona të hartës. Ofrohet një shtojcë WordPress (zip).
• bus-sun-catalog (/api/v2/data/bus-sun-catalog): modelet e autobusëve që pranon bus-sun-side, me rregullimin e ndenjëseve dhe dritaret.

Kuota: një kërkesë POST me imazhe llogaritet si 2 njësi. Të gjitha kërkesat e tjera llogariten si 1 njësi.

Dokumentacioni: Bus Sun Side.

fleet-compliance-validate tani mbulon më shumë nga EU 561/2006, siç është ndryshuar me Rregulloren (BE) 2020/1054. Fushat ekzistuese të përgjigjes nuk ndryshojnë; shtohen fusha të reja.

• Përjashtimi i Nenit 12: shënoni aktivitetet e drejtimit me art12_exceed: true. Në raste të jashtëzakonshme, shoferi mund t'i kalojë kufijtë ditorë dhe javorë të drejtimit deri në 1 orë për të arritur te qendra operative ose në shtëpi për pushimin javor, ose deri në 2 orë pas një pauze 30 min kur pason një pushim javor i rregullt. Validuesi e pranon këtë dhe kthen kompensimin e detyrueshëm dhe afatin e tij (fundi i javës së tretë pas) te remaining.driving.art12_compensation dhe exceptions.art12.
• Kthimi në bazë, Neni 8(8a): dërgoni location (residence, operational_centre ose elsewhere) te pushimet javore. Merrni një paralajmërim kur 4 javë radhazi nuk kanë pushim javor të rregullt në shtëpi ose në qendrën operative.
• Derogimi 12-ditor, Neni 8(6a): passenger_12day: true për një shërbim të vetëm okazional ndërkombëtar me autobus. Pushimi javor mund të vijë deri në dymbëdhjetë periudha 24-orëshe pas një pushimi javor të rregullt. Kontrollohen pushimet pas tij dhe drejtimi gjatë natës (22:00-06:00). AETR Neni 8(6)(b) zbatohet njëlloj.
• Dritaret kombëtare të natës (Direktiva 2002/15/KE Neni 3(h)): përdorni country ose wtd.country për të zbatuar periudhën kombëtare të natës. Të verifikuara: AT, IE (pasagjerët veçmas) dhe SE. Vendet e tjera të BE/ZEE përdorin 00:00-04:00 dhe kthejnë night_window_verified: false.
• fleet-compliance-limits: AETR tani liston ndryshimet pas vitit 2010 që u kontrolluan. Ato ndryshojnë vetëm Nenin 14, jo rregullat e drejtimit ose pushimit.

Dokumentacioni: Fleet Compliance.

Katër produkte të reja, të shërbyera nga /api/v2 dhe të llogaritura nga motori ynë i rregullave të festave për 51 vende (Evropë dhe Gjiri: SA, AE, QA, KW, BH, OM), 2020-2035:

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — festa publike, bankare, rajonale, fetare dhe përkujtimore për deri në 10 vende në një vit ose në një interval datash. Çdo festë tregon nëse është ditë pushimi, festë bankare ose brenda pushimeve shkollore, nëse një festë e fundjavës është zhvendosur në një ditë tjetër, nëse një datë e kalendarit islamik është ende e vlerësuar dhe nëse atë ditë zbatohet ndalimi i qarkullimit të kamionëve (truck_ban). Filtro sipas rajonit (region=DE-BY), llojit, gjuhës dhe emrit; school=1 shton pushimet shkollore.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — numëron ditët e punës midis dy datave, shton ose zbret ditë pune, verifikon një datë ose gjen ditën e ardhshme apo të mëparshme të punës. Përdor fundjavën e vendit (e shtunë-e diel, ose e premte-e shtunë dhe fundjava të tjera në Gjir), ditët e pushimit kombëtare dhe rajonale si dhe zhvendosjet e ditëve me dekret.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — vendet e mbuluara me ditët e fundjavës, zonën kohore, rajonet dhe llojet e festave; me country= jep edhe ditët e punës për vit dhe pesë festat e ardhshme.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, plani Pro dhe më lart) — ndikimi i biznesit i vlerësuar nga modeli: një pikëzim ndikimi 0-100 për çdo festë, probabiliteti i mbylljes së dyqaneve, kategoritë e kërkesës, pozicioni i fundjavës së gjatë dhe i urës, si dhe dritaret e rritjes së kërkesës. Te holiday-calendar-holidays, planet Pro dhe më lart marrin gjithashtu këtë bllok me include=impact dhe mund të filtrojnë me min_impact.

Produkti ekzistues holiday-calendar nuk ndryshon. Dokumentacioni: Holiday Calendar.

Tre produkte të reja për përputhshmërinë e kohës së drejtimit, të shërbyera nga /api/v2:

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, trup JSON) — kontrollon aktivitetin e regjistruar të shoferit sipas EU 561/2006 ose AETR dhe kohës së punës sipas Directive 2002/15/EC. Kthen çdo shkelje me nenin e rregullit dhe nivelin e rëndësisë, si dhe çfarë i ka mbetur shoferit tani: drejtimin ditor, kufijtë lëvizës prej 56 h në javë dhe 90 h në dy javë, pushimin e ardhshëm, pushimin ditor dhe javor. Mbulon pushimet e ndara, ditët e shkurtuara dhe të zgjatura, kompensimin e pushimit javor të shkurtuar, punën e natës, ekuipazhin e dyfishtë dhe pushimin e ndërprerë nga trageti ose treni.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — parametrat e rregullave për EU 561, AETR (me dallimet nga 561) dhe 2002/15, plus nivelet e rëndësisë sipas Regulation (EU) 2016/403.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, trup JSON) — kontrollon turnet e planifikuara përpara dërgimit kundrejt ndalimeve të qarkullimit të kamionëve, festave publike dhe ditëve të fundjavës në vendet e udhëtimit, si dhe kundrejt rregullave EU 561, AETR dhe 2002/15. Çdo turn merr orën më të hershme ligjore të fillimit.

Dokumentacioni: Fleet Compliance.

Nga v3, ndalesat për pushimin ditor dhe javor kanë fushat in_vehicle_allowed, accommodation_required dhe rule (route-plan me rest_rules=eu561 dhe truck-route). Rregullorja (BE) 2020/1054 ndryshoi nenin 8(8) të EU 561/2006: pushimi javor i rregullt dhe çdo pushim javor më i gjatë se 45 orë nuk mund të bëhet në automjet. Për këto ndalesa in_vehicle_allowed = false. Pushimi javor i reduktuar (nga 24 orë deri në më pak se 45 orë) dhe pushimi ditor mund të bëhen në një automjet të ndaluar me vend për gjumë.

Ndalesat për pushimin javor kanë gjithashtu accommodation[] — parkingje me dhoma në vend pranë ndalesës — dhe parkingu i ndalesës ka has_accommodation. Ky është vetëm informacion: ndalesa, ora e saj dhe parkingu për kamionë nuk ndryshojnë. Nëse nuk njihet asnjë vend me dhoma, ndalesa ka warning = no_accommodation_found. Përgjigjet v1 dhe v2 nuk ndryshojnë.

Çmimet e stacioneve në /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local dhe /api/v2/data/fuel me mode=nearest tani kanë një moshë maksimale prej 90 ditësh. Një çmim që e konfirmuam për herë të fundit më shumë se 90 ditë më parë nuk kthehet më. Më parë, një çmim i tillë kthehej me stale = true.

Çfarë ndryshon në përgjigje: një lloj karburanti që ka vetëm një çmim më të vjetër mungon në prices; një stacion pa asnjë çmim të mbetur nuk listohet, ose ka një objekt prices bosh aty ku shfaqen stacione pa çmim; dhe një përgjigje mund të jetë bosh aty ku më parë listonte çmime të vjetra. Një përgjigje bosh përmban si gjithmonë empty_reason. fuel-local mund të përgjigjet atëherë nga niveli i rajonit ose i vendit. Flamuri stale nuk ndryshon: është true kur një çmim është konfirmuar për herë të fundit më shumë se 7 ditë më parë. Historiku i çmimeve ruhet. Për fuel-cities, fuel-cost, mesataret kombëtare dhe fuel-grades nuk ka ndryshim praktik. Detaje: Mosha e çmimit.

GET /api/v2/data/route-plan merr në v2 një model të zgjeruar ndalesash (vetëm shtesa: asgjë nuk u hoq apo riemërtua) dhe vlera të reja parazgjedhëse në v3 (/api/v3/data/route-plan).

v2, shtesë. Me stop_places=1, çdo ndalesë (pushim, vakt, fjetje, pushim javor) përmban places[]: parkingje kandidate në një dritare kohe vozitjeje rreth ndalesës, secili me name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 dhe type_rank. Rregulloni kërkimin me places_before_min, places_after_min, places_radius_km dhe rest_radius_km; një rreze mbi 25 km kufizohet dhe raportohet me paralajmërimin radius_clamped. rest_rules=legacy|eu561 zgjedh modelin e pushimit, dhe me eu561 mund të dërgoni gjendjen e shoferit: driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used dhe allow_reduced. Lloje të reja ndalesash: ban_wait (me ban: name, country, from, until) dhe weekly_rest; një pritje që zëvendëson një pushim shënohet me counts_as. Kalimet e kamionëve në dalje nga Ukraina me radhë elektronike shtojnë registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note dhe registration_url, si dhe paralajmërimet echerha_registration dhe echerha_wait_unverified.

v3, vlera të reja parazgjedhëse. rest_rules ka si parazgjedhje eu561; emrat e vendeve janë strikte (vetëm parkingje dhe zona pushimi reale); koha e pritjes e publikuar nga eCherha (të dhëna të freskëta, pa kufi) përdoret si pritje në kufi, dhe pritja në kufi llogaritet si pushimi që duhej bërë. v2 mban modelin e vjetër të pushimit dhe filtrin origjinal të vendeve, pra integrimet ekzistuese nuk ndryshojnë. Detaje: Route Planner API.

GET /api/v3/data/truck-route tani përdor pritjen e eCherha në kufi. Në v3, border_crossings[] për korsitë e kamionëve në dalje nga Ukraina me radhë elektronike marrin wait_min nga koha e pritjes e publikuar nga eCherha (vetëm të dhëna të freskëta, pa kufi; nëse është e vjetër, wait_min është null dhe shtohet paralajmërimi echerha_wait_unverified) dhe mbartin registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note dhe registration_url, me paralajmërimin echerha_registration.

Plani i pushimit e trajton pritjen në kufi si kohë të kaluar në kufi: një radhë e gjatë llogaritet si pushimi, pushimi ditor ose javor që duhej bërë (counts_as në rreshtin waits[]), në vend që të shtohet sipër. v2 mbetet i pandryshuar. Detaje: Truck Route API.

Kur /api/v2/data/fuel-stations ose /api/v2/data/fuel-cheapest nuk gjen asnjë stacion, përgjigja prapë është HTTP 200 me listë bosh, dhe tani tregon arsyen. Vetëm në përgjigje bosh, data përmban empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type ose no_fresh_price_in_radius), nearest_station_km (stacioni më i afërt me llojin tuaj të karburantit, kërkuar deri në nearest_search_km = 50 km; null nëse nuk ka), country dhe suggestion, një fjali e shkurtër në lang tuaj, për shembull: Asnjë stacion brenda 5 km — më i afërti është 6,4 km larg; provoni radius_km=10.

Degëzoni kodin tuaj sipas empty_reason dhe nearest_station_km. suggestion është këshillë për njerëzit dhe formulimi i saj mund të ndryshojë. Nuk e zgjerojmë kurrë rrezen në vendin tuaj. Nëse mostroni një zonë ose një itinerar në rrjetë, përdorni radius_km 10–15. Përgjigjet që përmbajnë stacione nuk ndryshojnë. Detaje: Përgjigje bosh.

Rrezja e kërkimit. radius_km te /api/v2/data/fuel-stations tani mban një shifër dhjetore. Një rreze si 4.8 më parë shkurtohej në 4 pa njoftim, kështu që çdo kërkim mbulonte deri në një të tretën më pak sipërfaqe nga e kërkuara dhe mund të kthente më pak stacione ose asnjë. anchor.radius_km tregon rrezen e zbatuar realisht; numrat e plotë kthehen si më parë.

Emrat e markave. E njëjta markë tani shkruhet gjithmonë njësoj te brand — për shembull ORLEN dhe orlen kthehen si Orlen, dhe CircleK si Circle K. Stacionet, çmimet, id-të dhe fushat nuk ndryshojnë. Nëse i përputhni markat sipas shkrimit të saktë (për logo ose filtra), kontrolloni listën tuaj me emrat e rinj.

GET /api/v2/data/truck-route pranon një parametër të ri opsional traffic. Ai përcakton si merret parasysh trafiku për ETA, planin e pushimeve, orët e mbërritjes në kufij dhe orët te ndalimet për kamionë:

• forecast (parazgjedhja): ngarkesa e përsëritur në orën kur kamioni kalon çdo segment, bllokimet aktuale që zbehen me kohën deri në mbërritje, punimet dhe mbylljet në itinerar, dhe moti ku e kemi. Përgjigja përmban një bllok traffic_forecast me vonesën të ndarë sipas shkakut.
• live: vetëm trafiku aktual, pa ngarkesën e përsëritur.
• off: pa rregullim për trafikun; kohët janë kohët e motorit të kamionëve me qarkullim të lirë. Atëherë traffic_forecast përmban vetëm model dhe mode.

Çdo vlerë tjetër kthen 400 bad_request me mesazhin Invalid traffic: forecast, live or off. Kërkesat pa parametër marrin parazgjedhjen, forecast.

Ndalimet për kamionë në orën e parashikuar të mbërritjes: me forecast ose live, truck_bans[].active tani gjykohet në orën kur parashikohet që kamioni të arrijë çdo ndalim (nga depart_at, ose nga tani nëse nuk dërgoni), para çdo pritjeje për atë ndalim. Një fushë e re truck_bans[].active_at jep orën që u gjykua, në orën lokale të vendit të ndalimit. bans_summary, restriction_hits dhe legal ndjekin të njëjtat vendime, dhe një ndalim në të cilin vonesa e parashikuar bie për herë të parë (për shembull në një ditë më vonë ose në një vend tjetër) renditet gjithashtu te truck_bans. Me traffic=off, active gjykohet në vijën kohore të qarkullimit të lirë dhe active_at është i barabartë me eta_at_ban.

Produkt i ri: Truck Route API (GET /api/v2/data/truck-route, vetëm v2). Një thirrje kthen një itinerar të ligjshëm për kamion dhe gjithçka që i duhet një dispeçeri përgjatë tij. Itinerari llogaritet nga i njëjti bërthamë rrugëzimi si aplikacioni ynë i navigimit për kamionë TruckTurn, mbi të dhënat tona të hartës.

• Automjeti: height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (klasat ADR) dhe adr_tunnel (B–E). Ndalimet e qarkullimit për kamionë dhe zonat me kufizime kontrollohen mbi vijën e kthyer.
• Përgjatë itinerarit: stacione karburanti me çmime aktuale, parkime për kamionë dhe stacione peshimi, secili me km_from_start dhe devijim.
• Plani i pushimit të shoferit sipas Rregullores 561/2006 të BE-së: pushime të shkurtra (përfshirë ndarjen 15+30), pushim ditor dhe javor (përfshirë të reduktuarin), ekuipazh me një ose dy shoferë (crew=2), duke nisur nga gjendja aktuale e shoferit nëse e jepni. Çdo ndalesë vendoset në një parkim real përgjatë itinerarit. Është një ndihmë planifikimi, jo një regjistrim i tahografit.
• ETA që përfshin pushimet, ndalimet e qarkullimit për kamionë dhe pritjet në kufi. Planifikoni sipas depart_at ose arrive_at.
• Vlerësime të kostos së pagesave rrugore sipas shtetit (EUR, sipas akseve dhe klasës së emetimeve), me shtetet pa çmim të listuara te tolls.coverage_note. Gjithashtu avoid (pagesa rrugore, trageti, autostrada, kufij, tunele, rrugë të pashtruara, zona me emetime të ulëta), deri në 2 alternativa, ndarje sipas shtetit dhe geometry si polyline5, polyline6 ose GeoJSON.

Kuota: një kuotë e veçantë truck-route: 10 thirrje në ditë për çdo llogari, më shumë në planet me pagesë, dhe një shtesë Thirrje shtesë truck-route. Në sandbox mund të ekzekutoni 10 itinerare kamioni në ditë, ta shihni rezultatin në hartë me planin e plotë të itinerarit dhe ta eksportoni si GPX, KML, GeoJSON, CSV, kalendar (.ics) ose ITN. Shihni faqen e produktit dhe referencën.

Sipas Kushteve të API-së, një Market është vendi të cilit i përdorni të dhënat, dhe çelësi juaj mbulon vendet e miratuara për llogarinë tuaj. Deri tani, produktet me koordinata (lat/lon — p.sh. Nearby Shops, Truck Parkings, Fuel Stations) përgjigjeshin për çdo pikë në Evropë. Nga 13 tetori 2026, kjo kontrollohet gjatë përpunimit të kërkesës suaj:

• Një kërkesë, lat/lon e së cilës ndodhet në një vend të pamiratuar për llogarinë tuaj, kthen 403 me error.code market_not_allowed. Mesazhi tregon vendin dhe listën tuaj të vendeve të miratuara.
• Kur rrezja kalon një kufi, rezultatet, country_code i të cilave është jashtë vendeve tuaja të miratuara, hiqen. Përgjigja atëherë përfshin markets_filtered (sa u hoqën) dhe markets_notice, ndërsa total_found numëron vetëm ato që morët.

Kjo vlen për llogaritë, vendet e të cilave janë shqyrtuar (statusi approved ose partial). Asgjë nuk ndryshon në kërkesë — asnjë parametër i ri, asnjë version i ri. Nëse aplikacioni juaj ka nevojë për një vend tjetër, shtojeni në portalin e zhvilluesve përpara 13 tetorit. market_not_allowed është listuar bashkë me kodet e tjera të gabimit në referencë.

Llogaritë e zhvilluesve të lidhura me një llogari Nakordoni Partners me të njëjtin email tani mund të dërgojnë lajme dhe të menaxhojnë flotën e tyre NakBus (NakDriver / NakManager) nga partners.nakordoni.eu, me role ekipi (Owner, Manager, Viewer) dhe hyrje me një klikim mes dy portaleve. Faqet e portalit të zhvilluesve, çelësat API, pikat përfundimtare të flotës dhe aplikacionet mbeten të pandryshuara.

Te Fuel Prices, updated_at dhe flamuri age_hours/stale i vetë përgjigjes punonin me ora të ndryshme: updated_at lëviz vetëm kur një çmim ndryshon realisht, por vjetërsia llogaritej sikur lëvizte në çdo konfirmim. 46.7% e indeksit me çmime tregonte age_hours ≤48 dhe stale:false, ndërkohë që updated_at ishte në fakt më i vjetër se 48 orë, me 12,620 stacione më të vjetra se një javë. Tani çdo çmim mban edhe confirmed_at — hera e fundit që e konfirmuam çmimin, e rrumbullakuar poshtë në orë, asnjëherë para updated_at — dhe age_hours/stale llogariten prej tij. Kuptimi i updated_at nuk ka ndryshuar: përdoreni kur doni të dini kur ka ndryshuar çmimi herën e fundit, dhe përdorni confirmed_at kur doni të dini sa i freskët është tani. Nuk është i pranishëm në kontratën e ngrirë v1.

Dy defekte gjuhe, të dyja të heshtura: dërgimi i kodit kanonik të cilësisë me lang=pl (ose cilëndo nga 24 gjuhët e tjera të faqes) e kthente fuel_type_local në anglisht gjithsesi — vetëm 10 gjuhë kontrolloheshin në tabelën e etiketave, kështu që çdo gjuhë jashtë asaj liste binte te fjalori i paracaktuar i ndërfaqes në vend të gjuhës që kërkuat. Veçmas, lang=tr (ose disa kode të tjera të vlefshme) i kthente listat e stacioneve në ukrainisht, sepse një vlerë e brendshme e paracaktuar uk aktivizohej sa herë gjuha e kërkuar nuk ishte në po atë listë me 10 gjuhë. Të dyja janë rregulluar: gjuha që dërgoni tani është gjuha që merrni, në të gjitha 25.

Gjithashtu: brand te Nearby Fuel Stations nuk kthen më shenjën e papërpunuar të marrjes së të dhënave OTHER për rreth 330 stacione ku nuk e njohim markën — është null, në përputhje me çdo fushë tjetër të panjohur në përgjigje.

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

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.