Journal des modifications de l'API

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.

The retitle to "Live Queue & Freshness API" below did not actually reach the docs page. The page renders each product title through a translation lookup that falls back to the endpoint's title only when no translation exists — and a translation already existed, frozen at the old name, in all 25 UI languages. It now wins over any future update to the underlying title until it is updated too.

Retitled the translation key in all 25 languages so the docs page matches. No endpoint, parameter or response change — title text only.

If you poll live queue data frequently, you may be spending heavy quota you do not need to. /update-info is standard-class and already returns the live figure:

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

It returns queue_now, freshness, age_minutes, is_realtime, status, timestamp and timezone. Use it for the frequent refresh against your standard daily quota, and keep /queue, /multi and /forecast (all heavy-class) for when you need wait_min, the trend fields or history.

Nothing changed in the endpoint itself — only its documentation. It was listed as the "Data Freshness API" and its description mentioned only the freshness rating, never queue_now, so it was easy to miss. It is now titled "Live Queue & Freshness API" with the returned fields spelled out. Thanks to the developer who raised this.

Some failed requests were returning HTTP 200 with ok: true and the error buried inside data — so the documented if (!ok) throw pattern could not detect them, and the call was still billed. Affected calls now return HTTP 400 with ok: false and a proper error.code / error.message, as documented. Seen on fuel-cities with an unsupported country and travel-matrix with malformed coordinates.

Separately, a missing required parameter returned 500 internal_error instead of 400 bad_request (an upstream 4xx body was being discarded before its status was read). It now returns 400 bad_request with the upstream message — e.g. search without ?name=.

Successful responses are byte-for-byte unchanged — same fields, same params, same quota cost. If your client already branches on ok, no change is needed. If it ignored ok and read data directly, it will now see error envelopes on calls that were always failing.

Fixed a bug where /multi could return a wrong queue count for some checkpoints — mainly Balkan and Hungary–Serbia crossings — whenever its cache was cold. The fallback read a table that, for those crossings, holds no queue data, and reported unrelated values as car counts. Measured examples: a checkpoint with 12 cars reported 6, and several with real queues reported 0.

Three changes you may notice:

• found: false now means there is genuinely no recent queue data. Previously you could receive found: true with a fabricated queue_now: 0.
• wait_status, trend_percent and trend_direction are now returned on cold requests — they were null before.
• The endpoint also falls back when its cached snapshot is stale (older than 24h), not only when it is missing.

No changes to request parameters, quota cost or response shape.

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
• tmin/tpercar — supprimés de queue, border et multi (les constantes de la formule de temps d'attente ; les valeurs déjà calculées wait_min/wait_time ne sont pas affectées)
• 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 tmin + queue×tpercar, 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 tmin, tpercar ni 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 (et renvoie tmin/tpercar) 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   — tmin + queue_now × tpercar (minutes)
snapshot.tmin       — minimum crossing time (minutes)
snapshot.tpercar    — added time per vehicle (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.