Note di rilascio API

On Fuel Prices, updated_at and the response's own age_hours/stale flag were running on different clocks: updated_at moves only when a price actually changes, but staleness was computed as if it moved on every confirmation. 46.7% of the priced index showed age_hours ≤48 and stale:false while updated_at was in fact more than 48 hours old, 12,620 stations over a week old. Each price now also carries confirmed_at — the last time we confirmed the price, hour-floored, never earlier than updated_at — and age_hours/stale are computed from it. updated_at's meaning is unchanged: use it when you want to know when the price last moved, use confirmed_at when you want to know how current it is right now. Not present on the frozen v1 contract.

Two language bugs, both silent: sending the canonical grade code as lang=pl (or any of the other 24 site languages) got fuel_type_local back in English regardless — only 10 languages were ever checked against the label table, so anything outside that list fell through to the default UI vocabulary rather than the language you asked for. Separately, lang=tr (or several other valid codes) answered station listings in Ukrainian, because an internal default of uk fired whenever the requested language did not sit in that same 10-language list. Both are fixed: the language you send is now the language you get, across all 25.

Also: brand on Nearby Fuel Stations no longer returns the raw ingest sentinel OTHER for the ~330 stations where we do not know the brand — it is null, consistent with every other unknown field in the response.

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