Note di rilascio API

Nuovo prodotto lane-cost-index (GET /api/v2/data/lane-cost-index). Restituisce l'indice di costo di un viaggio a pieno carico di un camion da A a B in Europa: carburante, pedaggi, tempo dell'autista e trasferta.

• Input: from e to come "lat,lng" o id di città, vehicle (per esempio artic_40t), facoltativi euro, co2_class e empty_return.
• Per paese: km, pedaggio, litri di gasolio e costo del carburante (IVA esclusa), e la classe del veicolo usata per il pedaggio.
• Tempo dell'autista: guida, pause e riposi seguono le regole UE 561/2006. Il costo dell'autista e la trasferta usano la tariffa del paese di origine. Spagna e Italia hanno ora una tariffa autista e una trasferta dai contratti collettivi.
• Trend: trend fornisce l'indice di costo del mese corrente e dei due mesi precedenti.
• Dati incompleti: quando un paese sul percorso non ha dati su pedaggi o carburante, o il paese di origine non ha una tariffa autista, incomplete è true e il totale è un limite inferiore. missing_countries e missing_components indicano cosa manca.

È un indice di costo, non un prezzo di trasporto: capitale del veicolo, assicurazione, spese generali e margine non sono inclusi.

Quota: una richiesta conta come 1 unità della classe route, come truck-route.

Documentazione: Lane Cost Index.

Il prodotto toll-cost calcola in modo più preciso Francia, Spagna e Italia.

• Francia e Spagna: un tratto autostradale tra due caselli del percorso è calcolato con la tariffa di entrata/uscita del gestore autostradale. Compare come nuovo tipo di voce motorway_section con il gestore o la strada, i due caselli, toll_km e cost_eur. Gli altri km a pedaggio del paese usano ancora la media per km.
• Classe del veicolo: Francia: classe 3 per 2 assi e classe 4 per 3 o più assi. Spagna: Pesados 1 per 2 o 3 assi e Pesados 2 per 4 o più assi.
• Italia: i camion a 2 e 3 assi hanno ora le proprie tariffe al km.
• Classe Euro e CO2: le tariffe francesi, italiane e spagnole non dipendono da queste classi. Se invii euro o co2_class, class_fallback è false per questi paesi e class_note ne indica il motivo.
• Nessuna strada a pedaggio: un percorso in Spagna senza strade a pedaggio (per esempio Saragozza – Barcellona) restituisce la Spagna con cost_eur 0 e scheme not_tolled.

Gli altri paesi non cambiano. Documentazione: Truck Toll Cost.

Nuovo prodotto toll-cost (POST /api/v2/data/toll-cost, corpo JSON). Restituisce il costo dei pedaggi per camion di un percorso in Europa.

• Input: la linea del percorso come coordinates (per esempio la geometria di truck-route), oppure waypoints che instradiamo con il nostro routing per camion.
• Veicolo: axles, gross_weight_t, euro e co2_class. Facoltativi date per le tariffe e currency per il totale.
• Per paese: km a pedaggio, tariffa effettiva in EUR per km, costo, classe del veicolo tariffata e data della tariffa. Le tariffe specifiche per classe Euro e CO2 sono usate dove esiste una tariffa ufficiale per quella classe. Altrimenti si usa la tariffa della classe predefinita e class_fallback è true.
• Voci separate: tratte autostradali in concessione, e gallerie e ponti con un proprio pedaggio per camion (per esempio Calafat-Vidin).

Quota: una richiesta conta come 1 unità della classe route, come truck-route.

Documentazione: Truck Toll Cost.

Due nuovi prodotti in /api/v2. Per un viaggio in pullman indicano quale lato è al sole o all'ombra e quali posti sono migliori per l'ombra o per la vista.

• bus-sun-side (/api/v2/data/bus-sun-side), GET: un percorso dal nostro registro delle linee di autobus (route_id, dir, date) o un viaggio libero (from, to, depart).
• bus-sun-side, POST: invia il tuo percorso come elenco di fermate, linea GeoJSON o polilinea codificata. Aggiungi i parametri del pullman (file, disposizione dei posti, lato porte, finestrini, piano) o scegli un modello dal catalogo con bus_model.
• Meteo: per i viaggi nei prossimi 3 giorni si usa la previsione oraria lungo il percorso. I viaggi successivi sono calcolati con cielo sereno. Invia weather=0 per ottenere sempre il risultato con cielo sereno.
• Immagini (POST): mappa dei posti, mappa del percorso e cronologia come URL in PNG, WebP o JPG. Le immagini sono conservate per 12 ore. Ricevi anche embed_html per mostrare il risultato sulla tua pagina. Gli URL delle immagini iniziano con https://api.nakordoni.dev/images/.
• Animazione: il blocco animation contiene un fotogramma ogni 5 minuti con posizione del pullman, direzione, azimut e altezza del sole e lato al sole, con etichette nella tua lingua, totali per lato e una legenda. Invia animation=0 per ometterlo.
• Widget: mostra il risultato su qualsiasi sito, anche WordPress, con un tag script o un iframe. Il widget usa una chiave pubblica che funziona solo sulle origini che consenti, e le nostre tile di mappa. È disponibile un plugin WordPress (zip).
• bus-sun-catalog (/api/v2/data/bus-sun-catalog): i modelli di pullman accettati da bus-sun-side, con disposizione dei posti e finestrini.

Quota: una richiesta POST con immagini conta come 2 unità. Tutte le altre richieste contano come 1 unità.

Documentazione: Bus Sun Side.

fleet-compliance-validate ora copre una parte maggiore del Reg. UE 561/2006 come modificato dal Regolamento (UE) 2020/1054. I campi di risposta esistenti non cambiano; vengono aggiunti nuovi campi.

• Eccezione Art. 12: contrassegna le attività di guida con art12_exceed: true. In casi eccezionali il conducente può superare i limiti di guida giornalieri e settimanali fino a 1 h per raggiungere la sede operativa o il proprio domicilio per il riposo settimanale, oppure fino a 2 h dopo una pausa di 30 min quando segue un riposo settimanale regolare. Il validatore lo accetta e restituisce la compensazione dovuta e la relativa scadenza (la fine della terza settimana successiva) in remaining.driving.art12_compensation e exceptions.art12.
• Art. 8(8a) rientro alla sede: invia location (residence, operational_centre o elsewhere) per i riposi settimanali. Ricevi un avviso quando per 4 settimane consecutive non c'è un riposo settimanale regolare a casa o presso la sede operativa.
• Art. 8(6a) deroga di 12 giorni: passenger_12day: true per un singolo servizio internazionale occasionale in autobus. Il riposo settimanale può quindi iniziare fino a dodici periodi di 24 ore dopo un riposo settimanale regolare. Vengono controllati i riposi successivi e la guida notturna (22:00-06:00). L'Art. 8(6)(b) dell'AETR viene applicato allo stesso modo.
• Fasce notturne nazionali (Direttiva 2002/15/CE Art. 3(h)): usa country o wtd.country per applicare il periodo notturno nazionale. Verificati: AT, IE (passeggeri separatamente) e SE. Gli altri paesi UE/SEE usano 00:00-04:00 e restituiscono night_window_verified: false.
• fleet-compliance-limits: l'AETR ora elenca le modifiche successive al 2010 che sono state verificate. Modificano solo l'articolo 14, non le norme su guida e riposo.

Documentazione: Fleet Compliance.

Quattro nuovi prodotti, serviti da /api/v2 e calcolati dal nostro motore proprietario di regole sulle festività per 51 paesi (Europa e Golfo: SA, AE, QA, KW, BH, OM), 2020-2035:

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — festività nazionali, bancarie, regionali, religiose e ricorrenze per un massimo di 10 paesi in un anno o in un intervallo di date. Ogni festività indica se è un giorno non lavorativo, una festività bancaria o se ricade nelle vacanze scolastiche, se una festività nel fine settimana è stata spostata a un altro giorno, se una data del calendario islamico è ancora stimata e se in quel giorno vale un divieto di circolazione per i camion (truck_ban). Filtra per regione (region=DE-BY), tipo, lingua e nome; school=1 aggiunge le vacanze scolastiche.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — conta i giorni lavorativi tra due date, aggiunge o sottrae giorni lavorativi, verifica una data oppure trova il giorno lavorativo successivo o precedente. Utilizza il fine settimana del paese (sabato-domenica, oppure venerdì-sabato e altri fine settimana nei paesi del Golfo), i giorni non lavorativi nazionali e regionali e gli spostamenti di giorni stabiliti per decreto.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — i paesi coperti con giorni del fine settimana, fuso orario, regioni e tipi di festività; con country= anche i giorni lavorativi per anno e le successive cinque festività.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, piano Pro e superiori) — impatto stimato dal modello sull'attività: un punteggio di impatto 0-100 per ogni festività, probabilità di chiusura dei negozi, categorie di domanda, posizione di ponte e fine settimana lungo e finestre di picco della domanda. Su holiday-calendar-holidays, anche i piani Pro e superiori ottengono questo blocco con include=impact e possono filtrare con min_impact.

Il prodotto esistente holiday-calendar non cambia. Documentazione: Holiday Calendar.

Tre nuovi prodotti per la conformità ai tempi di guida, serviti da /api/v2:

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, corpo JSON) — verifica l'attività registrata del conducente rispetto a EU 561/2006 o AETR e all'orario di lavoro della Directive 2002/15/EC. Restituisce ogni infrazione con l'articolo della norma e la fascia di gravità, e ciò che resta al conducente in questo momento: guida giornaliera, limiti mobili di 56 h settimanali e 90 h bisettimanali, prossima pausa, riposo giornaliero e settimanale. Copre pause frazionate, giornate ridotte ed estese, compensazione del riposo settimanale ridotto, lavoro notturno, doppio equipaggio e riposo interrotto da traghetto o treno.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — i parametri delle norme per EU 561, AETR (con le differenze rispetto a 561) e 2002/15, oltre alle fasce di gravità del Regulation (EU) 2016/403.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, corpo JSON) — verifica i turni pianificati prima dell'invio rispetto ai divieti di circolazione dei camion, alle festività nazionali e ai giorni del fine settimana nei paesi del viaggio, e rispetto alle norme EU 561, AETR e 2002/15. Ogni turno riceve l'orario di inizio legale più anticipato.

Documentazione: Fleet Compliance.

Dalla v3 le soste di riposo giornaliero e settimanale hanno i campi in_vehicle_allowed, accommodation_required e rule (route-plan con rest_rules=eu561 e truck-route). Il regolamento (UE) 2020/1054 ha modificato l'art. 8, par. 8 del EU 561/2006: il riposo settimanale regolare e qualsiasi riposo settimanale di oltre 45 h non possono essere effettuati nel veicolo. Per queste soste in_vehicle_allowed = false. Il riposo settimanale ridotto (da 24 h a meno di 45 h) e il riposo giornaliero possono essere effettuati in un veicolo fermo dotato di cuccetta.

Le soste di riposo settimanale hanno anche accommodation[] — parcheggi con camere in loco vicino alla sosta — e il parcheggio della sosta ha has_accommodation. È solo un'informazione: la sosta, il suo orario e il suo parcheggio per camion non cambiano. Se non è noto alcun luogo con camere, la sosta ha warning = no_accommodation_found. Le risposte v1 e v2 non cambiano.

I prezzi delle stazioni in /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local e /api/v2/data/fuel con mode=nearest hanno ora un'età massima di 90 giorni. Un prezzo che abbiamo confermato l'ultima volta più di 90 giorni fa non viene più restituito. Prima, un prezzo del genere veniva restituito con stale = true.

Cosa cambia nelle risposte: un carburante che ha solo un prezzo più vecchio manca in prices; una stazione senza alcun prezzo rimasto non viene elencata, oppure ha un oggetto prices vuoto dove vengono mostrate le stazioni senza prezzo; e una risposta può essere vuota dove prima elencava prezzi vecchi. Una risposta vuota contiene come sempre empty_reason. fuel-local può allora rispondere dal livello di regione o di paese. Il flag stale non cambia: è true quando un prezzo è stato confermato l'ultima volta più di 7 giorni fa. Lo storico dei prezzi viene conservato. Per fuel-cities, fuel-cost, le medie nazionali e fuel-grades non c'è alcun cambiamento pratico. Dettagli: Età dei prezzi.

GET /api/v2/data/route-plan ottiene in v2 un modello di soste ampliato (additivo: nulla è stato rimosso o rinominato) e nuovi valori predefiniti in v3 (/api/v3/data/route-plan).

v2, additivo. Con stop_places=1 ogni sosta (pausa, pasto, pernottamento, riposo settimanale) contiene places[]: parcheggi candidati in una finestra di tempo di guida attorno alla sosta, ciascuno con name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 e type_rank. Regola la ricerca con places_before_min, places_after_min, places_radius_km e rest_radius_km; un raggio superiore a 25 km viene limitato e segnalato con l'avviso radius_clamped. rest_rules=legacy|eu561 sceglie il modello di riposo e con eu561 puoi inviare lo stato del conducente: driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used e allow_reduced. Nuovi tipi di sosta: ban_wait (con ban: name, country, from, until) e weekly_rest; un'attesa che sostituisce una pausa o un riposo è marcata counts_as. I valichi per camion in uscita dall'Ucraina con coda elettronica aggiungono registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note e registration_url, oltre agli avvisi echerha_registration e echerha_wait_unverified.

v3, nuovi valori predefiniti. rest_rules vale per impostazione predefinita eu561; i nomi dei luoghi sono rigorosi (solo veri parcheggi e aree di sosta); l'attesa pubblicata da eCherha (dati freschi, senza limite) è usata come attesa al confine, e un'attesa al confine conta come la pausa o il riposo dovuto. La v2 mantiene il vecchio modello di riposo e il filtro dei luoghi originale, quindi le integrazioni esistenti non cambiano. Dettagli: Route Planner API.

GET /api/v3/data/truck-route usa ora l'attesa al confine di eCherha. In v3 border_crossings[] per le corsie camion in uscita dall'Ucraina con coda elettronica prendono wait_min dall'attesa pubblicata da eCherha (solo dati freschi, senza limite; se i dati sono vecchi wait_min è null e viene aggiunto l'avviso echerha_wait_unverified) e riportano registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note e registration_url, con l'avviso echerha_registration.

Il piano di riposo tratta l'attesa al confine come tempo trascorso al confine: una lunga coda conta come la pausa, il riposo giornaliero o settimanale dovuto (counts_as nella riga waits[]), invece di essere sommata. La v2 non cambia. Dettagli: Truck Route API.

Quando /api/v2/data/fuel-stations o /api/v2/data/fuel-cheapest non trova nessuna stazione, la risposta è comunque HTTP 200 con un elenco vuoto, e ora ne indica il motivo. Solo in una risposta vuota, data contiene empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type o no_fresh_price_in_radius), nearest_station_km (la stazione più vicina con il tuo tipo di carburante, cercata fino a nearest_search_km = 50 km; null se non ce n'è), country e suggestion, una breve frase nella tua lang, ad esempio: Nessuna stazione entro 5 km: la più vicina dista 6,4 km; prova radius_km=10.

Basa la logica del codice su empty_reason e nearest_station_km. suggestion è un consiglio per le persone e la sua formulazione può cambiare. Non ampliamo mai il raggio al posto tuo. Se campioni un'area o un percorso su una griglia, usa radius_km 10–15. Le risposte che contengono stazioni non cambiano. Dettagli: Risposte vuote.

Raggio di ricerca. radius_km su /api/v2/data/fuel-stations ora mantiene una cifra decimale. Un raggio come 4.8 prima veniva troncato a 4 senza avviso, quindi ogni ricerca copriva fino a un terzo di area in meno del richiesto e poteva restituire meno stazioni o nessuna. anchor.radius_km mostra il raggio effettivamente applicato; i numeri interi vengono restituiti come prima.

Nomi dei marchi. Lo stesso marchio ora è sempre scritto allo stesso modo in brand: ad esempio ORLEN e orlen vengono restituiti come Orlen, e CircleK come Circle K. Stazioni, prezzi, id e campi non cambiano. Se associ i marchi per grafia esatta (per loghi o filtri), controlla il tuo elenco rispetto ai nuovi nomi.

GET /api/v2/data/truck-route accetta un nuovo parametro opzionale traffic. Definisce come viene considerato il traffico per l'ETA, il piano delle soste, gli orari di arrivo ai confini e gli orari ai divieti per camion:

• forecast (predefinito): congestione ricorrente all'ora in cui il camion percorre ogni tratto, code attuali che si attenuano con l'avvicinarsi dell'arrivo, lavori stradali e chiusure lungo il percorso, e meteo dove disponibile. La risposta contiene un blocco traffic_forecast con il ritardo suddiviso per causa.
• live: solo il traffico attuale, senza la congestione ricorrente.
• off: nessuna correzione per il traffico; i tempi sono quelli a flusso libero del motore camion. In questo caso traffic_forecast contiene solo model e mode.

Qualsiasi altro valore restituisce 400 bad_request con il messaggio Invalid traffic: forecast, live or off. Le richieste senza il parametro usano il valore predefinito, forecast.

Divieti per camion all'orario di arrivo previsto: con forecast o live, truck_bans[].active ora viene valutato all'ora in cui si prevede che il camion raggiunga ciascun divieto (da depart_at, oppure da adesso se non lo invii), prima di qualsiasi attesa per quel divieto. Un nuovo campo truck_bans[].active_at indica l'ora valutata, nell'ora locale del paese del divieto. bans_summary, restriction_hits e legal seguono gli stessi verdetti, e un divieto in cui il ritardo previsto fa incorrere di nuovo (ad esempio in un giorno successivo o in un altro paese) è elencato anch'esso in truck_bans. Con traffic=off, active è valutato sulla timeline a flusso libero e active_at è uguale a eta_at_ban.

Nuovo prodotto: Truck Route API (GET /api/v2/data/truck-route, solo v2). Una sola chiamata restituisce un percorso adatto ai camion e tutto ciò che serve a un dispatcher lungo il tragitto. Il percorso è calcolato dallo stesso motore di routing della nostra app di navigazione per camion TruckTurn, sui nostri dati cartografici.

• Veicolo: height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (classi ADR) e adr_tunnel (B–E). I divieti di circolazione per camion e le zone con restrizioni vengono verificati sulla linea restituita.
• Lungo il percorso: stazioni di servizio con prezzi aggiornati, parcheggi per camion e stazioni di pesatura, ciascuno con km_from_start e deviazione.
• Piano di riposo del conducente secondo il Regolamento UE 561/2006: pause (incl. pausa frazionata 15+30), riposo giornaliero e settimanale (incl. ridotto), equipaggio singolo o con due conducenti (crew=2), a partire dallo stato attuale del conducente, se lo si fornisce. Ogni sosta è collocata in un parcheggio reale lungo il percorso. È uno strumento di pianificazione, non una registrazione del tachigrafo.
• ETA che include i riposi, i divieti di circolazione per camion e le attese ai confini. Pianificazione tramite depart_at o arrive_at.
• Stime dei costi di pedaggio per paese (EUR, in base agli assi e alla classe di emissione), con i paesi senza tariffe elencati in tolls.coverage_note. Inoltre avoid (pedaggi, traghetti, autostrade, confini, tunnel, strade non asfaltate, zone a basse emissioni), fino a 2 alternative, una suddivisione per paese e geometry come polyline5, polyline6 o GeoJSON.

Quota: un limite separato per le chiamate truck-route: 10 chiamate al giorno per ogni account, di più con i piani a pagamento, e un componente aggiuntivo Chiamate truck-route extra. Nella sandbox puoi eseguire 10 percorsi per camion al giorno, vedere il risultato sulla mappa con il piano completo del percorso ed esportarlo in GPX, KML, GeoJSON, CSV, calendario (.ics) o ITN. Vedi la pagina del prodotto e la documentazione di riferimento.

Secondo i Termini API, un Market è il paese di cui usi i dati, e la tua chiave copre i paesi approvati per il tuo account. Finora, i prodotti basati su coordinate (lat/lon — es. Nearby Shops, Truck Parkings, Fuel Stations) rispondevano per qualsiasi punto in Europa. Dal 13 ottobre 2026, questo viene verificato al momento dell'elaborazione della richiesta:

• Una richiesta il cui lat/lon si trova in un paese non approvato per il tuo account restituisce 403 con error.code market_not_allowed. Il messaggio indica il paese e il tuo elenco di paesi approvati.
• Quando il raggio attraversa un confine, i risultati il cui country_code è fuori dai tuoi paesi approvati vengono rimossi. La risposta include quindi markets_filtered (quanti sono stati rimossi) e markets_notice, e total_found conta solo ciò che hai ricevuto.

Questo vale per gli account i cui paesi sono stati verificati (stato approved o partial). Nella richiesta non cambia nulla — nessun nuovo parametro, nessuna nuova versione. Se la tua app necessita di un altro paese, aggiungilo nel portale sviluppatori prima del 13 ottobre. market_not_allowed è elencato insieme agli altri codici di errore nel riferimento.

Gli account sviluppatore collegati a un account Nakordoni Partners con la stessa email possono ora inviare notizie e gestire la propria flotta NakBus (NakDriver / NakManager) da partners.nakordoni.eu, con ruoli di team (Owner, Manager, Viewer) e accesso con un clic tra i due portali. Le pagine del portale sviluppatori, le chiavi API, gli endpoint della flotta e le app restano invariati.

In Fuel Prices, updated_at e il flag age_hours/stale della stessa risposta andavano su orologi diversi: updated_at cambia solo quando un prezzo cambia davvero, mentre l'obsolescenza veniva calcolata come se cambiasse a ogni conferma. Il 46.7% dell'indice dei prezzi mostrava age_hours ≤48 e stale:false, mentre updated_at risaliva in realtà a più di 48 ore prima; 12,620 stazioni risalivano a più di una settimana. Ora ogni prezzo include anche confirmed_at — l'ultima volta in cui abbiamo confermato il prezzo, arrotondata per difetto all'ora, mai precedente a updated_at — e age_hours/stale sono calcolati a partire da esso. Il significato di updated_at non cambia: usalo per sapere quando il prezzo è cambiato l'ultima volta, usa confirmed_at per sapere quanto è aggiornato adesso. Non presente nel contratto v1 congelato.

Due bug sulla lingua, entrambi silenziosi: inviando il codice canonico del carburante con lang=pl (o con una qualsiasi delle altre 24 lingue del sito), fuel_type_local tornava comunque in inglese — solo 10 lingue venivano verificate nella tabella delle etichette, quindi tutto ciò che era fuori da quell'elenco ricadeva sul vocabolario predefinito dell'interfaccia invece che nella lingua richiesta. Inoltre, lang=tr (o diversi altri codici validi) restituiva gli elenchi delle stazioni in ucraino, perché un valore predefinito interno uk scattava ogni volta che la lingua richiesta non rientrava nello stesso elenco di 10 lingue. Entrambi sono stati corretti: la lingua che invii è ora la lingua che ricevi, su tutte e 25.

Inoltre: brand in Nearby Fuel Stations non restituisce più il valore sentinella grezzo di acquisizione OTHER per le circa 330 stazioni di cui non conosciamo il marchio — ora è null, coerentemente con ogni altro campo sconosciuto della risposta.

L'assistente AI di frontiera (/api/v1/data/assistant) rispondeva con 503 internal_error — «Assistente temporaneamente non disponibile» — quando la stessa chiave poneva la stessa domanda due volte nell'arco di cinque minuti. Nulla era indisponibile: nella maggior parte di quei casi la risposta era già calcolata e pronta per essere restituita. Ora viene restituita normalmente, con ok: true e HTTP 200.

Quando la ripetizione arriva mentre la prima risposta è ancora in fase di scrittura, la chiamata restituisce ora 429 con error.code pari a duplicate_request invece di un 503, così una politica di retry può distinguere «richiedi tra un momento» da un guasto reale. Entrambi i casi venivano inoltre conteggiati nel tasso di errore del tuo account come errori del server; ora non più. Nella richiesta non cambia nulla — nessun parametro, nessuna versione. duplicate_request è elencato insieme agli altri codici di errore nel riferimento.

Truck Parking (/api/v2/data/truck-parkings) restituiva voci con name pari a null e address vuoto — vicino a Bensheim, 20 su 50. Sono luoghi che conserviamo solo come coordinata, senza nulla da visualizzare e nulla da confrontare con il tuo insieme di POI. Non fanno più parte di questo prodotto: ora vengono servite solo località dotate di nome, attualmente più di 22.000 in tutta Europa. Se filtravi tu stesso le voci senza nome, quel codice ora è ridondante ma innocuo. Le risposte si accorciano a parità di radius e limit e ogni voce restituita è utilizzabile.

Separatamente, circa 10.000 parcheggi riportavano una coppia di coordinate grezza come name, ad esempio 51.927301,10.14112, mentre l'etichetta reale si trovava in address. Ora riportano quell'etichetta — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — ovunque compaiano, incluso /api/v1/data/pois. L'id di ogni luogo è invariato, quindi una mappatura in cache resta valida; cambia solo il name.

snapshot.updated_at su /api/v1/data/queue e /api/v1/data/multi è l'ora locale nel fuso proprio del valico (ad esempio Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv) e finora nulla nella risposta indicava quale fuso fosse, quindi il chiamante non poteva risolverla in un istante preciso. snapshot acquisisce un campo additivo timezone (nome IANA) accanto a updated_at. Nessun parametro, nessuna versione, nessun altro campo cambia.

Finora ogni endpoint carburante descriveva la propria copertura con un elenco scritto a mano: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, con la Polonia ridotta all'area di Trójmiasto. Entrambe le affermazioni erano superate da tempo. La copertura ora è misurata sull'indice vivo delle stazioni e ricalcolata ogni sei ore: 39 paesi hanno oggi stazioni con prezzi, e tra questi la Polonia su tutto il territorio, non in tre città. Nella richiesta non cambia nulla: nessun parametro, nessuna versione.

Nearby Fuel Stations e Cheapest Fuel: quando una ricerca torna vuota, il blocco coverage porta ora valori misurati station_countries, station_counts, sparse_coverage e measured_at, ristretti al tipo di carburante richiesto e non al carburante in generale. Un paese finisce in sparse_coverage quando vi abbiamo 25 stazioni con prezzo o meno — è un conteggio, non un giudizio.

C'è una nota nuova per un tipo che riconosciamo ma che nessuno quota dove avete chiesto. Finora coverage.fuel_type_note compariva solo quando il nome alla pompa ci era sconosciuto. Ora compare anche quando il nome viene risolto correttamente e semplicemente non esiste alcun prezzo per esso in quel paese; indica i paesi in cui quel tipo è quotato e i tipi che quotiamo intorno a voi. Il nome ceco Natural 100 è l'esempio pulito: viene riconosciuto, e nessuna fonte gli dà un prezzo in Cechia. Una risposta vuota smette di sembrare una richiesta rotta.

Fuel Grades (/api/v2/data/fuel-grades) guadagna priced_countries e priced_station_counts per ogni tipo, più priced_here quando passate ?country=. I due elenchi dicono cose diverse: un paese sotto countries è un paese in cui accettiamo quel nome alla pompa, mentre priced_countries indica dove una fonte lo quota davvero, quindi priced_here pari a 0 è una risposta vera e non un buco nella risposta. Il payload porta anche coverage_measured_at e coverage_note, e il suo Cache-Control scende da 24 ore a 6, per seguire la frequenza di ricalcolo.

Vengono risolti anche più nomi locali alla pompa, tra cui Klimadiesel 90 (HVO100) e HVO Diesel, Erdgas e Metano, Autogas e Autogaz, DEF per l'AdBlue, oltre a una serie di nomi commerciali di gasoli e benzine premium. L'ordine di risoluzione è invariato e la corrispondenza resta esatta, quindi nessun nome che funzionava prima oggi significa altro, e un nome nuovo può al massimo trasformare una risposta vuota in una con prezzi. Nello stesso tempo la documentazione di riferimento e le descrizioni degli endpoint sono state corrette in tutte le 25 lingue del sito.

Cheapest Fuel (/api/v2/data/fuel-cheapest) restituiva le stazioni più vicine ordinate per distanza invece che per le più economiche. Poiché la classificazione veniva applicata prima che il risultato fosse troncato al vostro limit, i distributori più economici all'interno del vostro raggio potevano risultare del tutto assenti dalla risposta. La classificazione è di nuovo corretta: prima il più economico per la benzina richiesta, in caso di parità vince il più vicino, e una stazione senza quotazione per quel tipo di carburante viene classificata per ultima. Nella richiesta non cambia nulla — né parametro, né versione.

Anche le risposte carburante v2 sono ora documentate come vengono effettivamente restituite: le stazioni arrivano sotto data.stations[], una voce per ogni stazione fisica, con ogni tipo di carburante annidato nell'oggetto prices (price, currency, local_name, updated_at, age_hours, stale), oltre a station_ref, grades, total_found e notices. Il riferimento per Nearby Fuel Stations e Cheapest Fuel descriveva ancora il vecchio elenco piatto di righe data.data[].

Nella pagina di fatturazione (scheda mensile) sono disponibili due componenti aggiuntivi per qualsiasi piano, senza cambiarlo: Chiamate di previsione extra — +100 chiamate di previsione e statistiche al giorno per blocco, €2 al mese per blocco, fino a 10 blocchi; e Paesi extra — +1 paese dichiarabile per unità, €2 al mese ciascuno. Modificando la quantità viene mostrato un preventivo proporzionale esatto prima di qualsiasi addebito.

Dal 10 novembre 2026 ogni piano include un numero definito di paesi dichiarati: Explorer e Student 4, Starter 10, Pro e superiori illimitati. Da quella data non sarà possibile salvare una dichiarazione più lunga del piano più i paesi extra acquistati; la scheda Account mostra già il tuo limite e gli account che lo superano vedono un suggerimento nella dashboard. Prima del 10 novembre non cambia nulla.

La sandbox API ora contrassegna ogni endpoint nell'elenco con la sua classe di quota (Pesante / Standard), mostra il costo in quota per la versione selezionata prima di eseguire qualsiasi cosa e, dopo una chiamata, mostra quanto la stessa chiamata sarebbe costata sulla tua quota di produzione — inclusa la formula ceil(N ppids × M sub-products / 2) usata per le chiamate in forma /multi.

È un'anteprima di sola lettura: le chiamate della sandbox vengono scalate dal budget di test separato della sandbox, mai dalla tua quota di produzione.

Da oggi, tutto ciò che abbiamo annunciato pubblicamente come in via di ritiro è chiuso agli account sviluppatore creati alla data dell'annuncio o successivamente. Se il tuo account esisteva già prima dell'annuncio, non cambia nulla — mantieni l'intero periodo di transizione, fino alla data di ritiro indicata nella voce che lo ha annunciato.

Perché esiste questa regola. Il 24 agosto 2026 abbiamo annunciato che truck-bans v1 viene ritirato l'8 settembre 2026. Due account registrati pochi giorni dopo quell'annuncio hanno costruito la loro integrazione su v1 e sono arrivati a poche ore da un 410 senza che nessuna nostra email li avesse mai raggiunti: l'annuncio e il ciclo di notifiche erano entrambi anteriori alla loro registrazione. Nulla nell'API ha impedito loro di adottare una versione che avevamo già dichiarato in uscita. È stato un nostro errore, e questa è la correzione: non puoi adottare ex novo qualcosa di cui è già programmata la rimozione.

Come si presenta. Una chiamata di questo tipo viene rifiutata con 410 Gone e codice di errore version_closed_to_new_accounts. Il messaggio indica la data di ritiro, la data dell'annuncio e la versione da usare al suo posto. È deliberatamente un codice diverso da version_sunset, che è quello che riceve ogni account una volta superata la data di ritiro stessa — il supporto può distinguere «sei arrivato troppo tardi per iniziare» da «questo non c'è più per nessuno» senza leggere un log.

Il diritto acquisito si basa sulla data di creazione dell'account, non sulla prima chiamata. Se ti sei registrato prima dell'annuncio ma inizi a integrare solo ora, mantieni comunque l'intero periodo di transizione: potresti averci lavorato fin dall'inizio.

In vigore da ora per truck-bans v1 (annunciato il 24 agosto 2026, ritirato l'8 settembre 2026), e automaticamente per ogni ritiro che annunceremo d'ora in avanti. Non ti viene richiesto nulla di nuovo: ogni risposta su una versione in ritiro porta già gli header Deprecation, Sunset e Link: rel="successor-version", così una nuova integrazione può vedere arrivare un ritiro senza leggere questa pagina.

Seguito della modifica v4 di ieri (ticket sviluppatori #105). Gli elenchi destination separati da virgole in v1 e v2 continuano a funzionare, ma ora seguono la stessa scadenza di destination=all: entrambi si fermano il 2026-10-06 (intestazioni Deprecation/Sunset fino ad allora, poi 400 destination_list_removed, che indica /api/v4/ come sostituto). Il limite esistente di 10 elementi sugli elenchi con virgole resta invariato fino a quella data.

La v4 resta a una sola destinazione per chiamata — questo oggi non è cambiato. È cambiato solo il modo in cui vengono comunicate v1/v2: il 400 di destination=all non suggerisce più un elenco con virgole come percorso di migrazione (morirebbe alla stessa data), ma rimanda direttamente alla v4.

Correzione della documentazione: l'esempio v4 su questo sito riportava in precedenza /api/v4/data/border/1/2,3,4/9 — un elenco con virgole, che la v4 rifiuta. Ora è /api/v4/data/border/1/2/9. Chi ha copiato il vecchio esempio avrebbe ricevuto un 400 alla prima chiamata; ci scusiamo.

Nuova chiave tradotta product_border_v4_p_destination viene rilasciata in tutte le 25 lingue del sito ed enuncia esplicitamente la regola di una sola destinazione in v4 invece di ricadere sulla formulazione di v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} è attivo da oggi. Rispetto alla v2 cambiano tre cose e, insieme, sono il motivo per cui si tratta di una nuova versione e non di una modifica.

1. Niente più destination=all. I nostri dati sono concessi in licenza per paese (Termini dell'API per sviluppatori, sezione 7) e un carattere jolly che si espande a "ogni paese confinante per cui abbiamo dati" restituisce paesi per cui il tuo account potrebbe non essere approvato, senza che nulla nella richiesta lo indichi. Nella v4 sei tu a indicare il paese.

2. Un solo paese di destinazione per chiamata. /api/v4/data/border/1/2/9 richiede un solo confine. Gli elenchi separati da virgola non sono accettati: invia 1/2/9, 1/3/9 e 1/4/9 come chiamate separate. Un elenco separato da virgola oppure all risponde 400 e indica le chiamate esatte da inviare, così nulla fallisce in silenzio.

3. Un solo codice per i camion. La v1 e la v2 dividevano il trasporto merci in 8 (Freight Transport) e 9 (Freight Transport up to 7.5 t). Al valico quella distinzione esiste davvero, ma nessun integratore può agire su di essa: chiedere 9 alla v2 sul confine UA-PL restituiva 21 dei 70 valichi per camion e nulla lo segnalava. La v4 risponde a 9 con tutte le corsie per camion e accetta 8 come alias di 9. Ogni riga porta con sé il proprio crossing_type, quindi una risposta unificata resta ispezionabile.

Nella v1 e nella v2, destination=all continua a funzionare fino al 6 ottobre 2026 e fino ad allora restituisce le intestazioni Deprecation / Sunset. Da quella data anche quelle versioni rispondono 400 per all; il resto della v1 e della v2 non viene toccato e resta disponibile. La stessa data vale per le altre scorciatoie "tutti i paesi": travel-matrix senza ?dest=, bus-carriers con ?ppid=all e fuel-grades senza ?country=.

La v3, annunciata oggi poco prima, è superata dalla v4. La v3 differiva dalla v4 solo perché accettava ancora un elenco separato da virgola, e nessuna integrazione usa quella forma. Gli URL della v3 continuano a rispondere, quindi nulla di quanto scritto per essa si rompe, ma la v3 non è documentata e non verrà sviluppata oltre: migra alla v4.

Tutto il resto della v4 è come nella v2: ordine direzionale del percorso, direction{from,to}, stale e ?max_age_min=.

Gli id numerici in /border/{origin}/{destination}/{crossing_type} non erano mai stati pubblicati sotto forma di tabella, quindi gli integratori li ricostruivano dai fusi orari e dagli URL di esempio. Ora sono nella documentazione, alla voce Codici dei paesi e dei tipi di veicolo, generati dalle stesse tabelle con cui l'API convalida le richieste: gli id dei paesi con i confini a cui ciascuno si espande e ogni crossing_type con l'etichetta restituita dall'API.

Durante la pubblicazione abbiamo scoperto che la sandbox e i metadati dell'endpoint descrivevano 8 come "truck<7.5t" e 9 come "truck". È il contrario: l'API etichetta 8 come Freight Transport e 9 come Freight Transport up to 7.5 tons, ed è sempre stato così. Se hai scelto un codice camion partendo dal suggerimento del parametro, stavi filtrando la corsia opposta a quella che intendevi. Corretto ovunque, e la v3 elimina del tutto la scelta.

I Termini dell'API v1.1 sostituiscono la v1.0 prima che entrasse in vigore e si applicano dal 6 ottobre 2026. Accettali nella tua dashboard.

La sezione 7 ora dice che cos'è un Mercato: il paese di cui usi i dati — quello in cui si trova il valico o il confine che richiedi — non il paese in cui vivono i tuoi utenti. La nostra dashboard affermava entrambe le cose in punti diversi; l'applicazione delle regole ha sempre inteso la prima.

Due modifiche a tuo favore. I paesi già approvati per il tuo account restano utilizzabili mentre una modifica successiva è in revisione (aggiungere un paese non sospende più quelli che hai già). E se non abbiamo risposto a una dichiarazione di mercato entro 5 giorni lavorativi, valgono i limiti pieni del tuo piano finché non lo facciamo.

La sezione 10.3 ora corrisponde a ciò che la dashboard chiede davvero e la sezione 13.2 indica una base di disponibilità che misuriamo e possiamo mostrarti.

Tre prodotti includono ora un campo aggiuntivo data_quality (high oppure low) che indica se una lettura è un'osservazione reale o una stima del modello in assenza di una fonte di conteggio dal vivo a quel valico: queue (nello snapshot di primo livello e su ogni riga storica in data[] — assente nelle righe di previsione), update-info (sull'envelope) e multi (sui sotto-oggetti queue e update_info di ciascun valico). Non è un segnale nuovo — il flag sottostante esisteva già internamente — ma non era mai stato esposto, quindi un valico interamente modellato risultava identico a uno misurato direttamente. is_realtime resta invariato di proposito: continua a valere true per le righe modellate, e cambiarne il significato sarebbe una modifica incompatibile di livello v2 che qui non facciamo.

Sempre da questa release: il prodotto queue-advanced non ridistribuisce più i dati meteo grezzi di origine. weather_main, temperature e wind_speed sono sostituiti da un condition_code derivato (scala di pericolosità 0–5, null quando non ci sono dati meteo disponibili), condition e severity.

Dal 2026-08-30 una richiesta /api/v1/data/multi riceve risposta per un massimo di 5 valichi. Una chiamata che elenca più PPID non viene rifiutata: continua a restituire 200, ma ricevono risposta solo i primi 5 ID in ?ppids=. Gli ID rimanenti vengono ignorati, restituiti in meta.ppid_cap.ignored e non vengono addebitati sulla tua quota — la chiamata è fatturata su ciò che restituisce effettivamente.

Finché una chiamata supera il limite, la risposta include l'intestazione X-Devapi-Warning: multi_ppid_cap e un blocco meta.ppid_cap con cap, enforced_from, enforced, ppids_asked, ppids_answered e ignored[]. Fino al 2026-08-30 questi campi compaiono con enforced: false e con l'insieme completo dei risultati, così puoi vedere il cambiamento in arrivo nei tuoi log.

Lo sconto di metà sulla quota resta invariato. Suddividi i tuoi valichi in gruppi da 5 e invia una chiamata per gruppo nel tuo consueto ciclo di aggiornamento; per interrogazioni frequenti sulla sola lunghezza della coda e sull'aggiornamento dei dati, update-info resta il prodotto di classe standard più economico.

Il divieto ucraino per il caldo, calcolato da noi — restituito con include_ua_heat e automaticamente per country=UA — risponde ora per la finestra di date che chiedi. Prima restituiva i sette giorni successivi qualunque cosa dicessero date_from e date_to, così una finestra di dicembre riportava in silenzio le righe di questa settimana. Il divieto è calcolato dalle previsioni meteo e non letto dal calendario dei divieti, quindi ha due limiti che il calendario non ha: non guarda indietro e finisce dove finiscono le previsioni. La tua finestra viene ora intersecata con ciò che le previsioni coprono davvero, e il nuovo campo ua_heat_ban.forecast_horizon indica l'ultima data raggiunta. Una finestra oltre quell'orizzonte non restituisce righe e spiega il perché in summary — che non equivale a «nessun divieto». Le risposte v1 restano invariate.

La forma della risposta non era documentata da nessuna parte: l'unico modo per sapere cosa restituiva un prodotto era chiamarlo. Ora la pagina di ogni prodotto mostra, sotto la tabella dei parametri, una tabella Campi della risposta con una breve descrizione di ogni campo; i campi degli elementi di una lista compaiono come items[].name, mentre i campi a livello di busta (usage, meta, snapshot, resolved_location) compaiono senza prefisso. Sono documentati 40 prodotti su 42: i due non ancora lanciati (weather, road-quality) restano volutamente senza descrizione. La stessa tabella viene pubblicata nel nostro mirror pubblico della documentazione su GitHub.

Ogni prodotto carburante accetta ora il nome locale di un carburante, non solo la nostra scrittura interna: ON in Polonia, Nafta in Cechia, Gázolaj in Ungheria, Motorină in Romania, ДП in Ucraina, Motorin in Turchia, Gasóleo in Portogallo e Spagna. Il nome è interpretato prima di tutto in base al paese — «95» è E10 a una pompa danese e E5 a una polacca — quindi inviate country insieme al nome locale, oppure coordinate con cui collocare il punto. La risposta restituisce fuel_type (canonico), fuel_type_requested (così come lo avete scritto) e fuel_type_local. Un nome che non riusciamo a collocare non viene mai sostituito con un carburante predefinito: la risposta torna vuota e lo dice.

La tabella completa è ora un prodotto a sé — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — i nostri carburanti canonici e i loro nomi locali in 41 paesi europei, compresi mercati per cui non pubblichiamo prezzi. I livelli paese e regione di fuel e fuel-local hanno inoltre un oggetto grades che collega ogni chiave di prezzo al carburante e al nome usato alla pompa.

Il prodotto truck-bans ora risponde per una data specifica o un intervallo di date su /api/v2/data/truck-bans. Finora restituiva sempre i 7 giorni successivi e ignorava qualsiasi data inviata, quindi per costruire un calendario serviva una richiesta al giorno — e su un piano da due richieste al secondo la maggior parte viene rifiutata con 429 qps_exceeded.

Usa ?date=YYYY-MM-DD per un singolo giorno, oppure ?date_from= e ?date_to= per un intervallo. Entrambi gli estremi sono inclusi e ciascuno può essere omesso: l'inizio vale oggi per impostazione predefinita, la fine vale l'inizio più 7 giorni. Una finestra può coprire al massimo 92 giorni — una più lunga viene rifiutata con 400 date_range_too_long invece di essere tagliata in silenzio. È un calendario rivolto al futuro: una finestra può iniziare al massimo 7 giorni nel passato e le date precedenti vengono rifiutate anziché servite — la copertura si estende in avanti fino al 31 dicembre 2028 su 23 paesi.

Ogni risposta contiene ora un oggetto window che indica esattamente l'intervallo coperto. È un campo aggiuntivo e viene inviato anche in v1, dove la v1 mantiene invariata la sua finestra fissa di 7 giorni. Nota: include_ua_heat copre sempre i 7 giorni successivi, qualunque finestra tu richieda — è calcolato da una previsione meteo, non dal calendario dei divieti. Ricorda che la v1 di questo prodotto viene ritirata l'8 settembre 2026.

Due miglioramenti collegati su tutta l'API: qualsiasi parametro che un prodotto non accetta è ora elencato in ignored_params nella risposta invece di essere scartato in silenzio, e gli errori di validazione del servizio dati ti arrivano così come sono scritti, con il codice leggibile dalle macchine in error.reason.

Tre correzioni sulla qualità delle risposte emerse da un audit del gateway (ticket #43).

L'header X-API-Key è ora accettato oltre a Authorization: Bearer e ?key=. Se il tuo client HTTP invia le chiavi tramite un header chiamato X-API-Key, ora funziona — in precedenza veniva ignorato silenziosamente e la chiamata veniva rifiutata come missing_api_key. Authorization: Bearer resta la forma documentata e consigliata.

Il messaggio di errore per chiave mancante ora indica tutti e tre i modi di autenticarsi (header Bearer, header X-API-Key oppure ?key=) invece di limitarsi a rimandare alla pagina di registrazione.

La directory checkpoints ora include has_day_stats in ogni riga — un booleano aggiuntivo che indica se l'API Best Time to Cross (day-stats) dispone di dati per quel checkpoint. I day-stats esistono solo per un sottoinsieme dei checkpoint monitorati; verifica questo flag prima del polling per evitare 404 prevedibili. I campi esistenti restano invariati.

Corretto anche nella documentazione: il prodotto road-conditions ha sempre rispettato il parametro lang per la localizzazione delle etichette — semplicemente non era elencato.

Due correzioni e una nuova versione per il prodotto truck-bans.

I paesi separati da virgola ora funzionano. ?country= accetta un elenco di massimo 3 codici ISO-2, per esempio ?country=DE,RO. Un elenco più lungo viene rifiutato con 400 too_many_countries anziché troncato silenziosamente — questo è un calendario di divieti per singolo paese, non un feed massivo. In precedenza non funzionava: il separatore veniva rimosso, quindi DE,RO veniva letto come il singolo token DERO, non corrispondeva a nulla e restituiva success: true con total_bans: 0 — un sicuro “nessun divieto” per due paesi che insieme ne avevano 22. Se avevi aggirato il problema inviando una richiesta per ogni paese, ora una sola richiesta le copre tutte e costa una chiamata invece di diverse.

Le risposte ora dichiarano la propria completezza. Tre campi aggiuntivi — returned, total_available e truncated — indicano se una risposta è stata limitata. In particolare una chiamata senza ambito restituisce una porzione limitata e finora nulla nel payload lo segnalava. total_bans mantiene il significato attuale (righe presenti in questa risposta), quindi nulla di ciò che già analizzi cambia.

La v2 è vincolata a un singolo paese. Su /api/v2/data/truck-bans, ?country= è obbligatorio e una richiesta senza ambito viene rifiutata con 400 scope_required — questo prodotto è un calendario di divieti per singolo paese, non un feed massivo. Oggi la v1 resta invariata — accetta ancora una chiamata senza ambito e restituisce ancora le stesse 50 righe limitate di sempre, quindi al momento nulla di ciò che hai in esecuzione si rompe. La v1 di questo prodotto viene ritirata l'8 settembre 2026. Funziona normalmente fino al 7 settembre; dall'8 settembre una richiesta v1 viene rifiutata con 410 Gone e un messaggio che rimanda alla v2. Fino ad allora ogni risposta v1 include Deprecation: true, un header Sunset con quella data e un header Link che indica la versione successiva, così una libreria client può esporre la scadenza senza che nessuno legga questa pagina. Per migrare: cambia il segmento di versione in /api/v2/data/truck-bans e passa ?country=.

Una correzione alla documentazione: il parametro date è stato rimosso. Era elencato da molto tempo ma non veniva mai letto dal servizio, quindi qualsiasi richiesta che lo inviava riceveva silenziosamente la finestra predefinita di 7 giorni invece del giorno richiesto. Per selezionare un giorno, filtra l'array upcoming_bans in base al suo campo date. Inoltre un codice ISO-3 come DEU non viene più risolto in un nome di paese nel riepilogo, dove produceva il fuorviante “No truck ban data for: Germany.”

Il prodotto truck-bans restituisce ora le restrizioni alla circolazione a livello nazionale per altri cinque Paesi: Belgio (BE), Bielorussia (BY), Montenegro (ME), Macedonia del Nord (MK) e Svezia (SE). La copertura esistente di Bulgaria, Grecia e Portogallo è stata estesa e aggiornata — le restrizioni greche arrivano ora a settembre 2027 e il Portogallo è di nuovo popolato.

La struttura della risposta non cambia. Le nuove righe hanno le stesse chiavi di qualsiasi altro divieto: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons e details_url. Quando una restrizione vale solo a una condizione — i divieti estivi bielorussi si applicano ad esempio oltre i 25 °C — tale condizione è indicata in restriction_details: leggi quindi questo campo prima di avvisare un autista. min_weight_tons è null quando una regola riguarda una classe di trasporto (merci pericolose) anziché un tonnellaggio.

I prodotti fuel-stations e fuel-cheapest restituiscono ora prezzi per singola stazione in Polonia. La copertura è parziale — l'area della Tricittà (Danzica, Gdynia, Sopot) — perciò la Polonia è segnalata in un nuovo array additivo coverage.sparse_coverage accanto all'elenco esistente coverage.station_countries. Un Paese elencato in sparse_coverage dispone di dati per stazione solo su una parte del territorio; una query altrove in quel Paese restituisce un elenco vuoto insieme alla nota di copertura, esattamente come prima. I prezzi polacchi sono espressi in PLN.

Anche l'errore per le query massive è più chiaro: quando manca lat, il messaggio scope_required rimanda ora al prodotto fuel (?country=XX) per i prezzi medi nazionali.

GET /api/v2/data/fuel-local?lat=&lon= risolve ora il prezzo su tre livelli anziché due: station, poi region, poi country. Il nuovo livello intermedio esiste per l'Ucraina, dove i prezzi per singola stazione non esistono da nessuna parte: un punto in Ucraina riceve ora la media del proprio oblast invece della media nazionale e ricade sulla media nazionale solo quando per l'oblast non ci sono quotazioni.

Una risposta del livello region contiene il codice dell'oblast (un valore ISO 3166-2 come UA-46), region_name e region_center_dist_km, oltre alle stesse chiavi di prezzo del livello paese. Continua a ramificare il codice su resolution, mai sulla forma della risposta; le risposte station e country restano invariate.

Il nuovo endpoint GET /api/v2/data/fuel-local?lat=&lon= restituisce il miglior prezzo del carburante disponibile per qualsiasi punto in Europa. Dove abbiamo dati per singola stazione risponde con i prezzi delle stazioni più vicine, altrimenti con la media nazionale del paese in cui si trova il punto — Ucraina compresa, dove i prezzi per singola stazione non esistono da nessuna parte.

Ogni risposta contiene il campo resolution, che indica il livello che ha risposto: station (un elenco di stazioni con distance_km, ciascuna nella propria valuta) o country (un oggetto con le medie nazionali). Ramifica il codice su resolution, mai sulla forma della risposta. Disponibile da /api/v2/ in poi; fuel, fuel-stations e fuel-cheapest restano invariati.

I prodotti fuel-stations e fuel-cheapest coprono ora molte più stazioni in Germania, con prezzi aggiornati nell'arco della giornata — comprese le aree rurali. Il parametro fuel_type accetta 13 tipi di carburante: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 e lng. Quando nessuna stazione corrisponde alla query, la risposta include un oggetto coverage con l'elenco dei paesi per cui sono disponibili dati sulle stazioni.

Il parametro radius= è ora accettato come alias compatibile di radius_km in tutti i prodotti che lo documentano. I prodotti fuel-stations e fuel-cheapest restituiscono un oggetto additivo coverage (elenco dei paesi con stazioni più una nota) invece di un risultato vuoto senza spiegazioni quando nessuna stazione corrisponde. Gli oggetti valico di route-plan includono ora la chiave additiva wait_basis (car_lane oppure vehicle_lane), così i client sanno quando i tempi di attesa per i camion provengono in realtà dalla corsia auto. L'abbinamento dei valichi per camion lungo un itinerario è nettamente più preciso: ripiego sulla corsia auto per le coppie di valichi senza dati sulla corsia merci, un controllo contro la direzione errata, una soglia di distanza più stringente e la deduplicazione dei valichi nella stessa posizione. Tutte le modifiche sono additive, nessuna modifica incompatibile.

La landing page per sviluppatori ora dispone di sezioni con ancore (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) con navigazione rapida, e ogni scheda prodotto rimanda alla propria pagina di documentazione. La nuova sezione Mobile apps presenta Kordon Online e Truck Bans con link a Google Play. Completamento traduzioni: cronologia fatturazione, errori di accesso, link sandbox e il pulsante di selezione del piano sono ora localizzati in tutte le 25 lingue.

La risposta del beacon della flotta (POST /api/v1/fleet_position.php) ora include un array messages che consegna i messaggi in attesa dal proprietario all'autista. Nuovo feed JSON live riservato al proprietario (?ajax=live) e una scheda "Messaggi agli autisti" nella dashboard della flotta. Nuova pagina di invito autista /{lang}/get-nakbus (25 lingue).

Localizzati titolo, descrizione e parametri di product_fleet_vehicles/live/history, nonché i parametri della cronologia flotta, in tutte le 25 lingue del portale sviluppatori.

/api/v1/data/truck-bans ora restituisce lo stesso set di campi di primo livello indipendentemente dalla query che ha generato la risposta. In precedenza, una query per un paese senza divieti calendariali, un ppid non riconosciuto o una normale corrispondenza nel database potevano omettere campi diversi (ad es. country, covered_countries, ppid). Ora ogni risposta include costantemente 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 e upcoming_bans (null o vuoto dove non applicabile), semplificando il parsing lato client.

Nove nuovi prodotti per singolo servizio. Quelli basati sulla posizione accettano lat/lon oppure city + country (geocodifichiamo noi la città per te): /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 (stazioni classificate per prezzo per un tipo di carburante) e /api/v2/data/internet-points; i risultati includono distance_km e sono limitati da radius. /api/v2/data/vignettes risponde se un paese richiede una vignetta, con prezzi attuali. Il prodotto esistente pois ora supporta lon e radius come documentato, e la modalità mode=nearest del prodotto fuel accetta anch'essa lon. Tutti e nove sono disponibili nel sandbox.

Ogni divieto in /api/v1/data/truck-bans ora include restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (ambito esatto o strade interessate) e min_weight_tons. details_url ora punta alle pagine per paese su nakordoni.eu. Un nuovo parametro facoltativo lang seleziona la lingua dei nomi dei paesi e del riepilogo; la lingua predefinita è ora l'inglese.

Un ?ppid= non valido ora restituisce il motivo reale invece di un laconico "Request failed": l'errore indica il parametro, il formato atteso id_<number> e rimanda a /api/v1/data/checkpoints. Le tabelle dei parametri di stats, forecast, update-info, weather e bus-carriers ora mostrano l'esempio id_13 in tutte e 25 le lingue.

La nuova interfaccia del portale (barra superiore, barra laterale con icone, dashboard KPI, layout a schede) è ora l'esperienza predefinita per tutti gli account sviluppatore autenticati — in anticipo rispetto al rilascio previsto per il 10 agosto. Usa ?v=1 per tornare in qualsiasi momento al layout classico.

Tutte le pagine del portale sviluppatori — home, documentazione, dashboard, AI Studio, sandbox, ticket, richieste, esportazione, flotta, notizie, changelog e pagine dell'account — non caricano più alcuno script né spazio pubblicitario. Vale per l'intero portale, non solo per accesso e registrazione come prima.

Pianifica l'intero viaggio di frontiera con una sola chiamata: /api/v2/data/route-plan restituisce il percorso, i valichi che vi si trovano davvero con la coda in tempo reale o una previsione per l'ora del tuo arrivo, e le soste che un conducente fa realmente — riposo, pasto, rifornimento — su un'unica linea temporale.

Il confine fa parte di quella linea. Una coda lunga vale come la pausa già dovuta e azzera il tempo di guida, quindi tre ore di attesa non vengono mai presentate come tre ore più una serie completa di pause che nessuno ha fatto. Le auto seguono un modello di guida sicura; autobus e camion ricevono il riposo obbligatorio UE 561/2006 e il tempo di servizio degli autobus è calibrato su oltre 1000 orari internazionali autorizzati. Aggiungi stop_places=1 per dare a ogni sosta una vera area di servizio o stazione di rifornimento, e via=lat,lon per passare da un altro valico.

Novità nel menu del portale: Presentazione — una presentazione viva e sempre aggiornata della piattaforma dati nakordoni, personalizzata per il tuo mercato (assicurazioni, viaggi, logistica, vettori, media, navigazione, carburanti, fintech, settore pubblico o progetti personali). Mostra i volumi reali della piattaforma a 30 giorni, il tuo consumo di API, le statistiche sui tempi di risposta e sui limiti e un consiglio sul piano quando le tue chiamate raggiungono i limiti del livello gratuito. Scegli o conferma il tuo mercato (o i tuoi mercati) nella pagina, nel profilo — oppure in fase di registrazione. Si apre automaticamente alla prima visita; l'apertura automatica si può disattivare dalla pagina stessa.

Se un assistente ha un feed attivo ma la chiamata non porta con sé il contesto di cui quel feed ha bisogno — ad esempio queue senza ppid— il feed viene ora saltato prima di qualsiasi richiesta e non viene addebitato. Prima veniva comunque chiamato, falliva e costava lo stesso un'unità. Lo studio mostra ciò di cui ogni feed ha bisogno, ricalcola il prezzo man mano che compili il contesto e contrassegna i risultati come ✓ eseguito / ⊘ saltato, non addebitato / ✕ fallito; l'API restituisce data.feeds_skipped , che indica esattamente quale parametro passare.

Le risposte non menzionano più feed, fonti dati o alcunché di tecnico: un feed mancante è al massimo una frase semplice per l'utente finale, mai un nome interno. I feed con soli filtri facoltativi (come fuel ristretto a un Paese per cui non abbiamo dati) ora ricadono sull'insieme di dati ampio invece di non restituire nulla.

Novità: /{lang}/developers/studio. Crea un assistente IA che risponde a partire dai tuoi contenuti e dai nostri dati di frontiera in tempo reale. Dacci il tuo markdown, oppure indica semplicemente le pagine e le recuperiamo e indicizziamo noi — tu mantieni solo i tuoi file. Scegli quali dei nostri feed può usare (coda, previsione, alternative, statistiche giornaliere, carburante, divieti per i camion, domeniche di apertura, festività, condizioni stradali, vettori di autobus, POI, valuta), scegli un livello di modello (veloce / bilanciato / pro — è questo a stabilire il prezzo), scrivi le tue istruzioni con i segnaposto {{feed.slug}} che indicano esattamente dove finiscono i nostri dati nella risposta, e aggiungi una frase di chiusura tua, accodata a ogni risposta. Modelli pronti: assistente di viaggio personale, assistente lavoro/trasporti, assistente per la vendita di assicurazioni e Carta Verde.

Provalo nello studio (30 risposte al giorno, separate dalla tua quota API), poi chiamalo in produzione su GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Prezzo per risposta = unità del livello di modello + 1 unità per ogni feed attivo, restituito in X-Devapi-Units. Il prodotto è solo v2 — un URL v1 restituisce unsupported_version. Il prodotto esistente assistant resta invariato.

Ogni assistente opera sotto una policy sui contenuti della piattaforma che prevale sulle tue istruzioni: nessuna impersonificazione di pubblici ufficiali, nessun aiuto per eludere i controlli di frontiera o doganali, nessun numero inventato, nessuna volgarità. Vengono controllate sia le istruzioni sia le risposte; le chiamate bloccate vengono registrate.

Novità: un vero server MCP all'indirizzo https://nakordoni.eu/mcp, che espone un sottoinsieme sicuro, di sola lettura, dell'API (status, checkpoints, border queue, live queue, forecast) come strumenti MCP. Stessa chiave API e stessa quota dell'API REST. Scheda del server all'indirizzo /.well-known/mcp/server-card.json. Vedi la sezione Server MCP nella documentazione.

La rinomina in «Live Queue & Freshness API» descritta qui sotto non era in realtà arrivata alla pagina della documentazione . La pagina mostra il titolo di ogni prodotto tramite una ricerca di traduzione che ricade sul titolo dell'endpoint solo quando non esiste una traduzione — e una traduzione esisteva già, congelata sul vecchio nome, in tutte e 25 le lingue dell'interfaccia. Ora ha la precedenza su qualsiasi futuro aggiornamento del titolo sottostante, finché non viene aggiornata anch'essa.

La chiave di traduzione è stata rinominata in tutte e 25 le lingue, così la pagina della documentazione corrisponde. Nessuna modifica a endpoint, parametri o risposta — solo il testo del titolo.

Se interroghi spesso i dati della coda in tempo reale, potresti consumare quota pesante senza necessità. /update-info è di classe standard e restituisce già il valore in tempo reale:

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

Restituisce queue_now, freshness, age_minutes, is_realtime, status, timestamp e timezone. Usalo per l'aggiornamento frequente a carico della tua quota giornaliera standard e tieni /queue, /multi e /forecast (tutti di classe pesante) per quando ti servono wait_min, i campi di tendenza o lo storico.

Nell'endpoint non è cambiato nulla — solo nella sua documentazione. Era elencato come «Data Freshness API» e la descrizione citava solo l'indice di freschezza, mai queue_now, quindi era facile non notarlo. Ora si chiama «Live Queue & Freshness API», con i campi restituiti elencati esplicitamente. Grazie allo sviluppatore che l'ha segnalato.

Alcune richieste fallite restituivano HTTP 200 con ok: true e l'errore sepolto dentro data — così il pattern documentato if (!ok) throw non poteva rilevarle, e la chiamata veniva comunque addebitata. Le chiamate interessate restituiscono ora HTTP 400 con ok: false e un error.code / error.messagecorretto, come da documentazione. Osservato su fuel-cities con un Paese non supportato e su travel-matrix con coordinate malformate.

A parte questo, un parametro obbligatorio mancante restituiva 500 internal_error invece di 400 bad_request (il corpo di una risposta 4xx del servizio interno veniva scartato prima di leggerne lo stato). Ora restituisce 400 bad_request con il messaggio del servizio interno — ad esempio search senza ?name=.

Le risposte riuscite sono invariate byte per byte — stessi campi, stessi parametri, stesso costo in quota. Se il tuo client si dirama già su ok, non serve alcuna modifica. Se ignorava ok e leggeva data direttamente, ora vedrà buste di errore sulle chiamate che comunque fallivano da sempre.

Corretto un bug per cui /multi poteva restituire un conteggio della coda errato per alcuni valichi — soprattutto balcanici e al confine Ungheria–Serbia — ogni volta che la sua cache era fredda. Il ripiego leggeva una tabella che, per quei valichi, non contiene dati di coda, e riportava valori estranei come numero di auto. Esempi misurati: un valico con 12 auto ne riportava 6 e diversi con code reali riportavano 0.

Tre cambiamenti che potresti notare:

• found: false significa ora che davvero non ci sono dati di coda recenti. Prima potevi ricevere found: true con un queue_now: 0inventato.
• wait_status, trend_percent e trend_direction vengono ora restituiti anche sulle richieste a freddo — prima erano null .
• L'endpoint ricade sul ripiego anche quando la sua istantanea in cache è obsoleta (più vecchia di 24 h), non solo quando manca.

Nessuna modifica ai parametri della richiesta, al costo in quota o alla struttura della risposta.

Corretto un bug per cui ogni chiamata a /multi veniva addebitata due volte — una volta da un controllo generico da 1 unità e una seconda volta dalla formula di costo variabile dell'endpoint (N PPID × sotto-prodotti). Ora una chiamata costa esattamente ⌈(N×M)/2⌉ unità come documentato, senza addebiti aggiuntivi.

È stato inoltre aggiunto un badge di classe quota (Standard/Heavy) su ogni prodotto nella pagina della documentazione, così da capire subito quale quota giornaliera utilizza un endpoint.

country e countries uniti in un unico parametro (1-15 codici separati da virgole). Nuovo parametro compare_to: confronto tra giorni festivi uguali o diversi tra i paesi, si combina con upcoming+days. lang ora accetta più lingue (aggiunge un oggetto names). days=0 o omesso ora significa nessun limite in modalità upcoming.

Giorni festivi ufficiali per ogni paese europeo — date, nomi locali e tipo. Basato sullo stesso servizio Nager.Date / OpenHolidaysAPI (con un calendario del Kosovo calcolato localmente) che alimenta la pagina del calendario dei giorni festivi di nakordoni.eu e i fattori calendariali del sistema di previsione.

• ?country=PL&year=2026 — elenco dei giorni festivi dell'intero anno per un paese
• ?upcoming=1&days=30 — elenco semplice dei prossimi giorni festivi tra i paesi
• Senza parametri — indice di un insieme di paesi principali con il prossimo giorno festivo di ciascuno

Aggiunto il prodotto currency — tassi di cambio basati sull'EUR per PLN, CZK, HUF, USD, GBP, CHF, NOK e UAH, forniti da Frankfurter (ECB) e memorizzati in cache per 6 ore. Nessun parametro, restituisce sempre la tabella completa dei tassi. Vedi la documentazione.

Integra i divieti di circolazione dei camion in Europa in tempo reale sul tuo sito web — un widget iframe gratuito con 3 design (light, dark, board), 5 lingue (en, uk, pl, de, ru), un filtro opzionale per paese e uno stato «attivo ora» in tempo reale. Nessuna chiave API necessaria. Configura e copia il codice su nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Preferisci i dati grezzi? Il prodotto API truck-bans e il feed JSON pubblico restano disponibili.

Tre aggiunte, tutte retrocompatibili — v1 è invariata.

Versionamento per endpoint. Ora esiste un URL di base /api/v2/. È per endpoint: solo gli endpoint che sono effettivamente cambiati si comportano diversamente in v2; ogni altro endpoint serve in modo trasparente la sua risposta v1 (quindi /api/v2/data/queue = gli stessi dati di v1, solo con "api_version":"v2"). Non è necessario migrare gli endpoint che funzionano.

border v2 è direzionale. L'ordine del percorso è la direzione di viaggio:

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)

Ogni checkpoint ottiene inoltre un oggetto direction {from,to} e un booleano stale, e ?max_age_min=N restituisce solo i passaggi aggiornati di recente. (In v1 border restituisce comunque entrambi i lati del confine indipendentemente dall'ordine — invariato.)

Sandbox interattivo. Gli sviluppatori autenticati possono ora provare qualsiasi endpoint dal browser su Sviluppatori → Sandbox — scegli un endpoint, una versione e una delle tue chiavi, modifica i parametri e vedi la risposta in tempo reale. I test nel Sandbox hanno un proprio budget giornaliero separato (50 chiamate/giorno) e non intaccano mai la tua quota API reale.

La documentazione è ora suddivisa per endpoint (Sviluppatori → Documentazione API) con un selettore di versione sugli endpoint che ne hanno più di una.

Due nuovi fattori integrati nella formula del tempo di attesa, oltre agli aggiustamenti esistenti section_mode e meteo:

• service_rate — auto/min attualmente in elaborazione, misurate rispetto alla velocità di riferimento configurata del checkpoint. Moltiplicativo, limitato tra 0.5x e 1.5x.
• shift_change — impatto del cambio turno delle guardie di frontiera alle 08:00/20:00, proprio di ciascun checkpoint. Additivo (minuti), non moltiplicativo — applicato solo entro +/-60 minuti da un cambio turno, richiede una cronologia minima di campioni, limitato a +/-120 minuti.

advanced_wait_min è ora round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Entrambi i fattori si riflettono anche in driver_reported.prognosed_advanced_wait_min per i confronti storici.

Nell'ambito di una revisione di sicurezza e privacy, i seguenti campi sono stati rimossi — esponevano dettagli implementativi interni (la tassonomia delle nostre fonti dati a monte, gli ID delle righe del DB, annotazioni interne della pipeline, campi inutilizzati o morti) senza reale valore per il prodotto:

• id e corrected — rimossi dagli oggetti riga di queue
• source (stringa grezza, ad es. "line") — rimosso da queue, multi e update-info. Il blocco update_info di update-info e di multi mantiene comunque source_category/source_label_en (un piccolo vocabolario pubblico); il blocco queue di queue e di multi non contiene più alcun campo source
• traffic_status — rimosso da border; era sempre null e non veniva mai popolato da nessuna parte del sistema

Se la tua integrazione legge uno di questi campi, aggiornala — consulta l'elenco attuale dei campi nella pagina di documentazione del prodotto pertinente.

L'utilizzo della quota giornaliera (usage.used in ogni risposta) ora può essere un valore decimale (ad es. 67.5) invece di essere sempre un numero intero. Si tratta di un effetto collaterale della fatturazione di queue-advanced a una tariffa frazionaria — vedi sotto. usage.limit non è interessato ed è sempre un numero intero. Se il tuo client tipizza rigorosamente usage.used come intero, allargalo per accettare un decimale / float.

Questi tre prodotti ora restituiscono gli stessi campi di stato in tempo reale mostrati dal sito web: wait_status (green/yellow/red, basato sulla cronologia recente di questo checkpoint) e trend_percent/trend_direction (up/up-slight/down/down-slight/stable, confrontando le ultime 3 ore). Puramente additivo.

Le righe data[] di /api/v1/data/queue avevano in precedenza wait_time: null per la maggior parte delle fonti — solo alcuni feed a monte riportano direttamente un tempo di attesa. Le righe che non ne hanno uno ora ricevono la stima standard , contrassegnata da un nuovo booleano wait_time_estimated così puoi distinguere un valore realmente riportato da uno calcolato.

queue-advanced ora costa 1.5 units per chiamata invece di 1 (a riflettere le ulteriori ricerche di traffico, meteo e segnalazioni dei conducenti che effettua) — vedi usage.used sopra. La risposta inoltre non include più total_crossing_time, e driver_reported ora è solo {wait_min, ts, age_min} — i precedenti campi di confronto previsione/realtà (prognosed_wait_min, diff_min, historical_section_mode, historical_weather, ecc.) sono stati rimossi. section_mode, weather, advanced_wait_min ed exceeds_crossing_time sono invariati.

/api/v1/data/truck-bans ora restituisce, per ogni paese in bans_by_country, uno status (active/clear) più active_window, next_window, local_time e tz — calcolati nel fuso orario proprio di quel paese, così non devi più valutare tu stesso le finestre di divieto grezze rispetto a un orologio. La risposta aggiunge inoltre una lista covered_countries di livello superiore e un timestamp UTC as_of.

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

Puramente additivo — i campi esistenti current_bans/upcoming_bans/bans_by_country sono invariati. Un ?country= sconosciuto ora restituisce un risultato vuoto con countries_not_covered invece dei divieti di ogni paese.

Un nuovo prodotto opzionale che regola il tempo di attesa standard in base al flusso di traffico in tempo reale e al meteo. Restituisce il dettaglio completo di ogni aggiustamento.

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

Concesso su richiesta — apri un ticket Data dalla tua dashboard per attivarlo.

/api/v1/data/border ora calcola correttamente wait_min per ogni checkpoint nella risposta, in linea con i prodotti queue e multi. In precedenza questo campo era sempre null.

/api/v1/data/forecast ora utilizza in modo affidabile il modello ensemble v4 per qualsiasi valore di prediction_steps (in precedenza alcuni orizzonti non standard potevano ricadere silenziosamente su un modello più vecchio). Anche il fattore meteo che alimenta l'ensemble è stato corretto e ora riflette realmente le condizioni in tempo reale (pioggia, neve, vento, nebbia) invece di segnalare sempre non disponibile.

Gli sviluppatori approvati possono ora scaricare i dati storici delle code alle frontiere, mediati su base oraria, per un massimo di 5 checkpoint (finestra mobile fino a 90 giorni) in formato CSV o NDJSON dalla nuova scheda Data export. I dati sono solo pubblicati e verificati nella qualità; i timestamp sono in UTC. Ti serve l'accesso? Apri un ticket Data.

Non hai ancora un sito web? Ora puoi creare un account sviluppatore descrivendo dove e come intendi utilizzare i nostri dati, invece di essere obbligato a inserire l'URL di una pagina online. Aggiungi l'URL reale in seguito dalla tua dashboard (Account & dati → Il tuo progetto) non appena il tuo sito o la tua app è online — un link visibile verso nakordoni.eu su quella pagina è richiesto dai nostri Termini.

Gli sviluppatori possono ora inviare le proprie notizie legate alle frontiere al feed di notizie di Nakordoni. Se i nostri redattori la pubblicano, ottieni un backlink dofollow indicizzabile verso il tuo servizio (firma dell'editore + riga della fonte) e traduciamo l'articolo in tutte le 24 lingue gratuitamente.

Un articolo a settimana è gratuito; gli articoli aggiuntivi sono un componente a pagamento. Scegli 'possiamo modificare leggermente + aggiungere link interni' oppure 'pubblica così com'è'. Invia e monitora lo stato di revisione in Sviluppatori → Invia notizia.

La Multi-Checkpoint API (/api/v1/data/multi) ora fattura la quota a ⌈(N PPIDs × sotto-prodotti) / 2⌉ — metà del costo di chiamate individuali equivalenti. Una richiesta per 10 checkpoint con entrambi i sotto-prodotti ora costa 10 units invece di 20. L'header X-Devapi-Units e meta.units_consumed nella risposta riflettono l'importo scontato.

Recupera lo stato delle code in tempo reale e la freschezza dei dati per un massimo di 20 checkpoint in un'unica chiamata API — pensato per chi crea dashboard e che attualmente interroga molti PPIDs in un loop.

La quota viene conteggiata in modo equo come N PPIDs × sotto-prodotti richiesti, quindi l'utilizzo totale è identico a quello delle chiamate individuali — ma con un solo round-trip invece di molti. Gli schemi in stile GreenTravel passano da oltre 24 chiamate/ora a 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 attuale, wait_min stimato, età dei dati e nome del checkpoint
• include=update-info — freschezza dei dati, classificazione della fonte, età in secondi/minuti
• Massimo 20 PPIDs per richiesta; combina entrambi i sotto-prodotti in un'unica chiamata per ottenere tutti i dati della dashboard
• La risposta include meta.units_consumed così puoi monitorare con precisione l'utilizzo della quota

La risposta del prodotto queue ora include un oggetto snapshot di livello superiore con i dati in tempo reale più recenti e un tempo di attesa previsto e calcolato — la stessa formula usata nella sezione hero di 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

L'array data (voci storiche) è invariato — si tratta di un'aggiunta puramente additiva. I client che non leggono snapshot non sono interessati.

Interroga tutti i checkpoint su una determinata frontiera + tipo di veicolo in un'unica chiamata invece di fare una richiesta per ogni PPID.

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

• Supporta un singolo paese di destinazione, un elenco separato da virgole, oppure all per estenderlo a tutti i vicini monitorati in una volta.
• Risultati ordinati per queue_now crescente (la coda più corta per prima).
• Completamente localizzato: aggiungi ?lang=uk (o una delle nostre 22 lingue supportate) per ottenere i nomi dei checkpoint in quella lingua.

Scopri i valori PPID dei checkpoint per nome senza sfogliare l'intera directory.

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

• Accetta un singolo nome o un elenco separato da virgole (fino a 20).
• Cerca in tutte le 24 lingue di traduzione — inserisci un nome in ucraino, polacco, tedesco o qualsiasi lingua supportata e verrà trovato.
• Restituisce tutti i PPIDs di quella località raggruppati per tipo di veicolo (auto / bus / pedone / camion).

Il prodotto alternatives ora accetta ?lang= in tutte le 22 lingue supportate (prima erano solo 12).

Il nuovo parametro crossing_type ti permette di sovrascrivere il filtro del tipo di veicolo — ad es. passa crossing_type=4 per ottenere alternative per auto anche interrogando da un PPID bus.

Il campo crossing_type_label nelle risposte di checkpoints, border e search è ora tradotto nella lingua richiesta, in tutte le 22 lingue supportate. I campi del nome del paese (origin_name, destination_name) seguono la stessa locale.

Il portale API per sviluppatori di Nakordoni è online all'indirizzo /en/developers. Registrati per una chiave Explorer gratuita (200 richieste/giorno) per accedere ai dati sulle code alle frontiere, alle previsioni, ai prezzi dei carburanti, ai POIs per i conducenti e altro ancora.

Prodotti disponibili al lancio: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.