Journal des modifications de l'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'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   — (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.