Registro de cambios de la API

Novedad: un servidor MCP real en https://nakordoni.eu/mcp, que expone un subconjunto seguro, de solo lectura, de la API (status, checkpoints, border queue, live queue, forecast) como herramientas MCP. Misma clave API y cuota que la API REST. Tarjeta del servidor en /.well-known/mcp/server-card.json. Consulta la seccion Servidor MCP en la documentacion.

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.

Se corrigió un error por el cual cada llamada a /multi se facturaba dos veces — una vez mediante una comprobación genérica de 1 unidad y otra vez mediante la propia fórmula de costo variable del endpoint (N PPID × subproductos). Ahora una llamada cuesta exactamente ⌈(N×M)/2⌉ unidades según lo documentado, sin cargo adicional.

También se añadió una insignia de clase de cuota (Standard/Heavy) a cada producto en la página de documentación, para que quede claro de un vistazo qué cuota diaria consume un endpoint.

country y countries fusionados en un solo parámetro (1-15 códigos separados por comas). Nuevo parámetro compare_to: comparación de días festivos iguales o diferentes entre países, se combina con upcoming+days. lang ahora acepta varios idiomas (añade un objeto names). days=0 u omitido ahora significa sin límite en modo upcoming.

Días festivos oficiales por país europeo — fechas, nombres locales y tipo. Respaldado por el mismo servicio Nager.Date / OpenHolidaysAPI (con un calendario de Kosovo calculado localmente) que impulsa la página del calendario de días festivos de nakordoni.eu y los factores de calendario del sistema de predicción.

• ?country=PL&year=2026 — lista de días festivos del año completo para un país
• ?upcoming=1&days=30 — lista simple de los próximos días festivos entre países
• Sin parámetros — índice de un conjunto de países principales con el siguiente día festivo de cada uno

Añadido el producto currency — tipos de cambio basados en el EUR para PLN, CZK, HUF, USD, GBP, CHF, NOK y UAH, obtenidos de Frankfurter (ECB) y almacenados en caché durante 6 horas. Sin parámetros, siempre devuelve la tabla completa de tipos. Consulta la documentación.

Integra las prohibiciones de circulación de camiones en Europa en tiempo real en tu propio sitio web — un widget iframe gratuito con 3 diseños (light, dark, board), 5 idiomas (en, uk, pl, de, ru), un filtro opcional por país y un estado «activo ahora» en tiempo real. No se necesita clave API. Configura y copia el código en nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. ¿Prefieres los datos en bruto? El producto API truck-bans y el feed JSON público siguen disponibles.

Tres novedades, todas retrocompatibles — v1 no cambia.

Versionado por endpoint. Ahora existe una URL base /api/v2/. Es por endpoint: solo los endpoints que realmente cambiaron se comportan de forma diferente en v2; todos los demás endpoints sirven de forma transparente su respuesta v1 (así /api/v2/data/queue = los mismos datos que v1, solo con "api_version":"v2"). No es necesario migrar los endpoints que funcionan.

border v2 es direccional. El orden de la ruta es el sentido del viaje:

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)

Cada checkpoint obtiene además un objeto direction {from,to} y un booleano stale, y ?max_age_min=N devuelve solo los pasos actualizados recientemente. (En v1, border sigue devolviendo ambos lados de la frontera sin importar el orden — sin cambios.)

Sandbox interactivo. Los desarrolladores que han iniciado sesión ahora pueden probar cualquier endpoint desde el navegador en Desarrolladores → Sandbox — elige un endpoint, una versión y una de tus claves, ajusta los parámetros y ve la respuesta en vivo. Las pruebas en el Sandbox tienen su propio presupuesto diario independiente (50 llamadas/día) y nunca afectan tu cuota real de la API.

La documentación ahora está dividida por endpoint (Desarrolladores → Documentación de la API) con un selector de versión en los endpoints que tienen más de una versión.

Dos nuevos factores integrados en la fórmula de tiempo de espera, junto con los ajustes existentes section_mode y de clima:

• service_rate — coches/min que se están procesando actualmente, medidos frente a la tasa de referencia configurada del checkpoint. Multiplicativo, limitado entre 0.5x y 1.5x.
• shift_change — impacto del cambio de turno de los guardias fronterizos a las 08:00/20:00, propio de cada checkpoint. Aditivo (minutos), no multiplicativo — se aplica solo dentro de +/-60 minutos de un cambio de turno, requiere un historial mínimo de muestras, limitado a +/-120 minutos.

advanced_wait_min ahora es round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Ambos factores también se reflejan en driver_reported.prognosed_advanced_wait_min para comparaciones históricas.

Como parte de una revisión de seguridad y privacidad, se han eliminado los siguientes campos — exponían detalles internos de implementación (la taxonomía de nuestras fuentes de datos originales, los ID de filas de la base de datos, anotaciones internas del pipeline, campos sin uso o muertos) sin valor real para el producto:

• id y corrected — eliminados de los objetos de fila de queue
• tmin/tpercar — eliminados de queue, border y multi (las constantes de la fórmula de tiempo de espera; los valores ya calculados wait_min/wait_time no se ven afectados)
• source (cadena en bruto, p. ej. "line") — eliminado de queue, multi y update-info. El bloque update_info de update-info y de multi sigue incluyendo source_category/source_label_en (un pequeño vocabulario público); el bloque queue de queue y de multi ya no incluye ningún campo source
• traffic_status — eliminado de border; siempre era null y ninguna parte del sistema lo rellenaba

Si tu integración lee alguno de estos campos, actualízala — consulta la lista actual de campos en la página de documentación del producto correspondiente.

El uso de la cuota diaria (usage.used en cada respuesta) ahora puede ser un valor decimal (p. ej. 67.5) en lugar de ser siempre un número entero. Es un efecto secundario de que queue-advanced se factura a una tarifa fraccionaria — ver más abajo. usage.limit no se ve afectado y siempre es un número entero. Si tu cliente tipa estrictamente usage.used como entero, amplíalo para aceptar un decimal / float.

Estos tres productos ahora devuelven los mismos campos de estado en tiempo real que muestra el sitio web: wait_status (green/yellow/red, basado en el historial reciente propio de este checkpoint) y trend_percent/trend_direction (up/up-slight/down/down-slight/stable, comparando las últimas 3 horas). Puramente aditivo.

Las filas data[] de /api/v1/data/queue tenían anteriormente wait_time: null para la mayoría de las fuentes — solo unos pocos feeds originales informan directamente de un tiempo de espera. Las filas que no tienen uno ahora reciben la estimación estándar tmin + queue×tpercar, marcada con un nuevo booleano wait_time_estimated para que puedas distinguir una cifra realmente informada de una calculada.

queue-advanced ahora cuesta 1.5 units por llamada en lugar de 1 (lo que refleja las búsquedas adicionales de tráfico, clima e informes de conductores que realiza) — ver usage.used arriba. La respuesta tampoco incluye ya tmin, tpercar ni total_crossing_time, y driver_reported ahora es solo {wait_min, ts, age_min} — los anteriores campos de comparación previsión/realidad (prognosed_wait_min, diff_min, historical_section_mode, historical_weather, etc.) se han eliminado. section_mode, weather, advanced_wait_min y exceeds_crossing_time no cambian.

/api/v1/data/truck-bans ahora devuelve, para cada país en bans_by_country, un status (active/clear) más active_window, next_window, local_time y tz — calculados en la zona horaria propia de ese país, de modo que ya no tienes que evaluar tú mismo las ventanas de prohibición en bruto frente a un reloj. La respuesta también añade una lista covered_countries de nivel superior y una marca de tiempo UTC as_of.

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

Puramente aditivo — los campos existentes current_bans/upcoming_bans/bans_by_country no cambian. Un ?country= desconocido ahora devuelve un resultado vacío con countries_not_covered en lugar de las prohibiciones de todos los países.

Un nuevo producto opcional que ajusta el tiempo de espera estándar según el flujo de tráfico en tiempo real y el clima. Devuelve el desglose completo de cada ajuste.

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

Concedido bajo solicitud — abre un ticket de Data desde tu panel para activarlo.

/api/v1/data/border ahora calcula correctamente wait_min (y devuelve tmin/tpercar) para cada checkpoint en la respuesta, igual que los productos queue y multi. Anteriormente este campo siempre era null.

/api/v1/data/forecast ahora usa de forma fiable el modelo de conjunto v4 para cualquier valor de prediction_steps (anteriormente algunos horizontes no estándar podían recurrir silenciosamente a un modelo más antiguo). El factor de clima que alimenta el conjunto también se ha corregido y ahora refleja realmente las condiciones en tiempo real (lluvia, nieve, viento, niebla) en lugar de informar siempre como no disponible.

Los desarrolladores aprobados ahora pueden descargar datos históricos de colas fronterizas, promediados por hora, para un máximo de 5 checkpoints (ventana móvil de hasta 90 días) en formato CSV o NDJSON desde la nueva pestaña Data export. Los datos son solo publicados y verificados en calidad; las marcas de tiempo están en UTC. ¿Necesitas acceso? Abre un ticket de Data.

¿Aún no tienes un sitio web? Ahora puedes crear una cuenta de desarrollador describiendo dónde y cómo planeas usar nuestros datos, en lugar de verte obligado a introducir la URL de una página en vivo. Añade la URL real más tarde desde tu panel (Cuenta & datos → Tu proyecto) en cuanto tu sitio o aplicación esté en línea — un enlace visible hacia nakordoni.eu en esa página es obligatorio según nuestros Términos.

Los desarrolladores ahora pueden enviar sus propias noticias relacionadas con las fronteras a la línea de noticias de Nakordoni. Si nuestros editores la publican, obtienes un backlink dofollow indexable hacia tu servicio (firma del editor + línea de fuente) y traducimos el artículo a los 24 idiomas de forma gratuita.

Un artículo por semana es gratis; los artículos adicionales son un complemento de pago. Elige 'podemos editar ligeramente + añadir enlaces internos' o 'publicar tal cual'. Envía y sigue el estado de revisión en Desarrolladores → Enviar noticia.

La Multi-Checkpoint API (/api/v1/data/multi) ahora factura la cuota a ⌈(N PPIDs × subproductos) / 2⌉ — la mitad del coste de llamadas individuales equivalentes. Una solicitud de 10 checkpoints con ambos subproductos ahora cuesta 10 units en lugar de 20. La cabecera X-Devapi-Units y meta.units_consumed en la respuesta reflejan el importe con descuento.

Obtén el estado de las colas en tiempo real y la frescura de los datos para un máximo de 20 checkpoints en una sola llamada API — diseñado para creadores de paneles que actualmente consultan muchos PPIDs en un bucle.

La cuota se cuenta de forma justa como N PPIDs × subproductos solicitados, por lo que el uso total es idéntico al de llamadas individuales — pero con un solo viaje de ida y vuelta en lugar de muchos. Los patrones tipo GreenTravel bajan de más de 24 llamadas/hora a 2.

GET /api/v1/data/multi?ppids=id_2,id_13,id_15,id_59&include=queue,update-info&lang=en

• include=queue — queue_now actual, wait_min estimado, antigüedad de los datos y nombre del checkpoint
• include=update-info — frescura de los datos, clasificación de la fuente, antigüedad en segundos/minutos
• Máximo 20 PPIDs por solicitud; combina ambos subproductos en una sola llamada para obtener todos los datos del panel
• La respuesta incluye meta.units_consumed para que puedas seguir con precisión el uso de la cuota

La respuesta del producto queue ahora incluye un objeto snapshot de nivel superior con los datos en tiempo real más recientes y un tiempo de espera previsto y calculado — la misma fórmula usada en la sección hero 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

El array data (entradas históricas) no cambia — se trata de una adición puramente aditiva. Los clientes que no leen snapshot no se ven afectados.

Consulta todos los checkpoints de una frontera + tipo de vehículo dados en una sola llamada en lugar de hacer una solicitud por cada PPID.

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

• Admite un solo país de destino, una lista separada por comas, o all para expandirlo a todos los vecinos monitorizados a la vez.
• Resultados ordenados por queue_now ascendente (la cola más corta primero).
• Totalmente localizado: añade ?lang=uk (o cualquiera de nuestros 22 idiomas admitidos) para obtener los nombres de los checkpoints en ese idioma.

Descubre los valores PPID de los checkpoints por nombre sin navegar por el directorio completo.

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

• Acepta un solo nombre o una lista separada por comas (hasta 20).
• Busca en los 24 idiomas de traducción — introduce un nombre en ucraniano, polaco, alemán o cualquier idioma admitido y coincidirá.
• Devuelve todos los PPIDs de esa ubicación agrupados por tipo de vehículo (coche / bus / peatón / camión).

El producto alternatives ahora acepta ?lang= en los 22 idiomas admitidos (antes solo 12).

El nuevo parámetro crossing_type te permite anular el filtro de tipo de vehículo — p. ej. pasa crossing_type=4 para obtener alternativas de coche incluso al consultar desde un PPID de bus.

El campo crossing_type_label en las respuestas de checkpoints, border y search ahora se traduce al idioma solicitado, en los 22 idiomas admitidos. Los campos de nombre de país (origin_name, destination_name) siguen la misma configuración regional.

El portal de API para desarrolladores de Nakordoni está disponible en /en/developers. Regístrate para obtener una clave Explorer gratuita (200 solicitudes/día) para acceder a los datos de colas fronterizas, previsiones, precios de combustible, POIs para conductores y mucho más.

Productos disponibles en el lanzamiento: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.