Journal des modifications de l'API

Nouveau produit lane-cost-index (GET /api/v2/data/lane-cost-index). Il renvoie l'indice de coût d'un trajet en charge d'un poids lourd de A à B en Europe : carburant, péages, temps du conducteur et frais de déplacement.

• Entrée: from et to en "lat,lng" ou identifiant de ville, vehicle (par exemple artic_40t), en option euro, co2_class et empty_return.
• Par pays: km, péage, litres de gazole et coût du carburant (hors TVA), et la classe de véhicule tarifée pour le péage.
• Temps du conducteur: conduite, pauses et repos suivent les règles UE 561/2006. Le coût conducteur et les frais de déplacement utilisent le taux du pays d'origine. L'Espagne et l'Italie ont maintenant un taux conducteur et des frais de déplacement issus des conventions collectives.
• Tendance: trend donne l'indice de coût du mois en cours et des deux mois précédents.
• Données incomplètes: quand un pays du trajet n'a pas de données de péage ou de carburant, ou que le pays d'origine n'a pas de taux conducteur, incomplete vaut true et le total est une borne basse. missing_countries et missing_components indiquent ce qui manque.

C'est un indice de coût, pas un prix de transport : capital du véhicule, assurance, frais généraux et marge ne sont pas inclus.

Quota : une requête compte pour 1 unité de la classe route, comme truck-route.

Documentation: Lane Cost Index.

Le produit toll-cost calcule plus précisément la France, l'Espagne et l'Italie.

• France et Espagne: un tronçon d'autoroute entre deux gares de péage de l'itinéraire est calculé avec le tarif entrée/sortie de la société d'autoroute. Il apparaît comme un nouveau type d'élément motorway_section avec la société ou la route, les deux gares, toll_km et cost_eur. Les autres km à péage du pays utilisent toujours la moyenne par km.
• Classe du véhicule: France : classe 3 pour 2 essieux et classe 4 pour 3 essieux ou plus. Espagne : Pesados 1 pour 2 ou 3 essieux et Pesados 2 pour 4 essieux ou plus.
• Italie: les camions à 2 et 3 essieux ont maintenant leurs propres tarifs au km.
• Classe Euro et CO2: les tarifs français, italiens et espagnols ne dépendent pas de ces classes. Si vous envoyez euro ou co2_class, class_fallback vaut false pour ces pays et class_note en donne la raison.
• Pas de route à péage: un itinéraire en Espagne sans route à péage (par exemple Saragosse – Barcelone) renvoie l'Espagne avec cost_eur 0 et scheme not_tolled.

Les autres pays ne changent pas. Documentation : Truck Toll Cost.

Nouveau produit toll-cost (POST /api/v2/data/toll-cost, corps JSON). Il renvoie le coût des péages poids lourd d'un itinéraire en Europe.

• Entrée : la ligne de l'itinéraire en coordinates (par exemple la géométrie de truck-route), ou des waypoints que nous calculons avec notre routage poids lourd.
• Véhicule : axles, gross_weight_t, euro et co2_class. En option date pour les tarifs et currency pour le total.
• Par pays : km à péage, taux effectif en EUR par km, coût, classe de véhicule tarifée et date du tarif. Les taux propres à une classe Euro et CO2 sont utilisés lorsqu'un tarif officiel existe pour cette classe. Sinon, le taux de la classe par défaut est utilisé et class_fallback vaut true.
• Postes séparés : sections autoroutières en concession, ainsi que tunnels et ponts avec leur propre péage poids lourd (par exemple Calafat-Vidin).

Quota : une requête compte pour 1 unité de la classe route, comme truck-route.

Documentation : Truck Toll Cost.

Deux nouveaux produits dans /api/v2. Pour un trajet en autocar, ils indiquent quel côté est au soleil ou à l'ombre et quelles places sont les meilleures pour l'ombre ou pour la vue.

• bus-sun-side (/api/v2/data/bus-sun-side), GET : un itinéraire de notre registre de lignes de bus (route_id, dir, date) ou un trajet libre (from, to, depart).
• bus-sun-side, POST : envoyez votre propre itinéraire sous forme de liste d'arrêts, de ligne GeoJSON ou de polyligne encodée. Ajoutez les paramètres du car (rangées, disposition des sièges, côté des portes, vitres, étage) ou choisissez un modèle du catalogue avec bus_model.
• Météo : pour les trajets dans les 3 prochains jours, la prévision horaire le long de l'itinéraire est utilisée. Les trajets plus lointains sont calculés pour un ciel clair. Envoyez weather=0 pour toujours obtenir le résultat par ciel clair.
• Images (POST) : plan des sièges, carte de l'itinéraire et chronologie sous forme d'URL en PNG, WebP ou JPG. Les images sont conservées 12 heures. Vous recevez aussi embed_html pour afficher le résultat sur votre page. Les URL des images commencent par https://api.nakordoni.dev/images/.
• Animation : le bloc animation contient une image toutes les 5 minutes avec la position du car, le cap, l'azimut et la hauteur du soleil et le côté ensoleillé, avec des libellés dans votre langue, des totaux par côté et une légende. Envoyez animation=0 pour l'omettre.
• Widget : affichez le résultat sur n'importe quel site, WordPress compris, avec une balise script ou un iframe. Le widget utilise une clé publique qui ne fonctionne que sur les origines que vous autorisez, et nos propres tuiles de carte. Un plugin WordPress (zip) est disponible.
• bus-sun-catalog (/api/v2/data/bus-sun-catalog) : les modèles de car acceptés par bus-sun-side, avec la disposition des sièges et les vitres.

Quota : une requête POST avec images compte pour 2 unités. Toutes les autres requêtes comptent pour 1 unité.

Docs: Bus Sun Side.

fleet-compliance-validate couvre désormais une plus grande partie du règlement EU 561/2006 tel que modifié par le règlement (UE) 2020/1054. Les champs de réponse existants ne changent pas ; de nouveaux champs sont ajoutés.

• Exception de l'Art. 12 : marquez les activités de conduite avec art12_exceed: true. Dans des cas exceptionnels, un conducteur peut dépasser les limites de conduite quotidiennes et hebdomadaires de 1 h au maximum pour rejoindre le centre d'exploitation ou son domicile afin d'y prendre un repos hebdomadaire, ou de 2 h au maximum après une pause de 30 min lorsqu'un repos hebdomadaire normal suit. Le validateur l'accepte et renvoie la compensation due ainsi que son échéance (la fin de la troisième semaine suivante) dans remaining.driving.art12_compensation et exceptions.art12.
• Retour à la base, Art. 8(8a) : envoyez location (residence, operational_centre ou elsewhere) pour les repos hebdomadaires. Vous recevez un avertissement lorsque 4 semaines consécutives se passent sans repos hebdomadaire normal au domicile ou au centre d'exploitation.
• Dérogation de 12 jours, Art. 8(6a) : passenger_12day: true pour un service international occasionnel unique de transport de voyageurs en autocar. Le repos hebdomadaire peut alors intervenir jusqu'à douze périodes de 24 heures après un repos hebdomadaire normal. Les repos qui suivent et la conduite de nuit (22:00-06:00) sont vérifiés. L'AETR Art. 8(6)(b) est appliqué de la même manière.
• Plages de nuit nationales (directive 2002/15/CE Art. 3(h)) : utilisez country ou wtd.country pour appliquer la période de nuit nationale. Vérifiés : AT, IE (voyageurs séparément) et SE. Les autres pays de l'UE/EEE utilisent 00:00-04:00 et renvoient night_window_verified: false.
• fleet-compliance-limits : l'AETR liste désormais les amendements postérieurs à 2010 qui ont été vérifiés. Ils ne modifient que l'article 14, pas les règles de conduite ou de repos.

Documentation : Fleet Compliance.

Quatre nouveaux produits, servis depuis /api/v2 et calculés par notre propre moteur de règles de jours fériés pour 51 pays (Europe et Golfe : SA, AE, QA, KW, BH, OM), 2020-2035 :

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — jours fériés nationaux, bancaires, régionaux, religieux et commémoratifs pour un maximum de 10 pays, sur une année ou une plage de dates. Chaque jour férié indique s'il s'agit d'un jour chômé, d'un jour férié bancaire ou s'il tombe pendant les vacances scolaires, si un jour férié tombant un week-end a été reporté à un autre jour, si une date du calendrier islamique est encore estimée, et si une interdiction de circulation des poids lourds s'applique ce jour-là (truck_ban). Filtrage par région (region=DE-BY), type, langue et nom ; school=1 ajoute les vacances scolaires.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — compte les jours ouvrés entre deux dates, ajoute ou soustrait des jours ouvrés, teste une date, ou trouve le jour ouvré suivant ou précédent. Il utilise le week-end du pays (samedi-dimanche, ou vendredi-samedi et d'autres week-ends dans le Golfe), les jours chômés nationaux et régionaux et les reports de jours décrétés.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — les pays couverts avec jours de week-end, fuseau horaire, régions et types de jours fériés ; avec country=, également les jours ouvrés par an et les cinq prochains jours fériés.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, plan Pro et supérieur) — impact commercial estimé par modèle : un score d'impact de 0 à 100 par jour férié, la probabilité de fermeture des commerces, les catégories de demande, la position en week-end prolongé et en pont, et les fenêtres de pic de demande. Sur holiday-calendar-holidays, les plans Pro et supérieurs obtiennent aussi ce bloc avec include=impact et peuvent filtrer avec min_impact.

Le produit existant holiday-calendar ne change pas. Documentation : Holiday Calendar.

Trois nouveaux produits pour la conformité des temps de conduite, servis depuis /api/v2 :

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, corps JSON) — vérifie l'activité enregistrée du conducteur au regard du règlement EU 561/2006 ou de l'AETR et du temps de travail de la Directive 2002/15/EC. Il renvoie chaque infraction avec l'article de la règle et sa tranche de gravité, ainsi que ce qu'il reste au conducteur à l'instant : conduite journalière, limites glissantes de 56 h par semaine et de 90 h sur deux semaines, prochaine pause, repos journalier et hebdomadaire. Il couvre les pauses fractionnées, les journées réduites et prolongées, la compensation du repos hebdomadaire réduit, le travail de nuit, l'équipage double et le repos interrompu par ferry ou train.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — les paramètres des règles EU 561, AETR (avec ses différences par rapport au 561) et 2002/15, ainsi que les tranches de gravité du Regulation (EU) 2016/403.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, corps JSON) — vérifie les services planifiés avant l'affectation au regard des interdictions de circulation des poids lourds, des jours fériés et des jours de week-end dans les pays du trajet, ainsi que des règles EU 561, AETR et 2002/15. Chaque service reçoit l'heure de début légale la plus précoce.

Documentation : Fleet Compliance.

À partir de la v3, les arrêts de repos journalier et hebdomadaire ont les champs in_vehicle_allowed, accommodation_required et rule (route-plan avec rest_rules=eu561 et truck-route). Le règlement (UE) 2020/1054 a modifié l'art. 8, § 8 du EU 561/2006 : le repos hebdomadaire normal et tout repos hebdomadaire de plus de 45 h ne peuvent pas être pris dans le véhicule. Pour ces arrêts, in_vehicle_allowed = false. Le repos hebdomadaire réduit (de 24 h à moins de 45 h) et le repos journalier peuvent être pris dans un véhicule à l'arrêt équipé d'un couchage.

Les arrêts de repos hebdomadaire ont aussi accommodation[] — des parkings avec chambres sur place près de l'arrêt — et le parking de l'arrêt a has_accommodation. C'est une information seulement : l'arrêt, son heure et son parking poids lourds ne changent pas. Si aucun site avec chambres n'est connu, l'arrêt a warning = no_accommodation_found. Les réponses v1 et v2 ne changent pas.

Les prix des stations dans /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local et /api/v2/data/fuel avec mode=nearest ont désormais un âge maximal de 90 jours. Un prix que nous avons confirmé pour la dernière fois il y a plus de 90 jours n'est plus renvoyé. Auparavant, un tel prix était renvoyé avec stale = true.

Ce qui change dans les réponses : un carburant qui n'a qu'un prix plus ancien est absent de prices ; une station sans aucun prix restant n'est pas listée, ou a un objet prices vide là où les stations sans prix sont affichées ; et une réponse peut être vide là où elle contenait auparavant d'anciens prix. Une réponse vide contient toujours empty_reason. fuel-local peut alors répondre depuis le niveau région ou pays. L'indicateur stale est inchangé : il vaut true quand un prix a été confirmé pour la dernière fois il y a plus de 7 jours. L'historique des prix est conservé. Pour fuel-cities, fuel-cost, les moyennes nationales et fuel-grades, il n'y a pas de changement pratique. Détails : Âge des prix.

GET /api/v2/data/route-plan reçoit un modèle d'arrêts étendu en v2 (additif : rien n'est supprimé ni renommé) et de nouvelles valeurs par défaut en v3 (/api/v3/data/route-plan).

v2, additif. Avec stop_places=1, chaque arrêt (pause, repas, nuit, repos hebdomadaire) contient places[] : des parkings candidats dans une fenêtre de temps de conduite autour de l'arrêt, chacun avec name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 et type_rank. Réglez la recherche avec places_before_min, places_after_min, places_radius_km et rest_radius_km ; un rayon supérieur à 25 km est plafonné et signalé par l'avertissement radius_clamped. rest_rules=legacy|eu561 choisit le modèle de repos, et avec eu561 vous pouvez envoyer l'état du conducteur : driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used et allow_reduced. Nouveaux types d'arrêt : ban_wait (avec ban : name, country, from, until) et weekly_rest ; une attente qui tient lieu de pause ou de repos est marquée counts_as. Les passages poids lourds de sortie d'Ukraine avec file électronique ajoutent registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note et registration_url, ainsi que les avertissements echerha_registration et echerha_wait_unverified.

v3, nouvelles valeurs par défaut. rest_rules vaut eu561 par défaut ; les noms de lieux sont stricts (uniquement de vrais parkings et aires de repos) ; l'attente publiée par eCherha (données fraîches, non plafonnée) sert d'attente à la frontière, et une attente à la frontière compte comme la pause ou le repos dû. La v2 conserve l'ancien modèle de repos et le filtre de lieux d'origine, les intégrations existantes ne changent donc pas. Détails : Route Planner API.

GET /api/v3/data/truck-route utilise désormais l'attente à la frontière d'eCherha. En v3, border_crossings[] pour les voies poids lourds de sortie d'Ukraine avec file électronique prennent wait_min dans l'attente publiée par eCherha (données fraîches uniquement, non plafonnée ; si elle est périmée, wait_min vaut null et l'avertissement echerha_wait_unverified est ajouté) et portent registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note et registration_url, avec l'avertissement echerha_registration.

Le plan de repos traite l'attente à la frontière comme du temps passé à la frontière : une longue file compte comme la pause, le repos quotidien ou hebdomadaire dû (counts_as sur la ligne waits[]), au lieu de s'ajouter en plus. La v2 est inchangée. Détails : Truck Route API.

Lorsque /api/v2/data/fuel-stations ou /api/v2/data/fuel-cheapest ne trouve aucune station, la réponse reste HTTP 200 avec une liste vide, et elle en indique désormais la raison. Uniquement pour une réponse vide, data contient empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type ou no_fresh_price_in_radius), nearest_station_km (la station la plus proche proposant votre carburant, recherchée jusqu'à nearest_search_km = 50 km ; null s'il n'y en a aucune), country et suggestion, une courte phrase dans votre lang, par exemple : No station within 5 km — the nearest is 6.4 km away; try radius_km=10.

Faites dépendre votre code de empty_reason et nearest_station_km. suggestion est un conseil pour les personnes et sa formulation peut changer. Nous n'élargissons jamais le rayon à votre place. Si vous échantillonnez une zone ou un itinéraire sur une grille, utilisez radius_km 10–15. Les réponses contenant des stations ne changent pas. Détails : Réponses vides.

Rayon de recherche. radius_km sur /api/v2/data/fuel-stations conserve désormais une décimale. Un rayon comme 4.8 était auparavant tronqué à 4 sans avertissement : chaque recherche couvrait jusqu'à un tiers de surface en moins que demandé et pouvait renvoyer moins de stations, voire aucune. anchor.radius_km indique le rayon réellement appliqué ; les nombres entiers sont renvoyés comme avant.

Noms de marque. Une même marque est désormais toujours écrite de la même façon dans brand — par exemple ORLEN et orlen sont renvoyés sous la forme Orlen, et CircleK sous la forme Circle K. Les stations, prix, identifiants et champs sont inchangés. Si vous associez les marques par orthographe exacte (pour des logos ou des filtres), vérifiez votre liste par rapport aux nouveaux noms.

GET /api/v2/data/truck-route accepte un nouveau paramètre facultatif traffic. Il définit comment le trafic est pris en compte pour l'ETA, le plan de repos, les heures d'arrivée aux frontières et les heures aux interdictions poids lourds :

• forecast (par défaut) : congestion récurrente à l'heure où le camion franchit chaque tronçon, embouteillages actuels s'atténuant avec le temps restant avant l'arrivée, travaux et fermetures sur le tracé, et météo là où nous la connaissons. La réponse contient un bloc traffic_forecast avec le retard réparti par cause.
• live : trafic actuel uniquement, sans congestion récurrente.
• off : aucun ajustement lié au trafic ; les temps sont ceux du moteur poids lourds en circulation fluide. traffic_forecast ne contient alors que model et mode.

Toute autre valeur renvoie 400 bad_request avec le message Invalid traffic: forecast, live or off. Les requêtes sans le paramètre reçoivent la valeur par défaut, forecast.

Interdictions poids lourds à l'heure d'arrivée prévue : avec forecast ou live, truck_bans[].active est désormais évalué à l'heure à laquelle le camion devrait atteindre chaque interdiction (à partir de depart_at, ou de maintenant si vous n'en envoyez pas), avant toute attente liée à cette interdiction. Un nouveau champ truck_bans[].active_at indique l'heure évaluée, en heure locale du pays de l'interdiction. bans_summary, restriction_hits et legal suivent les mêmes verdicts, et une interdiction que le retard prévu fait désormais rencontrer (par exemple un autre jour ou dans un autre pays) figure aussi dans truck_bans. Avec traffic=off, active est évalué sur la chronologie en circulation fluide et active_at est égal à eta_at_ban.

Nouveau produit : Truck Route API (GET /api/v2/data/truck-route, v2 uniquement). Un seul appel renvoie un itinéraire adapté aux poids lourds et ce dont un dispatcheur a besoin le long du trajet. L'itinéraire est calculé par le même moteur de routage que notre application de navigation poids lourds TruckTurn, sur nos propres données cartographiques.

• Véhicule : height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (classes ADR) et adr_tunnel (B–E). Les interdictions de circulation des poids lourds et les zones de restriction sont vérifiées sur le tracé renvoyé.
• Le long de l'itinéraire : stations-service avec prix actuels, parkings poids lourds et stations de pesage, chacun avec km_from_start et détour.
• Plan de repos du conducteur selon le règlement (CE) 561/2006 : pauses (y compris fractionnées 15+30), repos journalier et hebdomadaire (y compris réduit), conducteur seul ou équipage de deux (crew=2), à partir de l'état actuel du conducteur si vous le transmettez. Chaque arrêt est placé sur un parking réel le long de l'itinéraire. C'est une aide à la planification, pas un relevé de tachygraphe.
• ETA incluant les repos, les interdictions de circulation des poids lourds et les attentes aux frontières. Planification par depart_at ou arrive_at.
• Estimations du coût des péages par pays (EUR, selon les essieux et la classe d'émissions) ; les pays sans tarif sont listés dans tolls.coverage_note. Également avoid (péages, ferries, autoroutes, frontières, tunnels, routes non revêtues, zones à faibles émissions), jusqu'à 2 alternatives, une ventilation par pays et geometry en polyline5, polyline6 ou GeoJSON.

Quota : un quota distinct pour les itinéraires poids lourds : 10 appels par jour sur chaque compte, davantage avec les offres payantes, et une option Appels d'itinéraires poids lourds supplémentaires. Dans le sandbox, vous pouvez exécuter 10 itinéraires poids lourds par jour, voir le résultat sur la carte avec le plan d'itinéraire complet et l'exporter en GPX, KML, GeoJSON, CSV, calendrier (.ics) ou ITN. Voir la page produit et la référence.

Selon les Conditions d'utilisation de l'API, un Market est le pays dont vous utilisez les données, et votre clé couvre les pays approuvés pour votre compte. Jusqu'à présent, les produits basés sur des coordonnées (lat/lon — p. ex. Nearby Shops, Truck Parkings, Fuel Stations) répondaient pour n'importe quel point d'Europe. À partir du 13 octobre 2026, cela est vérifié lors du traitement de votre requête :

• Une requête dont les lat/lon se trouvent dans un pays non approuvé pour votre compte renvoie 403 avec error.code market_not_allowed. Le message indique le pays et votre liste de pays approuvés.
• Lorsque le rayon traverse une frontière, les résultats dont le country_code se situe hors de vos pays approuvés sont supprimés. La réponse comporte alors markets_filtered (nombre supprimé) et markets_notice, et total_found ne compte que ce que vous avez reçu.

Ceci s'applique aux comptes dont les pays ont été examinés (statut approved ou partial). Rien ne change dans la requête — aucun nouveau paramètre, aucune nouvelle version. Si votre application a besoin d'un autre pays, ajoutez-le dans le portail développeur avant le 13 octobre. market_not_allowed figure avec les autres codes d'erreur dans la référence.

Les comptes développeur liés à un compte Nakordoni Partners avec la même adresse e-mail peuvent désormais soumettre des actualités et gérer leur flotte NakBus (NakDriver / NakManager) depuis partners.nakordoni.eu, avec des rôles d'équipe (Owner, Manager, Viewer) et une connexion en un clic entre les deux portails. Les pages du portail développeur, les clés API, les points de terminaison de la flotte et les applications restent inchangés.

Sur Fuel Prices, updated_at et l'indicateur age_hours/stale propre à la réponse ne suivaient pas la même horloge : updated_at ne change que lorsqu'un prix change réellement, mais l'obsolescence était calculée comme s'il changeait à chaque confirmation. 46.7% de l'index des prix affichait age_hours ≤48 et stale:false alors que updated_at datait en réalité de plus de 48 heures, et de plus d'une semaine pour 12,620 stations. Chaque prix porte désormais aussi confirmed_at — la dernière fois que nous avons confirmé le prix, arrondie à l'heure inférieure et jamais antérieure à updated_at — et age_hours/stale sont calculés à partir de ce champ. La signification de updated_at est inchangée : utilisez-le pour savoir quand le prix a bougé pour la dernière fois, et confirmed_at pour savoir à quel point il est à jour maintenant. Absent du contrat v1 figé.

Deux bugs de langue, tous deux silencieux : envoyer le code canonique du carburant avec lang=pl (ou n'importe laquelle des 24 autres langues du site) renvoyait fuel_type_local en anglais quelle que soit la demande — seules 10 langues avaient jamais été vérifiées dans la table des libellés, si bien que tout ce qui sortait de cette liste retombait sur le vocabulaire d'interface par défaut au lieu de la langue demandée. Séparément, lang=tr (ou plusieurs autres codes valides) renvoyait les listes de stations en ukrainien, car une valeur interne par défaut uk se déclenchait chaque fois que la langue demandée ne figurait pas dans cette même liste de 10 langues. Les deux sont corrigés : la langue que vous envoyez est désormais la langue que vous recevez, sur les 25.

Aussi : brand sur Nearby Fuel Stations ne renvoie plus la valeur sentinelle brute d'ingestion OTHER pour les ~330 stations dont nous ne connaissons pas la marque — c'est désormais null, de façon cohérente avec tout autre champ inconnu de la réponse.

L'assistant IA frontière (/api/v1/data/assistant) renvoyait 503 internal_error — « Assistant temporairement indisponible » — lorsqu'une même clé posait deux fois la même question en moins de cinq minutes. Rien n'était indisponible : dans la plupart de ces cas, la réponse était déjà calculée et prête à être renvoyée. Elle est désormais renvoyée normalement, avec ok: true et HTTP 200.

Lorsque la répétition arrive alors que la première réponse est encore en cours de rédaction, l'appel renvoie maintenant 429 avec un error.code égal à duplicate_request au lieu d'un 503, ce qui permet à une politique de nouvelle tentative de distinguer « redemandez dans un instant » d'une véritable panne. Les deux cas étaient également comptés dans le taux d'erreur de votre compte comme des erreurs serveur ; ce n'est plus le cas. Rien ne change dans la requête — aucun paramètre, aucune version. duplicate_request figure avec les autres codes d'erreur dans la référence.

Truck Parking (/api/v2/data/truck-parkings) renvoyait des entrées dont le name valait null et dont l'address était vide — près de Bensheim, 20 sur 50. Ce sont des lieux que nous ne conservons que sous forme de coordonnée, sans rien à afficher ni rien à rapprocher de votre propre jeu de POI. Ils ne font plus partie de ce produit : il ne sert désormais que des lieux nommés, actuellement plus de 22 000 à travers l'Europe. Si vous filtriez vous-même les entrées sans nom, ce code est désormais redondant mais sans effet. Les réponses raccourcissent pour les mêmes radius et limit, et chaque entrée renvoyée est exploitable.

Par ailleurs, environ 10 000 parkings portaient une paire de coordonnées brute comme name, par exemple 51.927301,10.14112, alors que le libellé réel se trouvait dans address. Ils portent maintenant ce libellé — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — partout où ils apparaissent, y compris sur /api/v1/data/pois. L'id de chaque lieu est inchangé, donc une correspondance mise en cache reste valable ; seul le name diffère.

snapshot.updated_at sur /api/v1/data/queue et /api/v1/data/multi est l'heure locale dans le fuseau propre au poste-frontière (par exemple Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), et jusqu'ici rien dans la réponse n'indiquait de quel fuseau il s'agissait ; l'appelant ne pouvait donc pas la convertir en un instant précis. snapshot reçoit un champ additif timezone (nom IANA) à côté de updated_at. Aucun paramètre, aucune version, aucun autre champ ne change.

Jusqu'ici, chaque endpoint carburant décrivait sa propre couverture par une liste écrite à la main : AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, la Pologne y étant réduite à l'agglomération de Trójmiasto. Les deux affirmations étaient périmées depuis longtemps. La couverture est désormais mesurée sur l'index vivant des stations et recalculée toutes les six heures : 39 pays comptent aujourd'hui des stations avec des prix, dont la Pologne sur tout son territoire et non dans trois villes. Rien ne change dans la requête : aucun paramètre, aucune version.

Nearby Fuel Stations et Cheapest Fuel : quand une recherche ne renvoie rien, le bloc coverage porte maintenant des valeurs mesurées station_countries, station_counts, sparse_coverage et measured_at, restreintes au type de carburant demandé et non au carburant en général. Un pays entre dans sparse_coverage lorsque nous y détenons 25 stations avec prix ou moins — c'est un décompte, pas un jugement.

Une nouvelle note apparaît pour un type que nous reconnaissons mais que personne ne cote là où vous interrogez. Jusqu'à présent, coverage.fuel_type_note n'apparaissait que lorsque le nom à la pompe nous était inconnu. Elle apparaît désormais aussi lorsque le nom est correctement résolu et qu'il n'existe simplement aucun prix pour lui dans ce pays ; elle nomme les pays où ce type est coté et les types que nous cotons autour de vous. Le nom tchèque Natural 100 en est l'exemple net : il est reconnu, et aucune source ne lui donne de prix en Tchéquie. Une réponse vide cesse de ressembler à une requête cassée.

Fuel Grades (/api/v2/data/fuel-grades) gagne priced_countries et priced_station_counts pour chaque type, ainsi que priced_here si vous passez ?country=. Les deux listes ne disent pas la même chose : un pays sous countries est un pays où nous acceptons ce nom à la pompe, tandis que priced_countries indique où une source le cote réellement ; priced_here à 0 est donc une vraie réponse et non un trou dans la réponse. La charge utile porte aussi coverage_measured_at et coverage_note, et son Cache-Control passe de 24 heures à 6, pour coller à la fréquence de recalcul.

Davantage de noms locaux à la pompe sont également résolus, parmi lesquels Klimadiesel 90 (HVO100) et HVO Diesel, Erdgas et Metano, Autogas et Autogaz, DEF pour l'AdBlue, ainsi qu'un certain nombre de noms commerciaux de gazoles et d'essences premium. L'ordre de résolution est inchangé et la correspondance reste exacte : aucun nom qui fonctionnait auparavant ne signifie autre chose aujourd'hui, et un nom nouveau peut tout au plus transformer une réponse vide en réponse avec des prix. Dans le même temps, la documentation de référence et les descriptions des endpoints ont été corrigées dans les 25 langues du site.

Cheapest Fuel (/api/v2/data/fuel-cheapest) renvoyait les stations les plus proches triées par distance au lieu des moins chères. Comme le classement était appliqué avant que le résultat ne soit tronqué à votre limit, les stations les moins chères de votre rayon pouvaient être totalement absentes de la réponse. Le classement est de nouveau correct : la moins chère en premier pour le carburant demandé, la plus proche l'emporte en cas d'égalité, et une station sans cotation pour ce carburant est classée en dernier. Rien ne change dans la requête — ni paramètre, ni version.

Les réponses carburant v2 sont désormais également documentées telles qu'elles sont réellement renvoyées : les stations arrivent sous data.stations[], une entrée par station physique, chaque carburant étant imbriqué dans l'objet prices (price, currency, local_name, updated_at, age_hours, stale), plus station_ref, grades, total_found et notices. La documentation de référence de Nearby Fuel Stations et Cheapest Fuel décrivait encore l'ancienne liste plate de lignes data.data[].

Sur la page de facturation (onglet mensuel), deux options s'ajoutent à n'importe quelle formule, sans en changer : Appels de prévision supplémentaires — +100 appels de prévision et de statistiques par jour et par bloc, 2 € par mois et par bloc, jusqu'à 10 blocs ; et Pays supplémentaires — +1 pays déclarable par unité, 2 € par mois chacun. Toute modification de quantité affiche un devis au prorata exact avant tout prélèvement.

À partir du 10 novembre 2026, chaque formule inclut un nombre défini de pays déclarés : Explorer et Student 4, Starter 10, Pro et au-delà illimité. À partir de cette date, une déclaration plus longue que la formule plus les pays supplémentaires achetés ne pourra plus être enregistrée ; l'onglet Compte affiche déjà votre quota, et les comptes qui le dépassent voient une suggestion sur le tableau de bord. Rien ne change avant le 10 novembre.

Le bac à sable API indique désormais pour chaque point de terminaison de la liste sa classe de quota (Lourd / Standard), affiche le coût en quota de la version choisie avant toute exécution et, après un appel, montre ce que le même appel aurait coûté sur votre quota de production — y compris la formule ceil(N ppids × M sub-products / 2) utilisée pour les appels de type /multi.

Il s'agit d'un aperçu en lecture seule : les appels du bac à sable sont eux-mêmes prélevés sur votre budget de test distinct, jamais sur votre quota de production.

À partir d'aujourd'hui, tout ce que nous avons publiquement annoncé comme étant en cours de retrait est fermé aux comptes développeur créés à la date de l'annonce ou après. Si votre compte existait avant l'annonce, rien ne change — vous conservez l'intégralité de la période de grâce, jusqu'à la date de retrait indiquée dans l'entrée qui l'a annoncé.

Pourquoi cette règle existe. Le 24 août 2026, nous avons annoncé que truck-bans v1 serait retirée le 8 septembre 2026. Deux comptes se sont enregistrés quelques jours après cette annonce, ont bâti leur intégration sur la v1 et sont passés à quelques heures d'un 410 sans qu'aucun de nos e-mails ne leur soit jamais parvenu : l'annonce comme le lot de notifications précédaient leur inscription. Rien dans l'API ne les a empêchés d'adopter une version dont nous avions déjà dit qu'elle disparaissait. C'était notre erreur, et voici le correctif : vous ne pouvez pas adopter à neuf quelque chose dont la suppression est déjà programmée.

À quoi cela ressemble. Un tel appel est refusé avec 410 Gone et le code d'erreur version_closed_to_new_accounts. Le message indique la date de retrait, la date d'annonce et la version à utiliser à la place. C'est délibérément un code différent de version_sunset, que reçoit tout compte une fois la date de retrait elle-même passée — le support distingue ainsi « vous êtes arrivé trop tard pour commencer » de « c'est fini pour tout le monde » sans lire de journal.

L'antériorité se fonde sur la date de création du compte, pas sur le premier appel. Si vous vous êtes enregistré avant l'annonce mais ne commencez l'intégration que maintenant, vous bénéficiez tout de même de l'intégralité de la période de grâce : vous développiez peut-être dessus depuis le début.

En vigueur dès maintenant pour truck-bans v1 (annoncée le 24 août 2026, retirée le 8 septembre 2026), et automatiquement pour chaque retrait que nous annoncerons désormais. Rien de nouveau n'est requis de votre part : chaque réponse sur une version en cours de retrait porte déjà les en-têtes Deprecation, Sunset et Link: rel="successor-version", si bien qu'une nouvelle intégration peut voir venir un retrait sans lire cette page.

Suite du changement v4 d'hier (ticket développeur #105). Les listes destination séparées par des virgules en v1 et v2 continuent de fonctionner, mais relèvent désormais de la même échéance que destination=all : les deux s'arrêtent le 2026-10-06 (en-têtes Deprecation/Sunset jusque-là, puis 400 destination_list_removed, qui désigne /api/v4/ comme remplacement). Le plafond existant de 10 éléments sur les listes à virgules reste inchangé avant cette date.

La v4 reste à une seule destination par appel — cela n'a pas changé aujourd'hui. Seule la communication autour de v1/v2 change : le 400 de destination=all ne propose plus une liste à virgules comme voie de migration (elle mourrait à la même date), il renvoie directement vers la v4.

Correction de documentation : l'exemple v4 de ce site indiquait auparavant /api/v4/data/border/1/2,3,4/9 — une liste à virgules, que la v4 rejette. Il est désormais /api/v4/data/border/1/2/9. Quiconque a copié l'ancien exemple aurait obtenu un 400 dès son premier appel ; désolé.

Nouvelle clé traduite product_border_v4_p_destination est livrée dans les 25 langues du site et énonce explicitement la règle d'une seule destination en v4 au lieu de reprendre la formulation de v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} est en ligne depuis aujourd'hui. Trois choses changent par rapport à v2, et c'est leur ensemble qui en fait une nouvelle version plutôt qu'une simple modification.

1. Fini destination=all. Nos données sont concédées sous licence pays par pays (Developer API Terms, section 7), et un joker qui se développe en « tous les voisins pour lesquels nous détenons des données » renvoie des pays pour lesquels votre compte n'est peut-être pas approuvé — sans que rien dans la requête ne l'indique. En v4, vous nommez le pays.

2. Un seul pays de destination par appel. /api/v4/data/border/1/2/9 demande une seule frontière. Les listes séparées par des virgules ne sont pas acceptées : envoyez 1/2/9, 1/3/9 et 1/4/9 en appels distincts. Une liste à virgules ou all répond 400 et nomme les appels exacts à envoyer, pour que rien n'échoue en silence.

3. Un seul code poids lourd. v1 et v2 séparaient le fret en 8 (Freight Transport) et 9 (Freight Transport up to 7.5 t). Cette distinction est réelle au passage frontalier, mais aucun intégrateur ne peut en tirer parti : demander 9 à v2 sur la frontière UA-PL renvoyait 21 des 70 passages poids lourds, sans que rien ne le signale. v4 répond à 9 avec toutes les voies poids lourds, et accepte 8 comme alias de 9. Chaque ligne porte son propre crossing_type, la réponse fusionnée reste donc inspectable.

En v1 et v2, destination=all continue de fonctionner jusqu'au 6 octobre 2026 et porte d'ici là les en-têtes Deprecation / Sunset. À partir de cette date, ces versions répondent elles aussi 400 pour all — le reste de v1 et v2 est inchangé et reste disponible. La même date s'applique aux autres raccourcis « tous pays » : travel-matrix sans ?dest=, bus-carriers avec ?ppid=all, et fuel-grades sans ?country=.

v3, annoncée plus tôt dans la journée, est remplacée par v4. v3 ne différait de v4 que par l'acceptation d'une liste à virgules, et aucune intégration n'utilise cette forme. Les URL v3 continuent de répondre pour que rien de ce qui a été écrit contre elles ne casse, mais v3 n'est pas documentée et ne sera pas développée davantage — migrez vers v4.

Tout le reste de v4 est identique à v2 : ordre directionnel du chemin, direction{from,to}, stale et ?max_age_min=.

Les identifiants numériques de /border/{origin}/{destination}/{crossing_type} n'avaient jamais été publiés sous forme de table : les intégrateurs les reconstituaient à partir des fuseaux horaires et des URL d'exemple. Ils figurent désormais dans la documentation, sous Codes pays et types de véhicule, générés depuis les tables mêmes que l'API utilise pour valider — les identifiants de pays avec les frontières auxquelles chacun correspond, et chaque crossing_type avec le libellé que renvoie l'API.

En les publiant, nous avons constaté que le bac à sable et les métadonnées du point de terminaison décrivaient 8 comme « truck<7.5t » et 9 comme « truck ». C'est l'inverse : l'API libelle 8 Freight Transport et 9 Freight Transport up to 7.5 tons, et l'a toujours fait. Si vous avez choisi un code poids lourd d'après l'indication du paramètre, vous filtriez la voie opposée à celle que vous visiez. Corrigé partout, et v3 supprime le choix entièrement.

Les API Terms v1.1 remplacent la v1.0 avant son entrée en vigueur et s'appliquent à partir du 6 octobre 2026. Merci de les accepter dans votre tableau de bord.

La section 7 précise désormais ce qu'est un Marché : le pays dont vous utilisez les données — celui où se trouve le poste-frontière ou la frontière demandée — et non le pays où résident vos utilisateurs. Notre tableau de bord affirmait les deux à des endroits différents ; l'application a toujours retenu le premier.

Deux changements en votre faveur. Les pays déjà approuvés pour votre compte restent utilisables pendant l'examen d'une modification ultérieure (ajouter un pays ne suspend plus ceux que vous avez déjà). Et si nous n'avons pas répondu à une déclaration de marché sous 5 jours ouvrés, les limites complètes de votre offre s'appliquent jusqu'à ce que nous le fassions.

La section 10.3 correspond désormais à ce que le tableau de bord demande réellement, et la section 13.2 énonce une base de disponibilité que nous mesurons et pouvons vous présenter.

Trois produits portent désormais un champ additif data_quality (high ou low) indiquant si une valeur est une observation réelle ou une estimation de modèle, sans source de comptage en direct à ce passage : queue (sur le snapshot de premier niveau et sur chaque ligne historique de data[] — absent des lignes de prévision), update-info (sur l'enveloppe) et multi (sur les sous-objets queue et update_info de chaque poste-frontière). Ce n'est pas un nouveau signal — l'indicateur sous-jacent existait déjà en interne — mais il n'était jamais exposé, si bien qu'un poste entièrement modélisé semblait identique à un poste mesuré directement. is_realtime reste volontairement inchangé : il vaut toujours true pour les lignes modélisées, et modifier ce sens serait un changement cassant de niveau v2, que nous ne faisons pas ici.

Également dans cette version : le produit queue-advanced ne rediffuse plus les données météo brutes du fournisseur. weather_main, temperature et wind_speed sont remplacés par un condition_code dérivé (échelle de danger 0–5, null lorsque aucune météo n'est disponible), condition et severity.

À partir du 2026-08-30, une requête /api/v1/data/multi obtient une réponse pour 5 points de passage au maximum. Un appel qui énumère davantage de PPID n'est pas rejeté : il renvoie toujours 200, mais seuls les 5 premiers identifiants de ?ppids= reçoivent une réponse. Les identifiants restants sont ignorés, renvoyés dans meta.ppid_cap.ignored et ne sont pas décomptés de votre quota — l'appel est facturé sur ce qu'il renvoie réellement.

Tant qu'un appel dépasse la limite, la réponse comporte un en-tête X-Devapi-Warning: multi_ppid_cap et un bloc meta.ppid_cap avec cap, enforced_from, enforced, ppids_asked, ppids_answered et ignored[]. Jusqu'au 2026-08-30, ces champs apparaissent avec enforced: false et l'ensemble complet des résultats, afin que vous puissiez voir venir le changement dans vos propres journaux.

La remise de quota de moitié reste inchangée. Répartissez vos points de passage en groupes de 5 et envoyez un appel par groupe selon votre cycle de rafraîchissement habituel ; pour une interrogation fréquente portant uniquement sur la longueur de la file et la fraîcheur des données, update-info reste le produit de classe standard le moins cher.

L'interdiction canicule calculée pour l'Ukraine — renvoyée avec include_ua_heat, et automatiquement pour country=UA — répond désormais pour la fenêtre de dates demandée. Elle renvoyait auparavant les sept jours à venir quels que soient date_from et date_to, si bien qu'une fenêtre de décembre renvoyait discrètement les lignes de cette semaine. L'interdiction est calculée à partir des prévisions météo et non lue dans le calendrier des interdictions : elle a donc deux limites que le calendrier n'a pas, elle ne regarde pas en arrière et s'arrête là où s'arrêtent les prévisions. Votre fenêtre est maintenant croisée avec ce que les prévisions couvrent réellement, et le nouveau champ ua_heat_ban.forecast_horizon indique la dernière date atteinte. Une fenêtre au-delà de cet horizon ne renvoie aucune ligne et l'explique dans summary — ce qui n'équivaut pas à « aucune interdiction ». Les réponses v1 sont inchangées.

La forme de la réponse n'était documentée nulle part : le seul moyen de savoir ce qu'un produit renvoyait était de l'appeler. Chaque page produit affiche maintenant, sous le tableau des paramètres, un tableau Champs de la réponse avec une courte description de chaque champ ; les champs des éléments de liste apparaissent sous la forme items[].name, et les champs au niveau de l'enveloppe (usage, meta, snapshot, resolved_location) sans préfixe. 40 produits sur 42 sont documentés : les deux qui ne sont pas encore lancés (weather, road-quality) restent volontairement sans description. Le même tableau est publié dans notre miroir public de documentation sur GitHub.

Chaque produit carburant accepte désormais le nom local d'un carburant, et plus seulement notre écriture interne : ON en Pologne, Nafta en Tchéquie, Gázolaj en Hongrie, Motorină en Roumanie, ДП en Ukraine, Motorin en Turquie, Gasóleo au Portugal et en Espagne. Le nom est interprété d'abord selon le pays — « 95 » désigne le E10 à une pompe danoise et le E5 à une pompe polonaise —, envoyez donc country avec le nom local, ou des coordonnées permettant de situer le point. La réponse renvoie fuel_type (canonique), fuel_type_requested (tel que vous l'avez saisi) et fuel_type_local. Un nom que nous ne savons pas situer n'est jamais remplacé par un carburant par défaut : la réponse revient vide et le dit.

Le tableau complet est désormais un produit à part entière — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — nos carburants canoniques et leurs noms locaux dans 41 pays européens, y compris des marchés dont nous ne publions pas les prix. Les niveaux pays et région de fuel et fuel-local gagnent en outre un objet grades qui relie chaque clé de prix à son carburant et à son nom à la pompe.

Le produit truck-bans répond désormais pour une date précise ou une plage de dates sur /api/v2/data/truck-bans. Jusqu'ici il renvoyait toujours les 7 prochains jours et ignorait toute date transmise ; constituer un calendrier imposait donc une requête par jour — et sur une offre à deux requêtes par seconde, la plupart sont rejetées avec 429 qps_exceeded.

Utilisez ?date=YYYY-MM-DD pour une seule journée, ou ?date_from= et ?date_to= pour une plage. Les deux bornes sont incluses et l'une ou l'autre peut être omise : le début vaut aujourd'hui par défaut, la fin vaut le début plus 7 jours. Une fenêtre couvre au maximum 92 jours — au-delà, la requête est refusée avec 400 date_range_too_long plutôt que tronquée en silence. C'est un calendrier tourné vers l'avenir : une fenêtre peut commencer au plus 7 jours dans le passé, et toute date antérieure est refusée plutôt que servie — la couverture s'étend en avant jusqu'au 31 décembre 2028 pour 23 pays.

Chaque réponse contient désormais un objet window qui nomme exactement la plage couverte. Ce champ est additif et il est également envoyé en v1, où la v1 conserve sa fenêtre fixe de 7 jours inchangée. À noter : include_ua_heat couvre toujours les 7 prochains jours, quelle que soit la fenêtre demandée — il est calculé à partir d'une prévision météo, non du calendrier des interdictions. Rappel : la v1 de ce produit est retirée le 8 septembre 2026.

Deux améliorations connexes sur toute l'API : tout paramètre qu'un produit n'accepte pas est désormais listé dans ignored_params au sein de la réponse au lieu d'être écarté en silence, et les erreurs de validation du service de données vous parviennent telles qu'elles sont écrites, avec le code exploitable par une machine dans error.reason.

Trois correctifs de qualité de réponse issus d'un audit de la passerelle (ticket #43).

L'en-tête X-API-Key est désormais accepté aux côtés de Authorization: Bearer et de ?key=. Si votre client HTTP envoie les clés via un en-tête nommé X-API-Key, cela fonctionne maintenant — auparavant il était ignoré silencieusement et l'appel était rejeté avec missing_api_key. Authorization: Bearer reste la forme documentée et recommandée.

Le message d'erreur de clé manquante nomme désormais les trois moyens de s'authentifier (en-tête Bearer, en-tête X-API-Key ou ?key=) au lieu de renvoyer uniquement vers la page d'inscription.

L'annuaire checkpoints porte désormais has_day_stats sur chaque ligne — un booléen additif qui indique si l'API Best Time to Cross (day-stats) dispose de données pour ce poste-frontière. Les day-stats n'existent que pour une partie des postes surveillés ; vérifiez ce drapeau avant d'interroger l'API pour éviter des 404 prévisibles. Les champs existants sont inchangés.

Également corrigé dans la documentation : le produit road-conditions a toujours respecté un paramètre lang pour la localisation des libellés — il n'était simplement pas listé.

Deux correctifs et une nouvelle version pour le produit truck-bans.

Les pays séparés par des virgules fonctionnent désormais. ?country= accepte une liste d'au plus 3 codes ISO-2, par exemple ?country=DE,RO. Une liste plus longue est refusée avec 400 too_many_countries plutôt que tronquée silencieusement — il s'agit d'un calendrier d'interdictions par pays, pas d'un flux en masse. Cela ne fonctionnait pas jusqu'ici : le séparateur était supprimé, si bien que DE,RO était lu comme le jeton unique DERO, ne correspondait à rien et renvoyait success: true avec total_bans: 0 — un « aucune interdiction » assuré pour deux pays qui en comptaient 22 à eux deux. Si vous contourniez le problème par une requête par pays, une seule requête les couvre maintenant toutes et coûte un appel au lieu de plusieurs.

Les réponses signalent désormais leur propre complétude. Trois champs additifs — returned, total_available et truncated — indiquent si une réponse a été plafonnée. Un appel sans portée renvoie en particulier une tranche plafonnée, et jusqu'ici rien dans la charge utile ne le signalait. total_bans conserve son sens actuel (lignes de cette réponse), donc rien de ce que vous analysez déjà ne change.

La v2 est limitée à un pays. Sur /api/v2/data/truck-bans, ?country= est obligatoire et une requête sans portée est refusée avec 400 scope_required — ce produit est un calendrier d'interdictions par pays, pas un flux en masse. La v1 est inchangée aujourd'hui — elle accepte toujours un appel sans portée et renvoie toujours les mêmes 50 lignes plafonnées qu'auparavant, donc rien de ce que vous exécutez ne casse dès maintenant. La v1 de ce produit est retirée le 8 septembre 2026. Elle fonctionne normalement jusqu'au 7 septembre ; à partir du 8 septembre, une requête v1 est refusée avec 410 Gone et un message renvoyant vers la v2. D'ici là, chaque réponse v1 porte Deprecation: true, un en-tête Sunset avec cette date et un en-tête Link nommant la version qui lui succède, afin qu'une bibliothèque cliente puisse afficher l'échéance sans que personne ne lise cette page. Pour migrer : remplacez le segment de version par /api/v2/data/truck-bans et passez ?country=.

Une correction de documentation : le paramètre date a été retiré. Il était listé depuis longtemps mais n'était jamais lu par le service, si bien que toute requête l'envoyant recevait silencieusement la fenêtre de 7 jours par défaut plutôt que le jour demandé. Pour sélectionner un jour, filtrez le tableau upcoming_bans sur son champ date. Un code ISO-3 tel que DEU ne se résout plus non plus en nom de pays dans le résumé, où il produisait le trompeur « No truck ban data for: Germany. »

Le produit truck-bans renvoie désormais les restrictions de circulation nationales de cinq pays supplémentaires : la Belgique (BE), le Bélarus (BY), le Monténégro (ME), la Macédoine du Nord (MK) et la Suède (SE). La couverture existante de la Bulgarie, de la Grèce et du Portugal a été étendue et actualisée — les restrictions grecques vont maintenant jusqu'en septembre 2027, et le Portugal est de nouveau alimenté.

La structure de la réponse reste inchangée. Les nouvelles lignes portent les mêmes clés que toute autre interdiction : date, time_from, time_until, restriction_type, restriction_details, min_weight_tons et details_url. Lorsqu'une restriction ne s'applique que sous condition — les interdictions estivales bélarussiennes s'appliquent au-dessus de 25 °C, par exemple — cette condition figure dans restriction_details : lisez donc ce champ avant d'alerter un conducteur. min_weight_tons vaut null lorsqu'une règle vise une catégorie de transport (marchandises dangereuses) plutôt qu'un tonnage.

Les produits fuel-stations et fuel-cheapest renvoient désormais des prix par station en Pologne. La couverture est partielle — l'agglomération de Tricité (Gdańsk, Gdynia, Sopot) — c'est pourquoi la Pologne apparaît dans un nouveau tableau additif coverage.sparse_coverage, à côté de la liste existante coverage.station_countries. Un pays listé dans sparse_coverage ne dispose de données par station que pour une partie de son territoire ; une requête ailleurs dans ce pays renvoie une liste vide accompagnée de la note de couverture, exactement comme auparavant. Les prix polonais sont exprimés en PLN.

L'erreur de requête en masse est elle aussi plus claire : lorsque lat est absent, le message scope_required renvoie maintenant vers le produit fuel (?country=XX) pour les prix moyens nationaux.

GET /api/v2/data/fuel-local?lat=&lon= détermine désormais le prix sur trois niveaux au lieu de deux : station, puis region, puis country. Le nouveau niveau intermédiaire existe pour l'Ukraine, où aucun prix par station n'existe : un point en Ukraine reçoit maintenant la moyenne de son oblast au lieu de la moyenne nationale, et ne revient à la moyenne nationale que lorsque l'oblast n'est pas coté.

Une réponse du niveau region contient le code de l'oblast (une valeur ISO 3166-2 telle que UA-46), region_name et region_center_dist_km, ainsi que les mêmes clés de prix que le niveau pays. Continuez à brancher votre code sur resolution, jamais sur la forme de la réponse ; les réponses station et country restent inchangées.

Le nouvel endpoint GET /api/v2/data/fuel-local?lat=&lon= renvoie le meilleur prix de carburant disponible pour n'importe quel point en Europe. Là où nous disposons de données par station, il répond avec les prix des stations les plus proches ; sinon avec la moyenne nationale du pays où se situe le point — y compris l'Ukraine, où aucun prix par station n'existe.

Chaque réponse contient le champ resolution, qui indique le niveau ayant répondu : station (une liste de stations avec distance_km, chacune dans sa propre devise) ou country (un objet de moyennes nationales). Branchez votre code sur resolution, jamais sur la forme de la réponse. Disponible à partir de /api/v2/ ; fuel, fuel-stations et fuel-cheapest restent inchangés.

Les produits fuel-stations et fuel-cheapest couvrent désormais bien plus de stations en Allemagne, avec des prix actualisés tout au long de la journée — y compris en zone rurale. Le paramètre fuel_type accepte 13 types de carburant : diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 et lng. Lorsqu'aucune station ne correspond à la requête, la réponse contient un objet coverage listant les pays pour lesquels des données de stations sont disponibles.

Le paramètre radius= est désormais accepté comme alias compatible de radius_km sur tous les produits qui le documentent. Les produits fuel-stations et fuel-cheapest renvoient un objet additif coverage (liste des pays couverts et note explicative) au lieu d'un résultat vide sans explication lorsqu'aucune station ne correspond. Les objets de frontière de route-plan incluent maintenant une clé additive wait_basis (car_lane ou vehicle_lane), ce qui permet aux clients de savoir quand le temps d'attente poids lourds provient en réalité de la file voitures. La correspondance des postes-frontières poids lourds le long d'un itinéraire est nettement plus précise : repli sur la file voitures pour les paires de postes sans données poids lourds, garde-fou contre le mauvais sens, seuil de distance plus strict et déduplication des passages situés au même point. Toutes les modifications sont additives, sans rupture de compatibilité.

La page d'accueil développeurs dispose désormais de sections ancrées (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) avec une navigation par ancres, et chaque carte produit renvoie vers sa propre page de documentation. La nouvelle section Mobile apps présente Kordon Online et Truck Bans avec des liens Google Play. Rattrapage des traductions : l'historique de facturation, les erreurs de connexion, les liens vers le bac à sable et le bouton de sélection de plan sont désormais localisés dans les 25 langues.

La réponse du beacon de flotte (POST /api/v1/fleet_position.php) inclut désormais un tableau messages qui transmet les messages en attente du propriétaire vers le chauffeur. Nouveau flux JSON en direct réservé au propriétaire (?ajax=live) et une carte « Messages aux chauffeurs » sur le tableau de bord de la flotte. Nouvelle page d'invitation chauffeur /{lang}/get-nakbus (25 langues).

Titre, description et paramètres de product_fleet_vehicles/live/history, ainsi que les paramètres d'historique de flotte, localisés dans les 25 langues du portail développeurs.

/api/v1/data/truck-bans renvoie désormais le même ensemble de champs de premier niveau, quelle que soit la requête à l'origine de la réponse. Auparavant, une requête pour un pays sans interdictions calendaires, un ppid non reconnu, ou une correspondance normale en base de données pouvaient chacun omettre des champs différents (par ex. country, covered_countries, ppid). Désormais, chaque réponse inclut systématiquement 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 et upcoming_bans (null ou vide lorsque non applicable), ce qui simplifie l'analyse côté client.

Neuf nouveaux produits par service. Ceux liés à la localisation acceptent lat/lon ou city + country (nous géocodons la ville pour vous) : /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 (stations classées par prix pour un type de carburant) et /api/v2/data/internet-points ; les résultats contiennent distance_km et sont limités par radius. /api/v2/data/vignettes indique si un pays exige une vignette, avec les prix actuels. Le produit existant pois prend désormais en charge lon et radius comme documenté, et le mode mode=nearest du produit fuel accepte lui aussi lon. Les neuf sont disponibles dans le sandbox.

Chaque interdiction dans /api/v1/data/truck-bans inclut désormais restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (portée exacte ou routes concernées) et min_weight_tons. details_url pointe désormais vers des pages par pays sur nakordoni.eu. Un nouveau paramètre facultatif lang sélectionne la langue des noms de pays et du résumé ; la langue par défaut est désormais l'anglais.

Un ?ppid= mal formé renvoie désormais la vraie raison au lieu d'un simple "Request failed" : l'erreur nomme le paramètre, le format attendu id_<number> et renvoie vers /api/v1/data/checkpoints. Les tableaux de paramètres de stats, forecast, update-info, weather et bus-carriers affichent maintenant l'exemple id_13 dans les 25 langues.

La nouvelle interface du portail (barre supérieure, barre latérale à icônes, tableau de bord KPI, mises en page en cartes) est désormais l'expérience par défaut pour tous les comptes développeurs connectés — en avance sur le déploiement prévu le 10 août. Utilisez ?v=1 pour revenir à tout moment à la mise en page classique.

Toutes les pages du portail développeur — accueil, documentation, tableau de bord, AI Studio, bac à sable, tickets, demandes, export, flotte, actualités, journal des modifications et pages de compte — ne chargent plus aucun script ni emplacement publicitaire. Cela s'applique à tout le portail, et non plus seulement à la connexion et à l'inscription.

Planifiez tout un trajet transfrontalier en un appel : /api/v2/data/route-plan renvoie l'itinéraire, les points de passage réellement situés dessus avec la file en direct ou une prévision pour votre heure d'arrivée, et les arrêts qu'un conducteur fait vraiment — repos, repas, carburant — sur une seule chronologie.

La frontière fait partie de cette chronologie. Une longue file compte comme la pause déjà due et remet le temps de conduite à zéro : trois heures d'attente ne sont donc jamais présentées comme trois heures plus une série complète de pauses que personne n'a prises. Les voitures suivent un modèle d'hygiène de conduite ; autocars et poids lourds reçoivent le repos obligatoire UE 561/2006, et la charge de service des autocars est calibrée sur plus de 1000 horaires internationaux licenciés. Ajoutez stop_places=1 pour nommer une véritable aire de repos ou station-service à chaque arrêt, et via=lat,lon pour passer par un autre point de passage.

Nouveau dans le menu du portail : Présentation — une présentation vivante et toujours à jour de la plateforme de données nakordoni, personnalisée pour votre marché (assurance, voyage, logistique, transporteurs, médias, navigation, carburant, fintech, secteur public ou projets personnels). Elle affiche les volumes réels de la plateforme sur 30 jours, votre propre consommation d'API, les statistiques de temps de réponse et de limites, ainsi qu'une recommandation d'offre lorsque vos appels atteignent les limites du niveau gratuit. Choisissez ou confirmez votre marché (ou vos marchés) sur la page, dans votre profil — ou lors de l'inscription. Elle s'ouvre automatiquement lors de votre première visite ; l'ouverture automatique peut être désactivée depuis la page elle-même.

Si un assistant a un flux activé mais que l'appel ne transporte pas le contexte dont ce flux a besoin — par exemple queue sans ppid—, le flux est désormais ignoré avant toute requête et n'est pas facturé. Auparavant, il était appelé quand même, échouait et coûtait tout de même une unité. Le studio indique ce dont chaque flux a besoin, recalcule le prix au fur et à mesure que vous complétez le contexte et marque les résultats ✓ exécuté / ⊘ ignoré, non facturé / ✕ échoué ; l'API renvoie data.feeds_skipped , qui vous indique exactement quel paramètre transmettre.

Les réponses ne mentionnent plus les flux, les sources de données ni quoi que ce soit de technique : un flux manquant se traduit au plus par une phrase ordinaire pour l'utilisateur final, jamais par un nom interne. Les flux dotés uniquement de filtres facultatifs (comme fuel restreint à un pays pour lequel nous n'avons pas de données) reviennent désormais au jeu de données large au lieu de ne rien renvoyer.

Nouveau : /{lang}/developers/studio. Créez un assistant IA qui répond à partir de vos contenus et de nos données frontalières en direct. Donnez-nous votre markdown, ou indiquez simplement les pages et nous les récupérons et les indexons — vous ne maintenez jamais que vos propres fichiers. Choisissez les flux qu'il peut utiliser (file d'attente, prévision, alternatives, statistiques journalières, carburant, interdictions poids lourds, dimanches ouvrés, jours fériés, état des routes, transporteurs de bus, POI, devises), choisissez un niveau de modèle (rapide / équilibré / pro — c'est lui qui fixe le prix), rédigez vos propres instructions avec des espaces réservés {{feed.slug}} indiquant précisément où nos données arrivent dans la réponse, et ajoutez votre propre phrase de conclusion, ajoutée à chaque réponse. Modèles prêts à l'emploi : assistant de voyage personnel, assistant travail/fret, assistant de vente d'assurance et de carte verte.

Testez-le dans le studio (30 réponses/jour, indépendamment de votre quota d'API), puis appelez-le en production via GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Prix par réponse = unités du niveau de modèle + 1 unité par flux activé, renvoyé dans X-Devapi-Units. Le produit est réservé à la v2 — une URL v1 renvoie unsupported_version. Le produit existant assistant reste inchangé.

Chaque assistant fonctionne sous une politique de contenu de la plateforme qui prime sur vos instructions : pas d'usurpation d'identité de fonctionnaires, aucune aide pour contourner le contrôle frontalier ou douanier, pas de chiffres inventés, pas de grossièretés. Les instructions comme les réponses sont contrôlées ; les appels bloqués sont journalisés.

Nouveau : un véritable serveur MCP à l'adresse https://nakordoni.eu/mcp, exposant un sous-ensemble sûr, en lecture seule, de l'API (status, checkpoints, border queue, live queue, forecast) sous forme d'outils MCP. Même clé API et même quota que l'API REST. Carte du serveur à l'adresse /.well-known/mcp/server-card.json. Voir la section Serveur MCP dans la documentation.

Le renommage en « Live Queue & Freshness API » décrit ci-dessous n'avait en réalité pas atteint la page de documentation . La page affiche le titre de chaque produit via une recherche de traduction qui ne se rabat sur le titre du point de terminaison que s'il n'existe aucune traduction — or une traduction existait déjà, figée sur l'ancien nom, dans les 25 langues d'interface. Elle l'emporte désormais sur toute future mise à jour du titre sous-jacent, tant qu'elle n'est pas mise à jour elle aussi.

La clé de traduction a été renommée dans les 25 langues, de sorte que la page de documentation correspond. Aucun changement de point de terminaison, de paramètres ni de réponse — uniquement le texte du titre.

Si vous interrogez fréquemment les données de file en direct, vous dépensez peut-être du quota lourd sans nécessité. /update-info est de classe standard et renvoie déjà la valeur en direct :

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

Il renvoie queue_now, freshness, age_minutes, is_realtime, status, timestamp et timezone. Utilisez-le pour les rafraîchissements fréquents sur votre quota journalier standard, et gardez /queue, /multi et /forecast (tous de classe lourde) pour les cas où vous avez besoin de wait_min, des champs de tendance ou de l'historique.

Rien n'a changé dans le point de terminaison lui-même — uniquement dans sa documentation. Il était répertorié comme « Data Freshness API » et sa description ne mentionnait que l'indice de fraîcheur, jamais queue_now, si bien qu'il était facile de passer à côté. Il s'intitule désormais « Live Queue & Freshness API », avec les champs renvoyés détaillés. Merci au développeur qui a soulevé ce point.

Certaines requêtes en échec renvoyaient HTTP 200 avec ok: true et l'erreur enfouie dans data — le motif documenté if (!ok) throw ne pouvait donc pas les détecter, et l'appel était tout de même facturé. Les appels concernés renvoient désormais HTTP 400 avec ok: false et un error.code / error.messageen bonne et due forme, comme documenté. Observé sur fuel-cities avec un pays non pris en charge et sur travel-matrix avec des coordonnées mal formées.

Par ailleurs, un paramètre obligatoire manquant renvoyait 500 internal_error au lieu de 400 bad_request (le corps d'une réponse 4xx du service interne était écarté avant que son statut ne soit lu). Il renvoie désormais 400 bad_request avec le message du service interne — par exemple search sans ?name=.

Les réponses réussies sont inchangées, octet pour octet — mêmes champs, mêmes paramètres, même coût en quota. Si votre client se branche déjà sur ok, rien à changer. S'il ignorait ok et lisait data directement, il verra maintenant des enveloppes d'erreur sur des appels qui échouaient déjà systématiquement.

Correction d'un bug par lequel /multi pouvait renvoyer un nombre de véhicules en file erroné pour certains points de passage — principalement les Balkans et la frontière Hongrie–Serbie — chaque fois que son cache était froid. Le repli lisait une table qui, pour ces passages, ne contient aucune donnée de file, et rapportait des valeurs sans rapport comme nombre de voitures. Exemples mesurés : un point de passage avec 12 voitures en rapportait 6, et plusieurs avec de vraies files en rapportaient 0.

Trois changements que vous pourriez remarquer :

• found: false signifie désormais qu'il n'existe réellement aucune donnée de file récente. Auparavant, vous pouviez recevoir found: true avec un queue_now: 0fabriqué de toutes pièces.
• wait_status, trend_percent et trend_direction sont désormais renvoyés sur les requêtes à froid — ils valaient null auparavant.
• Le point de terminaison bascule aussi sur le repli lorsque son instantané en cache est périmé (plus de 24 h), et non plus seulement lorsqu'il est absent.

Aucun changement dans les paramètres de requête, le coût en quota ou la structure de la réponse.

Correction d'un bug qui faisait facturer chaque appel /multi deux fois — une fois par une vérification générique d'1 unité, puis à nouveau par la propre formule de coût variable de l'endpoint (N PPID × sous-produits). Un appel coûte désormais exactement ⌈(N×M)/2⌉ unités comme documenté, sans facturation supplémentaire.

Un badge de classe de quota (Standard/Heavy) a également été ajouté à chaque produit sur la page de documentation, afin de voir immédiatement quel quota journalier un endpoint utilise.

country et countries fusionnés en un seul paramètre (1-15 codes séparés par des virgules). Nouveau paramètre compare_to : comparaison des jours fériés identiques ou différents entre pays, se combine avec upcoming+days. lang accepte désormais plusieurs langues (ajoute un objet names). days=0 ou omis signifie désormais aucune limite en mode upcoming.

Jours fériés officiels par pays européen — dates, noms locaux et type. Basé sur le même service Nager.Date / OpenHolidaysAPI (avec un calendrier du Kosovo calculé localement) qui alimente la page du calendrier des jours fériés de nakordoni.eu et les facteurs calendaires du système de prévision.

• ?country=PL&year=2026 — liste des jours fériés de l'année complète pour un pays
• ?upcoming=1&days=30 — liste simple des prochains jours fériés entre pays
• Sans paramètre — index d'un ensemble de pays principaux avec le prochain jour férié de chacun

Ajout du produit currency — taux de change basés sur l'EUR pour PLN, CZK, HUF, USD, GBP, CHF, NOK et UAH, fournis par Frankfurter (ECB) et mis en cache pendant 6 heures. Aucun paramètre, renvoie toujours la table complète des taux. Voir la documentation.

Intégrez les interdictions de circulation des poids lourds en Europe en temps réel sur votre propre site web — un widget iframe gratuit avec 3 designs (light, dark, board), 5 langues (en, uk, pl, de, ru), un filtre optionnel par pays et un statut « actif maintenant » en temps réel. Aucune clé API requise. Configurez et copiez le code sur nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Vous préférez les données brutes ? Le produit API truck-bans et le flux JSON public restent disponibles.

Trois ajouts, tous rétrocompatibles — v1 est inchangée.

Versionnage par endpoint. Il existe désormais une URL de base /api/v2/. Elle fonctionne par endpoint : seuls les endpoints qui ont réellement changé se comportent différemment en v2 ; tous les autres endpoints servent de façon transparente leur réponse v1 (ainsi /api/v2/data/queue = les mêmes données qu'en v1, juste avec "api_version":"v2"). Inutile de migrer les endpoints qui fonctionnent.

border v2 est directionnel. L'ordre du chemin correspond au sens du trajet :

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)

Chaque checkpoint gagne également un objet direction {from,to} et un booléen stale, et ?max_age_min=N ne renvoie que les passages récemment mis à jour. (En v1, border renvoie toujours les deux côtés de la frontière quel que soit l'ordre — inchangé.)

Sandbox interactif. Les développeurs connectés peuvent désormais essayer n'importe quel endpoint depuis le navigateur sur Développeurs → Sandbox — choisissez un endpoint, une version et l'une de vos clés, ajustez les paramètres et voyez la réponse en direct. Les tests dans le Sandbox disposent de leur propre budget quotidien distinct (50 appels/jour) et n'affectent jamais votre quota API réel.

La documentation est désormais divisée par endpoint (Développeurs → Documentation API) avec un sélecteur de version sur les endpoints qui en comptent plusieurs.

Deux nouveaux facteurs intégrés à la formule de temps d'attente, en plus des ajustements existants section_mode et météo :

• service_rate — nombre de voitures/min actuellement traitées, mesuré par rapport au taux de référence configuré du checkpoint. Multiplicatif, borné entre 0.5x et 1.5x.
• shift_change — impact du changement d'équipe des gardes-frontières à 08:00/20:00, propre à chaque checkpoint. Additif (minutes), non multiplicatif — appliqué uniquement dans une fenêtre de +/-60 minutes autour d'un changement d'équipe, nécessite un historique d'échantillons minimum, plafonné à +/-120 minutes.

advanced_wait_min vaut désormais round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Les deux facteurs sont également reflétés dans driver_reported.prognosed_advanced_wait_min pour les comparaisons historiques.

Dans le cadre d'une revue de sécurité et de confidentialité, les champs suivants ont été supprimés — ils exposaient des détails d'implémentation internes (la taxonomie de nos sources de données en amont, les identifiants de lignes en base de données, des annotations internes du pipeline, des champs inutilisés ou morts) sans réelle valeur produit :

• id et corrected — supprimés des objets de ligne de queue
• source (chaîne brute, par ex. "line") — supprimé de queue, multi et update-info. Le bloc update_info de update-info et de multi conserve source_category/source_label_en (un petit vocabulaire public) ; le bloc queue de queue et de multi ne contient plus aucun champ source
• traffic_status — supprimé de border ; il valait toujours null et n'était jamais renseigné par aucune partie du système

Si votre intégration lit l'un de ces champs, veuillez la mettre à jour — consultez la liste actuelle des champs sur la page de documentation du produit concerné.

L'utilisation du quota quotidien (usage.used dans chaque réponse) peut désormais être une valeur décimale (par ex. 67.5) au lieu d'être toujours un entier. C'est un effet secondaire de la facturation de queue-advanced à un taux fractionnaire — voir ci-dessous. usage.limit n'est pas affecté et reste toujours un entier. Si votre client type strictement usage.used comme un entier, veuillez l'élargir pour accepter un nombre décimal / à virgule flottante.

Ces trois produits renvoient désormais les mêmes champs de statut en temps réel que ceux affichés sur le site web : wait_status (green/yellow/red, basé sur l'historique récent propre à ce checkpoint) et trend_percent/trend_direction (up/up-slight/down/down-slight/stable, en comparant les 3 dernières heures). Purement additif.

Les lignes data[] de /api/v1/data/queue avaient auparavant wait_time: null pour la plupart des sources — seuls quelques flux en amont indiquent directement un temps d'attente. Les lignes qui n'en ont pas reçoivent désormais l'estimation standard , signalée par un nouveau booléen wait_time_estimated afin que vous puissiez distinguer une valeur réellement rapportée d'une valeur calculée.

queue-advanced coûte désormais 1.5 units par appel au lieu de 1 (ce qui reflète les recherches supplémentaires de trafic, de météo et de rapports de conducteurs qu'il effectue) — voir usage.used ci-dessus. La réponse n'inclut également plus total_crossing_time, et driver_reported se limite désormais à {wait_min, ts, age_min} — les anciens champs de comparaison prévision/réalité (prognosed_wait_min, diff_min, historical_section_mode, historical_weather, etc.) ont été supprimés. section_mode, weather, advanced_wait_min et exceeds_crossing_time sont inchangés.

/api/v1/data/truck-bans renvoie désormais, pour chaque pays dans bans_by_country, un status (active/clear) ainsi que active_window, next_window, local_time et tz — calculés dans le fuseau horaire propre à ce pays, de sorte que vous n'avez plus à évaluer vous-même les fenêtres d'interdiction brutes par rapport à une horloge. La réponse ajoute également une liste covered_countries au niveau supérieur et un horodatage UTC as_of.

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

Purement additif — les champs existants current_bans/upcoming_bans/bans_by_country sont inchangés. Un ?country= inconnu renvoie désormais un résultat vide avec countries_not_covered au lieu des interdictions de tous les pays.

Un nouveau produit optionnel qui ajuste le temps d'attente standard en fonction du flux de trafic en temps réel et de la météo. Renvoie le détail complet de chaque ajustement.

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

Accordé sur demande — ouvrez un ticket Data depuis votre tableau de bord pour l'activer.

/api/v1/data/border calcule désormais correctement wait_min pour chaque checkpoint de la réponse, comme les produits queue et multi. Auparavant, ce champ valait toujours null.

/api/v1/data/forecast utilise désormais de façon fiable le modèle d'ensemble v4 pour toute valeur de prediction_steps (auparavant, certains horizons non standard pouvaient basculer silencieusement vers un modèle plus ancien). Le facteur météo qui alimente l'ensemble est également corrigé et reflète désormais réellement les conditions en temps réel (pluie, neige, vent, brouillard) au lieu de toujours indiquer indisponible.

Les développeurs approuvés peuvent désormais télécharger les données historiques de files d'attente aux frontières, moyennées à l'heure, pour un maximum de 5 checkpoints (fenêtre glissante jusqu'à 90 jours) au format CSV ou NDJSON depuis le nouvel onglet Data export. Les données sont uniquement publiées et vérifiées en qualité ; les horodatages sont en UTC. Besoin d'un accès ? Ouvrez un ticket Data.

Pas encore de site web ? Vous pouvez désormais créer un compte développeur en décrivant où et comment vous prévoyez d'utiliser nos données, au lieu d'être obligé de saisir l'URL d'une page en ligne. Ajoutez la véritable URL plus tard depuis votre tableau de bord (Compte & données → Votre projet) dès que votre site ou application est en ligne — un lien visible renvoyant vers nakordoni.eu sur cette page est requis par nos Conditions.

Les développeurs peuvent désormais soumettre leurs propres actualités liées aux frontières au fil d'actualités Nakordoni. Si nos éditeurs la publient, vous obtenez un backlink dofollow indexable vers votre service (signature de l'éditeur + ligne de source) et nous traduisons l'article dans les 24 langues gratuitement.

Un article par semaine est gratuit ; les articles supplémentaires sont une option payante. Choisissez 'nous pouvons légèrement modifier + ajouter des liens internes' ou 'publier tel quel'. Soumettez et suivez le statut de révision sous Développeurs → Soumettre une actualité.

La Multi-Checkpoint API (/api/v1/data/multi) facture désormais le quota à ⌈(N PPIDs × sous-produits) / 2⌉ — la moitié du coût d'appels individuels équivalents. Une requête pour 10 checkpoints avec les deux sous-produits coûte désormais 10 units au lieu de 20. L'en-tête X-Devapi-Units et meta.units_consumed dans la réponse reflètent le montant réduit.

Récupérez l'état des files d'attente en temps réel et la fraîcheur des données pour un maximum de 20 checkpoints en un seul appel API — conçu pour les créateurs de tableaux de bord qui interrogent actuellement de nombreux PPIDs en boucle.

Le quota est compté de façon équitable comme N PPIDs × sous-produits demandés, de sorte que l'utilisation totale est identique à celle d'appels individuels — mais avec un seul aller-retour au lieu de plusieurs. Les schémas de type GreenTravel passent de plus de 24 appels/heure à 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 actuel, wait_min estimé, âge des données et nom du checkpoint
• include=update-info — fraîcheur des données, classification de la source, âge en secondes/minutes
• Maximum 20 PPIDs par requête ; combinez les deux sous-produits en un seul appel pour obtenir toutes les données du tableau de bord
• La réponse inclut meta.units_consumed afin que vous puissiez suivre précisément l'utilisation du quota

La réponse du produit queue inclut désormais un objet snapshot de niveau supérieur avec les données en temps réel les plus récentes et un temps d'attente prévu et calculé — la même formule que celle utilisée dans la section héros de 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

Le tableau data (entrées historiques) est inchangé — il s'agit d'un ajout purement additif. Les clients qui ne lisent pas snapshot ne sont pas affectés.

Interrogez tous les checkpoints d'une frontière + type de véhicule donnés en un seul appel au lieu de faire une requête par PPID.

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

• Prend en charge un seul pays de destination, une liste séparée par des virgules, ou all pour l'étendre à tous les voisins surveillés en une fois.
• Résultats triés par queue_now croissant (la file la plus courte en premier).
• Entièrement localisé : ajoutez ?lang=uk (ou l'une de nos 22 langues prises en charge) pour obtenir les noms des checkpoints dans cette langue.

Découvrez les valeurs PPID des checkpoints par nom sans parcourir l'annuaire complet.

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

• Accepte un seul nom ou une liste séparée par des virgules (jusqu'à 20).
• Recherche dans les 24 langues de traduction — indiquez un nom en ukrainien, polonais, allemand ou toute autre langue prise en charge et il correspondra.
• Renvoie tous les PPIDs de ce lieu regroupés par type de véhicule (voiture / bus / piéton / camion).

Le produit alternatives accepte désormais ?lang= dans les 22 langues prises en charge (contre 12 auparavant).

Le nouveau paramètre crossing_type vous permet de remplacer le filtre de type de véhicule — par ex. passez crossing_type=4 pour obtenir des alternatives voiture même en interrogeant depuis un PPID bus.

Le champ crossing_type_label dans les réponses de checkpoints, border et search est désormais traduit dans la langue demandée, dans les 22 langues prises en charge. Les champs de nom de pays (origin_name, destination_name) suivent la même locale.

Le portail API développeur de Nakordoni est en ligne à l'adresse /en/developers. Inscrivez-vous pour obtenir une clé Explorer gratuite (200 requêtes/jour) afin d'accéder aux données de files d'attente aux frontières, aux prévisions, aux prix des carburants, aux POIs pour conducteurs et bien plus encore.

Produits disponibles au lancement : checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.