Registro de cambios de la API

Nuevo producto lane-cost-index (GET /api/v2/data/lane-cost-index). Devuelve el índice de coste de un viaje cargado de un camión de A a B en Europa: combustible, peajes, tiempo del conductor y dietas.

• Entrada: from y to como "lat,lng" o id de ciudad, vehicle (por ejemplo artic_40t), opcionales euro, co2_class y empty_return.
• Por país: km, peaje, litros de gasóleo y coste del combustible (sin IVA), y la clase de vehículo aplicada en el peaje.
• Tiempo del conductor: conducción, pausas y descansos siguen las normas UE 561/2006. El coste del conductor y las dietas usan la tarifa del país de origen. España e Italia tienen ahora una tarifa de conductor y unas dietas de los convenios colectivos.
• Tendencia: trend da el índice de coste del mes actual y de los dos meses anteriores.
• Datos incompletos: cuando un país de la ruta no tiene datos de peajes o combustible, o el país de origen no tiene tarifa de conductor, incomplete es true y el total es un límite inferior. missing_countries y missing_components indican qué falta.

Es un índice de coste, no un precio de transporte: el capital del vehículo, el seguro, los gastos generales y el margen no están incluidos.

Cuota: una solicitud cuenta como 1 unidad de la clase route, igual que truck-route.

Documentación: Lane Cost Index.

El producto toll-cost calcula con más precisión Francia, España e Italia.

• Francia y España: un tramo de autopista entre dos peajes de la ruta se calcula con la tarifa de entrada/salida de la concesionaria. Aparece como un nuevo tipo de elemento motorway_section con la concesionaria o la carretera, los dos peajes, toll_km y cost_eur. Los demás km de peaje del país siguen usando la media por km.
• Clase del vehículo: Francia: clase 3 para 2 ejes y clase 4 para 3 o más ejes. España: Pesados 1 para 2 o 3 ejes y Pesados 2 para 4 o más ejes.
• Italia: los camiones de 2 y 3 ejes tienen ahora sus propias tarifas por km.
• Clase Euro y CO2: las tarifas de Francia, Italia y España no dependen de estas clases. Si envías euro o co2_class, class_fallback es false para estos países y class_note indica el motivo.
• Sin carretera de peaje: una ruta por España sin carretera de peaje (por ejemplo Zaragoza – Barcelona) devuelve España con cost_eur 0 y scheme not_tolled.

Los demás países no cambian. Documentación: Truck Toll Cost.

Nuevo producto toll-cost (POST /api/v2/data/toll-cost, cuerpo JSON). Devuelve el coste de los peajes de camión de una ruta por Europa.

• Entrada: la línea de la ruta como coordinates (por ejemplo la geometría de truck-route), o waypoints que calculamos con nuestro enrutamiento para camiones.
• Vehículo: axles, gross_weight_t, euro y co2_class. Opcionales date para las tarifas y currency para el total.
• Por país: km de peaje, tarifa efectiva en EUR por km, coste, la clase de vehículo tarificada y la fecha de la tarifa. Las tarifas específicas de clase Euro y CO2 se usan donde existe una tarifa oficial para esa clase. Si no, se usa la tarifa de la clase por defecto y class_fallback es true.
• Partidas separadas: tramos de autopista en concesión, y túneles y puentes con su propio peaje para camiones (por ejemplo Calafat-Vidin).

Cuota: una solicitud cuenta como 1 unidad de la clase route, igual que truck-route.

Documentación: Truck Toll Cost.

Dos nuevos productos en /api/v2. Para un viaje en autocar indican qué lado tiene sol o sombra y qué asientos son mejores para la sombra o para las vistas.

• bus-sun-side (/api/v2/data/bus-sun-side), GET: una ruta de nuestro registro de líneas de autobús (route_id, dir, date) o un viaje libre (from, to, depart).
• bus-sun-side, POST: envíe su propia ruta como lista de paradas, línea GeoJSON o polilínea codificada. Añada los parámetros del autocar (filas, distribución de asientos, lado de la puerta, ventanas, planta) o elija un modelo del catálogo con bus_model.
• Tiempo: para viajes en los próximos 3 días se usa la previsión horaria a lo largo de la ruta. Los viajes posteriores se calculan con cielo despejado. Envíe weather=0 para obtener siempre el resultado con cielo despejado.
• Imágenes (POST): plano de asientos, mapa de la ruta y cronología como URL en PNG, WebP o JPG. Las imágenes se guardan 12 horas. También recibe embed_html para mostrar el resultado en su página. Las URL de las imágenes empiezan por https://api.nakordoni.dev/images/.
• Animación: el bloque animation contiene un fotograma cada 5 minutos con la posición del autocar, el rumbo, el acimut y la altura del sol y el lado soleado, con etiquetas en su idioma, totales por lado y una leyenda. Envíe animation=0 para omitirlo.
• Widget: muestre el resultado en cualquier sitio web, incluido WordPress, con una etiqueta script o un iframe. El widget usa una clave pública que solo funciona en los orígenes que usted permita, y nuestras propias teselas de mapa. Hay un plugin de WordPress (zip) disponible.
• bus-sun-catalog (/api/v2/data/bus-sun-catalog): los modelos de autocar que acepta bus-sun-side, con su distribución de asientos y ventanas.

Cuota: una solicitud POST con imágenes cuenta como 2 unidades. Todas las demás solicitudes cuentan como 1 unidad.

Documentación: Bus Sun Side.

fleet-compliance-validate ahora cubre una parte mayor del Reglamento (CE) 561/2006 modificado por el Reglamento (UE) 2020/1054. Los campos de respuesta existentes no cambian; se añaden campos nuevos.

• Excepción del Art. 12: marque las actividades de conducción con art12_exceed: true. En casos excepcionales, un conductor puede superar los límites de conducción diaria y semanal hasta 1 h para llegar al centro operativo o a su domicilio y tomar un descanso semanal, o hasta 2 h tras una pausa de 30 min cuando sigue un descanso semanal regular. El validador lo acepta y devuelve la compensación debida y su plazo (el final de la tercera semana siguiente) en remaining.driving.art12_compensation y exceptions.art12.
• Art. 8(8a) regreso a la base: envíe location (residence, operational_centre o elsewhere) en los descansos semanales. Recibirá una advertencia cuando pasen 4 semanas consecutivas sin un descanso semanal regular en el domicilio o en el centro operativo.
• Art. 8(6a) excepción de 12 días: passenger_12day: true para un único servicio internacional ocasional de autocar. El descanso semanal puede entonces tomarse hasta doce períodos de 24 horas después de un descanso semanal regular. Se comprueban los descansos posteriores y la conducción nocturna (22:00-06:00). El Art. 8(6)(b) del AETR se aplica del mismo modo.
• Franjas nocturnas nacionales (Directiva 2002/15/CE Art. 3(h)): use country o wtd.country para aplicar el período nocturno nacional. Verificados: AT, IE (pasajeros por separado) y SE. Los demás países de la UE/EEE usan 00:00-04:00 y devuelven night_window_verified: false.
• fleet-compliance-limits: el AETR ahora enumera las modificaciones posteriores a 2010 que se han comprobado. Solo cambian el artículo 14, no las normas de conducción ni de descanso.

Documentación: Fleet Compliance.

Cuatro nuevos productos, servidos desde /api/v2 y calculados por nuestro propio motor de reglas de festivos para 51 países (Europa y el Golfo: SA, AE, QA, KW, BH, OM), 2020-2035:

• holiday-calendar-holidays (/api/v2/data/holiday-calendar/holidays) — festivos públicos, bancarios, regionales, religiosos y días conmemorativos para hasta 10 países en un año o un rango de fechas. Cada festivo indica si es un día no laborable, un festivo bancario o si cae dentro de las vacaciones escolares, si un festivo de fin de semana se trasladó a otro día, si una fecha del calendario islámico sigue siendo estimada y si ese día se aplica una prohibición de circulación de camiones (truck_ban). Filtre por región (region=DE-BY), tipo, idioma y nombre; school=1 añade las vacaciones escolares.
• holiday-calendar-business-days (/api/v2/data/holiday-calendar/business-days) — cuenta los días laborables entre dos fechas, suma o resta días laborables, comprueba una fecha o encuentra el siguiente o anterior día laborable. Utiliza el fin de semana del país (sábado-domingo, o viernes-sábado y otros fines de semana en el Golfo), los días no laborables nacionales y regionales y los traslados de días por decreto.
• holiday-calendar-countries (/api/v2/data/holiday-calendar/countries) — los países cubiertos con sus días de fin de semana, zona horaria, regiones y tipos de festivos; con country= también los días laborables por año y los próximos cinco festivos.
• holiday-calendar-impact (/api/v2/data/holiday-calendar/impact, plan Pro y superiores) — impacto empresarial estimado por modelo: una puntuación de impacto de 0-100 por festivo, probabilidad de cierre de comercios, categorías de demanda, posición de fin de semana largo y puente, y ventanas de aumento de demanda. En holiday-calendar-holidays, los planes Pro y superiores también obtienen este bloque con include=impact y pueden filtrar con min_impact.

El producto existente holiday-calendar no cambia. Documentación: Holiday Calendar.

Tres nuevos productos para el cumplimiento de los tiempos de conducción, servidos desde /api/v2:

• fleet-compliance-validate (POST /api/v2/data/fleet/compliance/validate, cuerpo JSON) — comprueba la actividad registrada del conductor según EU 561/2006 o AETR y el tiempo de trabajo de la Directive 2002/15/EC. Devuelve cada infracción con el artículo de la norma y su banda de gravedad, y lo que le queda ahora al conductor: conducción diaria, los límites móviles de 56 h semanales y 90 h bisemanales, la próxima pausa, y el descanso diario y semanal. Cubre pausas fraccionadas, jornadas reducidas y ampliadas, compensación del descanso semanal reducido, trabajo nocturno, doble tripulación y descanso interrumpido por ferry o tren.
• fleet-compliance-limits (/api/v2/data/fleet/compliance/limits) — los parámetros de las normas para EU 561, AETR (con sus diferencias respecto a 561) y 2002/15, además de las bandas de gravedad del Regulation (EU) 2016/403.
• fleet-compliance-plan-check (POST /api/v2/data/fleet/compliance/plan-check, cuerpo JSON) — comprueba los turnos planificados antes del despacho frente a las prohibiciones de circulación de camiones, los festivos y los días de fin de semana en los países del viaje, y frente a las normas EU 561, AETR y 2002/15. Cada turno recibe la hora de inicio legal más temprana.

Documentación: Fleet Compliance.

Desde la v3, las paradas de descanso diario y semanal tienen los campos in_vehicle_allowed, accommodation_required y rule (route-plan con rest_rules=eu561 y truck-route). El Reglamento (UE) 2020/1054 modificó el art. 8, apdo. 8 del EU 561/2006: el descanso semanal normal y cualquier descanso semanal de más de 45 h no se pueden tomar en el vehículo. Para estas paradas, in_vehicle_allowed = false. El descanso semanal reducido (de 24 h a menos de 45 h) y el descanso diario se pueden tomar en un vehículo detenido con litera.

Las paradas de descanso semanal también tienen accommodation[] — aparcamientos con habitaciones en el lugar cerca de la parada — y el aparcamiento de la parada tiene has_accommodation. Es solo información: la parada, su hora y su aparcamiento para camiones no cambian. Si no se conoce ningún lugar con habitaciones, la parada tiene warning = no_accommodation_found. Las respuestas v1 y v2 no cambian.

Los precios de estaciones en /api/v2/data/fuel-stations, /api/v2/data/fuel-cheapest, /api/v2/data/fuel-local y /api/v2/data/fuel con mode=nearest tienen ahora una antigüedad máxima de 90 días. Un precio que confirmamos por última vez hace más de 90 días ya no se devuelve. Antes, un precio así se devolvía con stale = true.

Qué cambia en las respuestas: un combustible que solo tiene un precio más antiguo falta en prices; una estación sin ningún precio restante no aparece en la lista, o tiene un objeto prices vacío donde se muestran estaciones sin precio; y una respuesta puede estar vacía donde antes incluía precios antiguos. Una respuesta vacía sigue incluyendo empty_reason. fuel-local puede entonces responder desde el nivel de región o de país. El indicador stale no cambia: es true cuando un precio se confirmó por última vez hace más de 7 días. El historial de precios se conserva. Para fuel-cities, fuel-cost, las medias nacionales y fuel-grades no hay cambio práctico. Detalles: Antigüedad del precio.

GET /api/v2/data/route-plan recibe en v2 un modelo de paradas ampliado (aditivo: no se elimina ni renombra nada) y nuevos valores predeterminados en v3 (/api/v3/data/route-plan).

v2, aditivo. Con stop_places=1, cada parada (pausa, comida, pernocta, descanso semanal) incluye places[]: aparcamientos candidatos en una ventana de tiempo de conducción alrededor de la parada, cada uno con name, type, country, lat, lon, at_km, at_drive_s, offset_min, off_route_km, detour_km, exceeds_4h30 y type_rank. Ajuste la búsqueda con places_before_min, places_after_min, places_radius_km y rest_radius_km; un radio superior a 25 km se limita y se notifica con la advertencia radius_clamped. rest_rules=legacy|eu561 elige el modelo de descanso, y con eu561 puede enviar el estado del conductor: driven_since_break_min, driven_today_min, duty_started_min_ago, driven_week_min, driven_fortnight_min, extended_days_used, reduced_rests_used y allow_reduced. Nuevos tipos de parada: ban_wait (con ban: name, country, from, until) y weekly_rest; una espera que sustituye una pausa o un descanso se marca con counts_as. Los cruces de camiones a la salida de Ucrania con cola electrónica añaden registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note y registration_url, además de las advertencias echerha_registration y echerha_wait_unverified.

v3, nuevos valores predeterminados. rest_rules es eu561 por defecto; los nombres de lugares son estrictos (solo aparcamientos y áreas de descanso reales); la espera publicada por eCherha (datos recientes, sin límite) se usa como espera en la frontera, y una espera en la frontera cuenta como la pausa o el descanso que tocaba. La v2 conserva el modelo de descanso anterior y el filtro de lugares original, así que las integraciones existentes no cambian. Detalles: Route Planner API.

GET /api/v3/data/truck-route ahora usa la espera en la frontera de eCherha. En v3, border_crossings[] de los carriles de camiones a la salida de Ucrania con cola electrónica toman wait_min de la espera publicada por eCherha (solo datos recientes, sin límite; si está desactualizada, wait_min es null y se añade la advertencia echerha_wait_unverified) e incluyen registration_required, registration_wait_minutes, registration_wait_source, registration_wait_at, registration_note y registration_url, con la advertencia echerha_registration.

El plan de descansos trata la espera en la frontera como tiempo pasado en la frontera: una cola larga cuenta como la pausa, el descanso diario o semanal que tocaba (counts_as en la fila waits[]), en lugar de sumarse encima. La v2 no cambia. Detalles: Truck Route API.

Cuando /api/v2/data/fuel-stations o /api/v2/data/fuel-cheapest no encuentra ninguna estación, la respuesta sigue siendo HTTP 200 con una lista vacía, y ahora indica el motivo. Solo en una respuesta vacía, data incluye empty_reason (no_station_in_radius, no_price_for_fuel_type, fuel_type_not_priced_in_country, unknown_fuel_type o no_fresh_price_in_radius), nearest_station_km (la estación más cercana con su tipo de combustible, buscada hasta nearest_search_km = 50 km; null si no hay ninguna), country y suggestion, una frase breve en su lang, por ejemplo: Ninguna estación a menos de 5 km: la más cercana está a 6,4 km; pruebe radius_km=10.

Base la lógica de su código en empty_reason y nearest_station_km. suggestion es un consejo para personas y su redacción puede cambiar. Nunca ampliamos el radio por usted. Si muestrea un área o una ruta en una cuadrícula, use radius_km de 10–15. Las respuestas que contienen estaciones no cambian. Detalles: Respuestas vacías.

Radio de búsqueda. radius_km en /api/v2/data/fuel-stations ahora conserva un decimal. Un radio como 4.8 antes se truncaba a 4 sin aviso, de modo que cada búsqueda cubría hasta un tercio menos de área de la solicitada y podía devolver menos estaciones o ninguna. anchor.radius_km muestra el radio realmente aplicado; los números enteros se devuelven como antes.

Nombres de marca. Una misma marca ahora se escribe siempre igual en brand: por ejemplo, ORLEN y orlen se devuelven como Orlen, y CircleK como Circle K. Las estaciones, los precios, los ids y los campos no cambian. Si compara marcas por su grafía exacta (para logotipos o filtros), revise su lista con los nuevos nombres.

GET /api/v2/data/truck-route acepta un nuevo parámetro opcional traffic. Define cómo se tiene en cuenta el tráfico para el ETA, el plan de descansos, las horas de llegada a las fronteras y las horas en las prohibiciones para camiones:

• forecast (predeterminado): congestión recurrente a la hora en que el camión pasa por cada tramo, atascos actuales que se atenúan con el tiempo hasta la llegada, obras y cortes en el trayecto, y meteorología donde la tenemos. La respuesta incluye un bloque traffic_forecast con el retraso desglosado por causa.
• live: solo el tráfico actual, sin la congestión recurrente.
• off: sin ajuste por tráfico; los tiempos son los del motor de camión en flujo libre. Entonces traffic_forecast contiene solo model y mode.

Cualquier otro valor devuelve 400 bad_request con el mensaje Invalid traffic: forecast, live or off. Las solicitudes sin el parámetro usan el valor predeterminado, forecast.

Prohibiciones para camiones a la hora de llegada prevista: con forecast o live, truck_bans[].active ahora se evalúa a la hora en que se prevé que el camión llegue a cada prohibición (a partir de depart_at, o de ahora si no lo envía), antes de cualquier espera por esa prohibición. Un nuevo campo truck_bans[].active_at indica la hora evaluada, en la hora local del país de la prohibición. bans_summary, restriction_hits y legal siguen los mismos veredictos, y una prohibición con la que el retraso previsto choca por primera vez (por ejemplo, en un día posterior o en otro país) también aparece en truck_bans. Con traffic=off, active se evalúa en la línea temporal de flujo libre y active_at es igual a eta_at_ban.

Nuevo producto: Truck Route API (GET /api/v2/data/truck-route, solo v2). Una sola llamada devuelve una ruta apta para camiones y lo que un despachador necesita a lo largo de ella. La ruta la calcula el mismo núcleo de enrutamiento que nuestra aplicación de navegación para camiones TruckTurn, sobre nuestros propios datos de mapa.

• Vehículo: height, width, length, weight, axle_load, axles, trailers, emission_class, hazmat (clases ADR) y adr_tunnel (B–E). Las prohibiciones de circulación de camiones y las zonas de restricción se comprueban sobre la línea devuelta.
• A lo largo de la ruta: gasolineras con precios actuales, aparcamientos para camiones y básculas, cada uno con km_from_start y desvío.
• Plan de descanso del conductor según el Reglamento (CE) 561/2006: pausas (incluida la división 15+30), descanso diario y semanal (incluido el reducido), conductor único o tripulación de dos (crew=2), partiendo del estado actual del conductor si lo envía. Cada parada se sitúa en un aparcamiento real a lo largo de la ruta. Es una ayuda de planificación, no un registro de tacógrafo.
• ETA incluyendo descansos, prohibiciones de circulación de camiones y esperas en frontera. Planifique por depart_at o arrive_at.
• Estimaciones del coste de peajes por país (EUR, según ejes y clase de emisiones); los países sin tarifa se enumeran en tolls.coverage_note. También avoid (peajes, ferris, autopistas, fronteras, túneles, caminos sin asfaltar, zonas de bajas emisiones), hasta 2 alternativas, un desglose por país y geometry como polyline5, polyline6 o GeoJSON.

Cuota: una cuota independiente para rutas de camión: 10 llamadas al día en cada cuenta, más en los planes de pago, y un complemento de Llamadas adicionales de rutas de camión. En el sandbox puede ejecutar 10 rutas de camión al día, ver el resultado en el mapa con el plan de ruta completo y exportarlo como GPX, KML, GeoJSON, CSV, calendario (.ics) o ITN. Consulte la página del producto y la referencia.

Según los Términos de la API, un Market es el país cuyos datos utiliza, y su clave cubre los países aprobados para su cuenta. Hasta ahora, los productos basados en coordenadas (lat/lon — p. ej. Nearby Shops, Truck Parkings, Fuel Stations) respondían para cualquier punto de Europa. A partir del 13 de octubre de 2026, esto se comprueba al procesar su solicitud:

• Una solicitud cuyo lat/lon se encuentra en un país no aprobado para su cuenta devuelve 403 con error.code market_not_allowed. El mensaje indica el país y su lista de países aprobados.
• Cuando el radio cruza una frontera, se eliminan los resultados cuyo country_code está fuera de sus países aprobados. La respuesta entonces incluye markets_filtered (cuántos se eliminaron) y markets_notice, y total_found solo cuenta lo recibido.

Esto se aplica a cuentas cuyos países han sido revisados (estado approved o partial). Nada cambia en la solicitud — ningún parámetro nuevo, ninguna versión nueva. Si su aplicación necesita otro país, añádalo en el portal para desarrolladores antes del 13 de octubre. market_not_allowed aparece junto con los demás códigos de error en la referencia.

Las cuentas de desarrollador vinculadas a una cuenta de Nakordoni Partners con el mismo correo electrónico ahora pueden enviar noticias y gestionar su flota NakBus (NakDriver / NakManager) desde partners.nakordoni.eu, con roles de equipo (Owner, Manager, Viewer) e inicio de sesión con un clic entre los dos portales. Las páginas del portal para desarrolladores, las claves de API, los endpoints de la flota y las aplicaciones permanecen sin cambios.

En Fuel Prices, updated_at y el propio indicador age_hours/stale de la respuesta funcionaban con relojes distintos: updated_at solo cambia cuando un precio realmente cambia, pero la obsolescencia se calculaba como si cambiara en cada confirmación. El 46.7% del índice de precios mostraba age_hours ≤48 y stale:false cuando updated_at tenía en realidad más de 48 horas, y 12,620 estaciones más de una semana. Ahora cada precio incluye además confirmed_at — la última vez que confirmamos el precio, redondeada a la hora hacia abajo y nunca anterior a updated_at — y age_hours/stale se calculan a partir de él. El significado de updated_at no cambia: úselo cuando quiera saber cuándo se movió el precio por última vez, y confirmed_at cuando quiera saber qué tan actual es ahora mismo. No está presente en el contrato v1 congelado.

Dos errores de idioma, ambos silenciosos: enviar el código canónico del tipo de combustible con lang=pl (o cualquiera de los otros 24 idiomas del sitio) devolvía fuel_type_local en inglés independientemente de lo solicitado — solo se habían comprobado 10 idiomas en la tabla de etiquetas, de modo que todo lo que quedaba fuera de esa lista caía en el vocabulario de interfaz por defecto en lugar del idioma solicitado. Por separado, lang=tr (u otros códigos válidos) respondía con listados de estaciones en ucraniano, porque un valor interno por defecto uk se activaba siempre que el idioma solicitado no estaba en esa misma lista de 10 idiomas. Ambos están corregidos: el idioma que envía es ahora el idioma que recibe, en los 25.

Además: brand en Nearby Fuel Stations ya no devuelve el valor centinela de ingesta OTHER para las ~330 estaciones cuya marca desconocemos — ahora es null, de forma coherente con cualquier otro campo desconocido de la respuesta.

El asistente de IA de fronteras (/api/v1/data/assistant) respondía 503 internal_error — «Asistente temporalmente no disponible» — cuando la misma clave hacía la misma pregunta dos veces en menos de cinco minutos. Nada estaba fuera de servicio: en la mayoría de esos casos la respuesta ya estaba calculada y lista para devolverse. Ahora se devuelve con normalidad, con ok: true y HTTP 200.

Cuando la repetición llega mientras aún se está redactando la primera respuesta, la llamada devuelve ahora 429 con un error.code igual a duplicate_request en lugar de un 503, de modo que una política de reintentos puede distinguir «vuelve a preguntar en un momento» de una caída real. Ambos casos se contabilizaban además en la tasa de errores de tu cuenta como errores de servidor; ya no es así. En la petición no cambia nada: ningún parámetro, ninguna versión. duplicate_request figura junto a los demás códigos de error en la referencia.

Truck Parking (/api/v2/data/truck-parkings) devolvía entradas con name igual a null y address vacío — cerca de Bensheim, 20 de 50. Son lugares que conservamos solo como coordenada, sin nada que mostrar ni nada con lo que casarlos con tu propio conjunto de POI. Ya no forman parte de este producto: ahora sirve únicamente ubicaciones con nombre, actualmente más de 22.000 en toda Europa. Si filtrabas tú mismo las entradas sin nombre, ese código ahora es redundante pero inocuo. Las respuestas se acortan para el mismo radius y limit, y cada entrada devuelta es utilizable.

Aparte, unos 10.000 aparcamientos llevaban un par de coordenadas en bruto como name, por ejemplo 51.927301,10.14112, mientras que la etiqueta real estaba en address. Ahora llevan esa etiqueta — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — en todos los sitios donde aparecen, incluido /api/v1/data/pois. El id de cada lugar no cambia, así que un mapeo en caché sigue siendo válido; solo cambia el name.

snapshot.updated_at en /api/v1/data/queue y /api/v1/data/multi es hora local en la zona propia del paso fronterizo (por ejemplo Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), y hasta ahora nada en la respuesta indicaba de qué zona se trataba, por lo que quien llamaba no podía convertirla en un instante concreto. snapshot incorpora un campo aditivo timezone (nombre IANA) junto a updated_at. Ningún parámetro, ninguna versión, ningún otro campo cambia.

Hasta ahora cada endpoint de combustible describía su propia cobertura con una lista escrita a mano: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, y Polonia quedaba reducida en ella al área de Trójmiasto. Ambas afirmaciones llevaban mucho tiempo desfasadas. La cobertura ahora se mide desde el índice vivo de estaciones y se recalcula cada seis horas: 39 países tienen hoy estaciones con precios, y Polonia entre ellos en todo el país, no en tres ciudades. En la petición no cambia nada: ningún parámetro, ninguna versión.

Nearby Fuel Stations y Cheapest Fuel: cuando una búsqueda vuelve vacía, el bloque coverage lleva ahora valores medidos station_countries, station_counts, sparse_coverage y measured_at, acotados al tipo de combustible que pidió y no al combustible en general. Un país entra en sparse_coverage cuando tenemos allí 25 estaciones con precio o menos — es un recuento, no una valoración.

Hay una nota nueva para un tipo que reconocemos pero que nadie cotiza donde usted pregunta. Hasta ahora coverage.fuel_type_note solo aparecía cuando el nombre del surtidor nos era desconocido. Ahora aparece también cuando el nombre se resuelve correctamente y sencillamente no hay precio para él en ese país; nombra los países donde ese tipo sí se cotiza y los tipos que cotizamos a su alrededor. El nombre checo Natural 100 es el ejemplo limpio: se reconoce, y ninguna fuente le pone precio en Chequia. Una respuesta vacía deja de parecer una petición rota.

Fuel Grades (/api/v2/data/fuel-grades) gana priced_countries y priced_station_counts para cada tipo, más priced_here cuando envía ?country=. Las dos listas significan cosas distintas: un país en countries es aquel donde aceptamos ese nombre de surtidor, mientras que priced_countries indica dónde una fuente lo cotiza realmente, así que priced_here igual a 0 es una respuesta real y no un hueco en la respuesta. La carga útil lleva además coverage_measured_at y coverage_note, y su Cache-Control baja de 24 horas a 6 para ajustarse a la frecuencia de recálculo.

También se resuelven más nombres locales de surtidor, entre ellos Klimadiesel 90 (HVO100) y HVO Diesel, Erdgas y Metano, Autogas y Autogaz, DEF para AdBlue, y una serie de nombres comerciales de gasóleos y gasolinas premium. El orden de resolución no cambia y la coincidencia sigue siendo exacta, así que ningún nombre que funcionaba antes significa hoy otra cosa, y un nombre nuevo solo puede convertir una respuesta vacía en una con precios. Al mismo tiempo se corrigieron la documentación de referencia y las descripciones de los endpoints en los 25 idiomas del sitio.

Cheapest Fuel (/api/v2/data/fuel-cheapest) devolvía las estaciones más cercanas ordenadas por distancia en lugar de las más baratas. Como la clasificación se aplicaba antes de recortar el resultado a su limit, las gasolineras más baratas dentro de su radio podían faltar por completo en la respuesta. La clasificación vuelve a ser correcta: primero la más barata para el combustible solicitado, en caso de empate gana la más cercana, y una estación sin cotización para ese combustible queda clasificada en último lugar. Nada cambia en la solicitud: ni parámetro, ni versión.

Las respuestas de combustible v2 también están documentadas tal como se sirven realmente: las estaciones llegan bajo data.stations[], una entrada por estación física, con cada tipo de combustible anidado dentro del objeto prices (price, currency, local_name, updated_at, age_hours, stale), además de station_ref, grades, total_found y notices. La referencia de Nearby Fuel Stations y Cheapest Fuel seguía describiendo la antigua lista plana de filas data.data[].

En la página de facturación (pestaña mensual) hay dos complementos disponibles sobre cualquier plan, sin cambiarlo: Llamadas de previsión adicionales — +100 llamadas de previsión y estadísticas al día por bloque, €2 al mes por bloque, hasta 10 bloques; y Países adicionales — +1 país declarable por unidad, €2 al mes cada uno. Al cambiar la cantidad se muestra un presupuesto prorrateado exacto antes de cualquier cobro.

Desde el 10 de noviembre de 2026 cada plan incluye un número determinado de países declarados: Explorer y Student 4, Starter 10, Pro y superiores ilimitados. A partir de esa fecha no se podrá guardar una declaración mayor que el plan más los países adicionales comprados; la pestaña Cuenta ya muestra tu asignación y las cuentas que la superan ven una sugerencia en el panel. Antes del 10 de noviembre no cambia nada.

El sandbox de la API ahora etiqueta cada endpoint del selector con su clase de cuota (Pesado / Estándar), muestra el coste de cuota de la versión seleccionada antes de ejecutar nada y, tras una llamada, muestra lo que esa misma llamada habría costado en tu cuota real — incluida la fórmula ceil(N ppids × M sub-products / 2) que se usa para las llamadas con forma /multi.

Es una vista previa de solo lectura: las llamadas del sandbox se descuentan de tu presupuesto de pruebas independiente, nunca de tu cuota real.

Desde hoy, todo lo que hemos anunciado públicamente como en retirada está cerrado a las cuentas de desarrollador creadas en la fecha del anuncio o después. Si tu cuenta ya existía antes del anuncio, nada cambia: conservas el periodo de gracia completo, hasta la fecha de retirada indicada en la entrada que la anunció.

Por qué existe esta regla. El 24 de agosto de 2026 anunciamos que truck-bans v1 se retira el 8 de septiembre de 2026. Dos cuentas registradas pocos días después de ese anuncio construyeron su integración sobre v1 y llegaron a estar a horas de un 410 sin que ningún correo nuestro les hubiera llegado: tanto el anuncio como el envío de notificaciones eran anteriores a su registro. Nada en la API les impidió adoptar una versión que ya habíamos dado por desaparecida. Fue un fallo nuestro, y esta es la corrección: no puedes adoptar de nuevo algo cuya eliminación ya está programada.

Cómo se ve. Una llamada así se rechaza con 410 Gone y el código de error version_closed_to_new_accounts. El mensaje indica la fecha de retirada, la fecha del anuncio y la versión que debe usarse en su lugar. Es deliberadamente un código distinto de version_sunset, que es el que recibe cualquier cuenta una vez pasada la propia fecha de retirada: el soporte puede distinguir «llegaste demasiado tarde para empezar» de «esto ya no existe para nadie» sin leer un registro.

El derecho adquirido se determina por la fecha de creación de la cuenta, no por la primera llamada. Si te registraste antes del anuncio pero empiezas a integrar ahora, sigues teniendo el periodo de gracia completo: es posible que llevaras desarrollando contra ella todo el tiempo.

En vigor ahora para truck-bans v1 (anunciado el 24 de agosto de 2026, se retira el 8 de septiembre de 2026), y automáticamente para cada retirada que anunciemos a partir de ahora. No se te exige nada nuevo: cada respuesta de una versión en retirada ya incluye las cabeceras Deprecation, Sunset y Link: rel="successor-version", de modo que una nueva integración puede ver venir una retirada sin leer esta página.

Continuación del cambio de v4 de ayer (ticket de desarrollador #105). Las listas destination separadas por comas en v1 y v2 siguen funcionando, pero ahora se rigen por el mismo plazo que destination=all: ambas se detienen el 2026-10-06 (cabeceras Deprecation/Sunset hasta entonces y, después, 400 destination_list_removed, que señala /api/v4/ como sustituto). El límite actual de 10 elementos en las listas con comas no cambia antes de esa fecha.

v4 sigue admitiendo un solo destino por llamada — eso no ha cambiado hoy. Lo único que cambia es cómo se comunican v1/v2: el 400 de destination=all ya no sugiere una lista con comas como vía de migración (moriría en la misma fecha), sino que apunta directamente a v4.

Corrección de la documentación: el ejemplo de v4 en este sitio decía antes /api/v4/data/border/1/2,3,4/9 — una lista con comas, que v4 rechaza. Ahora es /api/v4/data/border/1/2/9. Quien copiara el ejemplo antiguo habría recibido un 400 en su primera llamada; lo sentimos.

Nueva clave traducida product_border_v4_p_destination se publica en los 25 idiomas del sitio y enuncia de forma explícita la regla de un solo destino en v4 en lugar de recurrir a la redacción de v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} está disponible desde hoy. Tres cosas cambian respecto a v2 y, en conjunto, son la razón de que sea una versión nueva y no una modificación.

1. Se acabó destination=all. Nuestros datos se licencian por país (Términos de la API para desarrolladores, sección 7), y un comodín que se expande a "todos los países vecinos de los que tenemos datos" devuelve países para los que tu cuenta puede no estar aprobada, sin que nada en la petición lo indique. En v4 eres tú quien nombra el país.

2. Un país de destino por llamada. /api/v4/data/border/1/2/9 pide una sola frontera. Las listas separadas por comas no se aceptan: envía 1/2/9, 1/3/9 y 1/4/9 como llamadas separadas. Una lista separada por comas o all responde 400 e indica las llamadas exactas que hay que enviar, así nada falla en silencio.

3. Un solo código de camión. v1 y v2 dividían el transporte de mercancías en 8 (Freight Transport) y 9 (Freight Transport up to 7.5 t). Esa división es real en el paso fronterizo, pero ningún integrador puede actuar sobre ella: pedir 9 a v2 en la frontera UA-PL devolvía 21 de los 70 pasos para camiones y nada lo indicaba. v4 responde a 9 con todos los carriles de camiones y acepta 8 como alias de 9. Cada fila lleva su propio crossing_type, de modo que una respuesta combinada sigue siendo inspeccionable.

En v1 y v2, destination=all sigue funcionando hasta el 6 de octubre de 2026 y hasta entonces incluye las cabeceras Deprecation / Sunset. A partir de esa fecha esas versiones también responden 400 para all; el resto de v1 y v2 queda intacto y sigue disponible. La misma fecha se aplica a los demás atajos de todos los países: travel-matrix sin ?dest=, bus-carriers con ?ppid=all y fuel-grades sin ?country=.

v3, anunciada hoy mismo un poco antes, queda sustituida por v4. v3 solo se diferenciaba de v4 en que aún aceptaba una lista separada por comas, y ninguna integración usa esa forma. Las URL de v3 siguen respondiendo, así que nada escrito contra ellas se rompe, pero v3 no está documentada y no se seguirá desarrollando: migra a v4.

Todo lo demás en v4 es igual que en v2: orden direccional de la ruta, direction{from,to}, stale y ?max_age_min=.

Los ids numéricos de /border/{origin}/{destination}/{crossing_type} nunca se publicaron como tabla, así que los integradores los reconstruían a partir de zonas horarias y URL de ejemplo. Ya están en la documentación, en Códigos de país y de tipo de vehículo, generados desde las mismas tablas con las que valida la API: los ids de país con las fronteras a las que se expande cada uno, y cada crossing_type con la etiqueta que devuelve la API.

Al publicarlos encontramos que el sandbox y los metadatos del endpoint describían 8 como "truck<7.5t" y 9 como "truck". Está invertido: la API etiqueta 8 como Freight Transport y 9 como Freight Transport up to 7.5 tons, y siempre ha sido así. Si elegiste un código de camión a partir de la pista del parámetro, estabas filtrando el carril contrario al que querías. Corregido en todas partes, y v3 elimina la elección por completo.

Los Términos de la API v1.1 sustituyen a v1.0 antes de que entrara en vigor y se aplican desde el 6 de octubre de 2026. Acéptalos en tu panel.

La sección 7 ya dice qué es un Mercado: el país cuyos datos usas — donde está el paso fronterizo o la frontera que solicitas — no el país en el que viven tus usuarios. Nuestro panel decía ambas cosas en sitios distintos; la aplicación de la norma siempre se refirió a lo primero.

Dos cambios a tu favor. Los países ya aprobados para tu cuenta siguen siendo utilizables mientras un cambio posterior está en revisión (añadir un país ya no suspende los que tienes). Y si no hemos respondido a una declaración de mercado en 5 días hábiles, se aplican los límites completos de tu plan hasta que lo hagamos.

La sección 10.3 ya coincide con lo que el panel pide realmente, y la sección 13.2 fija una base de disponibilidad que medimos y podemos mostrarte.

Tres productos incluyen ahora un campo aditivo data_quality (high o low) que indica si una lectura es una observación real o una estimación del modelo sin fuente de conteo en vivo en ese paso fronterizo: queue (en el snapshot de nivel superior y en cada fila histórica de data[] — ausente en las filas de previsión), update-info (en el sobre) y multi (en los subobjetos queue y update_info de cada paso fronterizo). No es una señal nueva — el indicador subyacente ya existía internamente — pero nunca se exponía, así que un paso completamente modelado se veía idéntico a uno medido directamente. is_realtime no cambia a propósito: sigue valiendo true para las filas modeladas, y cambiar ese significado sería un cambio incompatible de nivel v2 que no vamos a hacer aquí.

También en esta versión: el producto queue-advanced ya no redistribuye datos meteorológicos brutos de origen. weather_main, temperature y wind_speed se sustituyen por un condition_code derivado (escala de riesgo 0–5, null cuando no hay datos meteorológicos disponibles), condition y severity.

Desde el 2026-08-30, una solicitud /api/v1/data/multi se responde para un máximo de 5 pasos fronterizos. Una llamada que enumera más PPID no se rechaza: sigue devolviendo 200, pero solo se responden los primeros 5 ID de ?ppids=. Los ID restantes se ignoran, se devuelven en meta.ppid_cap.ignored y no se descuentan de tu cuota — la llamada se factura por lo que realmente devuelve.

Mientras una llamada supere el límite, la respuesta incluye la cabecera X-Devapi-Warning: multi_ppid_cap y un bloque meta.ppid_cap con cap, enforced_from, enforced, ppids_asked, ppids_answered e ignored[]. Hasta el 2026-08-30 esos campos aparecen con enforced: false y el conjunto completo de resultados, para que puedas ver venir el cambio en tus propios registros.

El descuento de cuota de la mitad no cambia. Divide tus pasos fronterizos en grupos de 5 y envía una llamada por grupo en tu ciclo de actualización habitual; para consultar con frecuencia solo la longitud de la cola y la frescura de los datos, update-info sigue siendo el producto de clase estándar más barato.

La prohibición ucraniana por calor que calculamos — devuelta con include_ua_heat y automáticamente para country=UA — ahora responde para la ventana de fechas que pides. Antes devolvía los siete días siguientes dijeran lo que dijeran date_from y date_to, de modo que una ventana de diciembre traía en silencio las filas de esta semana. La prohibición se calcula a partir del pronóstico meteorológico y no se lee del calendario de prohibiciones, así que tiene dos límites que el calendario no tiene: no mira hacia atrás y termina donde termina el pronóstico. Tu ventana ahora se cruza con lo que el pronóstico cubre realmente, y el nuevo campo ua_heat_ban.forecast_horizon indica la última fecha alcanzada. Una ventana más allá de ese horizonte no devuelve filas y explica por qué en summary — lo que no equivale a «sin prohibición». Las respuestas v1 no cambian.

La forma de la respuesta no estaba documentada en ningún sitio: la única manera de saber qué devolvía un producto era llamarlo. Ahora la página de cada producto muestra, debajo de la tabla de parámetros, una tabla Campos de la respuesta con una breve descripción de cada campo; los campos de los elementos de una lista aparecen como items[].name, y los campos del nivel del sobre (usage, meta, snapshot, resolved_location) aparecen sin prefijo. Están documentados 40 de 42 productos: los dos aún no lanzados (weather, road-quality) se quedan a propósito sin descripción. La misma tabla se publica en nuestro espejo público de documentación en GitHub.

Cada producto de carburante acepta ahora el nombre local de un carburante, no solo nuestra escritura interna: ON en Polonia, Nafta en Chequia, Gázolaj en Hungría, Motorină en Rumanía, ДП en Ucrania, Motorin en Turquía, Gasóleo en Portugal y España. El nombre se interpreta primero según el país — «95» es E10 en un surtidor danés y E5 en uno polaco —, así que envíe country junto con el nombre local, o coordenadas con las que situar el punto. La respuesta devuelve fuel_type (canónico), fuel_type_requested (tal como lo escribió) y fuel_type_local. Un nombre que no podemos situar nunca se sustituye por un carburante por defecto: la respuesta vuelve vacía y lo dice.

La tabla completa es ahora un producto propio — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — nuestros carburantes canónicos y sus nombres locales en 41 países europeos, incluidos mercados para los que no publicamos precios. Los niveles de país y de región de fuel y fuel-local incorporan además un objeto grades que asocia cada clave de precio con su carburante y con el nombre que se usa en el surtidor.

El producto truck-bans ya responde para una fecha concreta o un rango de fechas en /api/v2/data/truck-bans. Hasta ahora siempre devolvía los 7 días siguientes e ignoraba cualquier fecha enviada, de modo que construir un calendario exigía una petición por día — y en un plan de dos peticiones por segundo la mayoría se rechazan con 429 qps_exceeded.

Usa ?date=YYYY-MM-DD para un solo día, o ?date_from= y ?date_to= para un rango. Ambos extremos son inclusivos y cualquiera puede omitirse: el inicio es hoy por defecto y el fin es el inicio más 7 días. Una ventana puede abarcar como máximo 92 días — una más larga se rechaza con 400 date_range_too_long en lugar de recortarse en silencio. Es un calendario orientado al futuro: una ventana puede comenzar como máximo 7 días atrás, y las fechas anteriores se rechazan en lugar de servirse; la cobertura se extiende hacia adelante hasta el 31 de diciembre de 2028 en 23 países.

Cada respuesta incluye ahora un objeto window que indica exactamente el rango cubierto. Es un campo aditivo y también se envía en v1, donde v1 mantiene sin cambios su ventana fija de 7 días. Ten en cuenta que include_ua_heat siempre cubre los 7 días siguientes, sea cual sea la ventana solicitada: se calcula a partir de una previsión meteorológica, no del calendario de restricciones. Recuerda que la v1 de este producto se retira el 8 de septiembre de 2026.

Dos mejoras relacionadas en toda la API: cualquier parámetro que un producto no acepte aparece ahora en ignored_params dentro de la respuesta en lugar de descartarse en silencio, y los errores de validación del servicio de datos te llegan tal como están escritos, con el código legible por máquina en error.reason.

Tres correcciones de calidad de respuesta procedentes de una auditoría del gateway (ticket #43).

La cabecera X-API-Key ya se acepta junto a Authorization: Bearer y ?key=. Si tu cliente HTTP envía las claves mediante una cabecera llamada X-API-Key, ahora funciona — antes se ignoraba en silencio y la llamada se rechazaba como missing_api_key. Authorization: Bearer sigue siendo la forma documentada y recomendada.

El mensaje de error de clave ausente ahora nombra las tres formas de autenticarse (cabecera Bearer, cabecera X-API-Key o ?key=) en lugar de limitarse a enlazar la página de registro.

El directorio checkpoints ahora incluye has_day_stats en cada fila — un booleano aditivo que indica si la API Best Time to Cross (day-stats) tiene datos para ese punto de control. Los day-stats solo existen para un subconjunto de los puntos de control monitorizados; comprueba este indicador antes de consultar para evitar 404 predecibles. Los campos existentes no cambian.

También corregido en la documentación: el producto road-conditions siempre ha respetado el parámetro lang para la localización de etiquetas — simplemente no estaba listado.

Dos correcciones y una nueva versión para el producto truck-bans.

Los países separados por comas ya funcionan. ?country= acepta una lista de hasta 3 códigos ISO-2, por ejemplo ?country=DE,RO. Una lista más larga se rechaza con 400 too_many_countries en vez de recortarse en silencio — esto es un calendario de restricciones por país, no un feed masivo. Antes esto no funcionaba: se eliminaba el separador, así que DE,RO se leía como el único token DERO, no coincidía con nada y devolvía success: true con total_bans: 0 — un rotundo “sin restricciones” para dos países que entre ambos tenían 22. Si lo sorteabas enviando una petición por país, ahora una sola petición las cubre todas y cuesta una llamada en lugar de varias.

Las respuestas ahora informan de su propia completitud. Tres campos aditivos — returned, total_available y truncated — indican si una respuesta se truncó. En particular, una llamada sin ámbito devuelve un fragmento limitado y hasta ahora nada en la carga útil lo indicaba. total_bans conserva su significado actual (filas de esta respuesta), así que nada de lo que ya analizas cambia.

La v2 tiene ámbito por país. En /api/v2/data/truck-bans, ?country= es obligatorio y una petición sin ámbito se rechaza con 400 scope_required — este producto es un calendario de restricciones por país, no un feed masivo. La v1 no cambia hoy — sigue aceptando llamadas sin ámbito y sigue devolviendo las mismas 50 filas limitadas de siempre, así que ahora mismo no se rompe nada de lo que tengas en funcionamiento. La v1 de este producto se retira el 8 de septiembre de 2026. Funciona con normalidad hasta el 7 de septiembre; desde el 8 de septiembre una petición v1 se rechaza con 410 Gone y un mensaje que apunta a la v2. Hasta entonces, cada respuesta v1 incluye Deprecation: true, una cabecera Sunset con esa fecha y una cabecera Link que nombra la versión sucesora, de modo que una biblioteca cliente puede mostrar el plazo sin que nadie lea esta página. Para migrar: cambia el segmento de versión a /api/v2/data/truck-bans y envía ?country=.

Una corrección en la documentación: se ha eliminado el parámetro date. Estuvo listado mucho tiempo pero el servicio nunca lo leía, así que cualquier petición que lo enviara recibía en silencio la ventana predeterminada de 7 días en lugar del día solicitado. Para seleccionar un día, filtra el array upcoming_bans por su campo date. Además, un código ISO-3 como DEU ya no se resuelve como nombre de país en el resumen, donde producía el engañoso “No truck ban data for: Germany.”

El producto truck-bans devuelve ahora restricciones de circulación de ámbito nacional para cinco países más: Bélgica (BE), Bielorrusia (BY), Montenegro (ME), Macedonia del Norte (MK) y Suecia (SE). La cobertura existente de Bulgaria, Grecia y Portugal se ha ampliado y actualizado — las restricciones griegas llegan ahora hasta septiembre de 2027 y Portugal vuelve a tener datos.

La estructura de la respuesta no cambia. Las filas nuevas llevan las mismas claves que cualquier otra prohibición: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons y details_url. Cuando una restricción solo se aplica bajo una condición — por ejemplo, las prohibiciones estivales bielorrusas rigen por encima de 25 °C — esa condición se indica en restriction_details, así que lee ese campo antes de avisar a un conductor. min_weight_tons es null cuando una norma afecta a una clase de transporte (mercancías peligrosas) y no a un tonelaje.

Los productos fuel-stations y fuel-cheapest devuelven ahora precios por estación en Polonia. La cobertura es parcial — el área de la Triciudad (Gdansk, Gdynia, Sopot) — por lo que Polonia se indica en un nuevo array aditivo coverage.sparse_coverage junto a la lista ya existente coverage.station_countries. Un país incluido en sparse_coverage solo tiene datos de estaciones para una parte de su territorio; una consulta en otro punto de ese país devuelve una lista vacía junto con la nota de cobertura, igual que antes. Los precios polacos se expresan en PLN.

El error de consulta masiva también es más claro: cuando falta lat, el mensaje scope_required remite ahora al producto fuel (?country=XX) para precios medios de todo el país.

GET /api/v2/data/fuel-local?lat=&lon= resuelve ahora el precio en tres niveles en lugar de dos: station, luego region, luego country. El nuevo nivel intermedio existe para Ucrania, donde no existen precios por estación en ninguna fuente: un punto en Ucrania recibe ahora la media de su óblast en lugar de la media nacional, y solo vuelve a la media nacional cuando el óblast no está cotizado.

Una respuesta del nivel region incluye el código del óblast (un valor ISO 3166-2 como UA-46), region_name y region_center_dist_km, además de las mismas claves de precio que el nivel de país. Sigue ramificando el código según resolution, nunca según la forma de la respuesta; las respuestas station y country no cambian.

El nuevo endpoint GET /api/v2/data/fuel-local?lat=&lon= devuelve el mejor precio de combustible disponible para cualquier punto de Europa. Donde tenemos datos por estación responde con los precios de las estaciones más cercanas; en caso contrario, con la media nacional del país en el que se encuentra el punto, incluida Ucrania, donde no existen precios por estación en ninguna fuente.

Cada respuesta incluye el campo resolution, que indica el nivel que respondió: station (una lista de estaciones con distance_km, cada una en su propia moneda) o country (un objeto con las medias nacionales). Ramifica tu código según resolution, nunca según la forma de la respuesta. Disponible a partir de /api/v2/; fuel, fuel-stations y fuel-cheapest no cambian.

Los productos fuel-stations y fuel-cheapest cubren ahora muchas más gasolineras en Alemania, con precios que se actualizan a lo largo del día, incluidas las zonas rurales. El parámetro fuel_type acepta 13 tipos de combustible: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 y lng. Cuando ninguna gasolinera coincide con la consulta, la respuesta incluye un objeto coverage con la lista de países para los que hay datos de estaciones.

El parámetro radius= se acepta ahora como alias compatible de radius_km en todos los productos que lo documentan. Los productos fuel-stations y fuel-cheapest devuelven un objeto aditivo coverage (lista de países con estaciones más una nota) en lugar de un resultado vacío sin explicación cuando ninguna gasolinera coincide. Los objetos de frontera de route-plan incluyen ahora la clave aditiva wait_basis (car_lane frente a vehicle_lane), de modo que los clientes pueden saber cuándo el tiempo de espera de camiones procede en realidad del carril de turismos. La correspondencia de pasos fronterizos para camiones a lo largo de una ruta es bastante más precisa: recurso al carril de turismos en los pares de pasos sin datos de carril de camiones, protección contra la dirección equivocada, un umbral de distancia más estricto y deduplicación de pasos situados en la misma posición. Todos los cambios son aditivos; no hay cambios incompatibles.

La página de aterrizaje para desarrolladores ahora tiene secciones ancladas (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) con navegación de salto, y cada tarjeta de producto enlaza a su propia página de documentación. La nueva sección Mobile apps presenta Kordon Online y Truck Bans con enlaces a Google Play. Relleno de traducciones: el historial de facturación, los errores de inicio de sesión, los enlaces de sandbox y el botón de selección de plan ahora están localizados en los 25 idiomas.

La respuesta del beacon de la flota (POST /api/v1/fleet_position.php) ahora incluye un array messages que entrega los mensajes pendientes del propietario al conductor. Nuevo feed JSON en vivo solo para propietarios (?ajax=live) y una tarjeta "Mensajes para conductores" en el panel de la flota. Nueva página de invitación para conductores /{lang}/get-nakbus (25 idiomas).

Se localizaron el título, la descripción y los parámetros de fleet-history de product_fleet_vehicles/live/history en los 25 idiomas del portal de desarrolladores.

/api/v1/data/truck-bans ahora devuelve el mismo conjunto de campos de nivel superior sin importar qué consulta haya originado la respuesta. Antes, una consulta para un país sin prohibiciones de calendario, un ppid no reconocido, o una coincidencia normal en la base de datos podían omitir campos distintos (p. ej., country, covered_countries, ppid). Ahora cada respuesta incluye de forma consistente 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 y upcoming_bans (null o vacío cuando no aplica), simplificando el análisis del lado del cliente.

Nueve nuevos productos por servicio. Los basados en ubicación aceptan lat/lon o city + country (geocodificamos la ciudad por ti): /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 (estaciones clasificadas por precio para un tipo de combustible) y /api/v2/data/internet-points; los resultados incluyen distance_km y están limitados por radius. /api/v2/data/vignettes responde si un país requiere una viñeta, con precios actuales. El producto existente pois ahora admite lon y radius según lo documentado, y el modo mode=nearest del producto fuel también acepta lon. Los nueve están disponibles en el sandbox.

Cada prohibición en /api/v1/data/truck-bans ahora incluye restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (ámbito exacto o carreteras afectadas) y min_weight_tons. details_url ahora apunta a páginas por país en nakordoni.eu. Un nuevo parámetro opcional lang selecciona el idioma de los nombres de países y del resumen; el predeterminado ahora es el inglés.

Un ?ppid= mal formado ahora devuelve el motivo real en lugar de un escueto "Request failed": el error nombra el parámetro, el formato esperado id_<number> y remite a /api/v1/data/checkpoints. Las tablas de parámetros de stats, forecast, update-info, weather y bus-carriers ahora muestran el ejemplo id_13 en los 25 idiomas.

La interfaz rediseñada del portal (barra superior, barra lateral de iconos, panel de KPI, diseños en tarjetas) ya es la experiencia predeterminada para todas las cuentas de desarrollador con sesión iniciada — antes de la fecha de despliegue prevista del 10 de agosto. Usa ?v=1 para volver al diseño clásico en cualquier momento.

Todas las páginas del portal para desarrolladores — inicio, documentación, panel, AI Studio, entorno de pruebas, tickets, solicitudes, exportación, flota, noticias, registro de cambios y páginas de la cuenta — ya no cargan ningún script ni espacio publicitario. Se aplica a todo el portal, no solo al inicio de sesión y al registro como antes.

Planifica todo un viaje fronterizo en una sola llamada: /api/v2/data/route-plan devuelve la ruta, los pasos fronterizos que realmente están en ella con la cola en directo o una previsión para tu hora de llegada, y las paradas que un conductor hace de verdad — descanso, comida, repostaje — en una sola línea de tiempo.

La frontera forma parte de esa línea. Una cola larga cuenta como el descanso que ya tocaba y reinicia el tiempo al volante, así que tres horas de espera nunca se presentan como tres horas más una tanda completa de descansos que nadie hizo. Los turismos siguen un modelo de conducción segura; autobuses y camiones reciben el descanso obligatorio de la UE 561/2006, y el tiempo de servicio de los autobuses está calibrado con más de 1000 horarios internacionales autorizados. Añade stop_places=1 para dar a cada parada un área de descanso o gasolinera real, y via=lat,lon para pasar por otro paso fronterizo.

Novedad en el menú del portal: Presentación — una presentación viva y siempre actualizada de la plataforma de datos de nakordoni, personalizada para tu mercado (seguros, viajes, logística, transportistas, medios, navegación, combustible, fintech, sector público o proyectos personales). Muestra volúmenes reales de la plataforma a 30 días, tu propio uso de la API, estadísticas de tiempos de respuesta y límites, y una recomendación de plan cuando tus llamadas alcanzan los límites del nivel gratuito. Elige o confirma tu mercado (o mercados) en la página, en tu perfil — o durante el registro. Se abre automáticamente en tu primera visita; la apertura automática se puede desactivar en la propia página.

Si un asistente tiene una fuente activada pero la llamada no lleva el contexto que esa fuente necesita — por ejemplo queue sin ppid—, la fuente ahora se omite antes de realizar ninguna petición y no se cobra. Antes se llamaba igualmente, fallaba y aun así costaba una unidad. El estudio muestra qué necesita cada fuente, recalcula el precio a medida que completas el contexto y marca los resultados como ✓ ejecutada / ⊘ omitida, sin cargo / ✕ fallida; la API devuelve data.feeds_skipped , que te indica exactamente qué parámetro pasar.

Las respuestas ya no mencionan fuentes, orígenes de datos ni nada técnico: una fuente ausente es, como mucho, una frase sencilla para el usuario final, nunca un nombre interno. Las fuentes con solo filtros opcionales (como fuel limitada a un país del que no tenemos datos) ahora recurren al conjunto de datos amplio en lugar de no devolver nada.

Novedad: /{lang}/developers/studio. Crea un asistente de IA que responda a partir de tu contenido y de nuestros datos fronterizos en vivo. Danos tu markdown o simplemente indícanos las páginas y nosotros las descargamos e indexamos: tú solo mantienes tus propios archivos. Elige qué fuentes nuestras puede usar (cola, previsión, alternativas, estadísticas diarias, combustible, restricciones para camiones, domingos comerciales, festivos, estado de las carreteras, transportistas de autobús, POI, divisas), elige un nivel de modelo (rápido / equilibrado / pro — es lo que fija el precio), escribe tus propias instrucciones con marcadores {{feed.slug}} que indiquen exactamente dónde aparecen nuestros datos en la respuesta, y añade tu propia frase de cierre, que se adjunta a cada respuesta. Plantillas listas: asistente personal de viaje, asistente de trabajo/carga, asistente de venta de seguros y Carta Verde.

Pruébalo en el estudio (30 respuestas al día, aparte de tu cuota de API) y luego llámalo en producción en GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Precio por respuesta = unidades del nivel de modelo + 1 unidad por cada fuente activada, devuelto en X-Devapi-Units. El producto es solo v2: una URL v1 devuelve unsupported_version. El producto existente assistant no cambia.

Cada asistente funciona bajo una política de contenido de la plataforma que prevalece sobre tus instrucciones: nada de hacerse pasar por autoridades, ninguna ayuda para eludir el control fronterizo o aduanero, ninguna cifra inventada, nada de lenguaje soez. Se revisan tanto las instrucciones como las respuestas; las llamadas bloqueadas quedan registradas.

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.

El cambio de nombre a «Live Queue & Freshness API» descrito más abajo en realidad no llegó a la página de documentación . La página muestra el título de cada producto mediante una búsqueda de traducción que recurre al título del endpoint solo cuando no existe traducción — y ya existía una, congelada con el nombre antiguo, en los 25 idiomas de la interfaz. A partir de ahora prevalece sobre cualquier futura actualización del título base, hasta que también ella se actualice.

Se renombró la clave de traducción en los 25 idiomas, así que la página de documentación ya coincide. Sin cambios en el endpoint, los parámetros ni la respuesta: solo el texto del título.

Si consultas con frecuencia los datos de la cola en vivo, puede que estés gastando cuota pesada sin necesidad. /update-info es de clase estándar y ya devuelve el valor en vivo:

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

Devuelve queue_now, freshness, age_minutes, is_realtime, status, timestamp y timezone. Úsalo para el refresco frecuente con cargo a tu cuota diaria estándar y reserva /queue, /multi y /forecast (todos de clase pesada) para cuando necesites wait_min, los campos de tendencia o el histórico.

En el endpoint no ha cambiado nada: solo su documentación. Aparecía como «Data Freshness API» y su descripción solo mencionaba la valoración de frescura, nunca queue_now, así que era fácil pasarlo por alto. Ahora se titula «Live Queue & Freshness API», con los campos devueltos detallados. Gracias al desarrollador que lo señaló.

Algunas peticiones fallidas devolvían HTTP 200 con ok: true y el error enterrado dentro de data — de modo que el patrón documentado if (!ok) throw no podía detectarlas y la llamada se cobraba igualmente. Las llamadas afectadas ahora devuelven HTTP 400 con ok: false y un error.code / error.messagecorrectos, tal como está documentado. Visto en fuel-cities con un país no admitido y en travel-matrix con coordenadas mal formadas.

Aparte, un parámetro obligatorio ausente devolvía 500 internal_error en lugar de 400 bad_request (el cuerpo de una respuesta 4xx del servicio interno se descartaba antes de leer su estado). Ahora devuelve 400 bad_request con el mensaje del servicio interno; por ejemplo, search sin ?name=.

Las respuestas correctas no cambian ni un byte — mismos campos, mismos parámetros, mismo coste de cuota. Si tu cliente ya se bifurca según ok, no hace falta ningún cambio. Si ignoraba ok y leía data directamente, ahora verá sobres de error en llamadas que siempre habían estado fallando.

Se corrigió un error por el que /multi podía devolver un recuento de cola incorrecto en algunos pasos fronterizos — sobre todo balcánicos y de la frontera Hungría–Serbia — siempre que su caché estaba fría. El respaldo leía una tabla que, para esos pasos, no contiene datos de cola, y presentaba valores ajenos como número de coches. Ejemplos medidos: un paso con 12 coches informaba de 6, y varios con colas reales informaban de 0.

Tres cambios que puedes notar:

• found: false significa ahora que realmente no hay datos de cola recientes. Antes podías recibir found: true con un queue_now: 0inventado.
• wait_status, trend_percent y trend_direction se devuelven ahora también en peticiones en frío; antes eran null .
• El endpoint también recurre al respaldo cuando su instantánea en caché está obsoleta (más de 24 h), no solo cuando falta.

Sin cambios en los parámetros de la petición, el coste de cuota ni la estructura de la respuesta.

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
• 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 , 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 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 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   — prognosed wait time (minutes)
snapshot.updated_at — when the queue data was recorded
snapshot.age_min    — minutes since last update
snapshot.source     — data source identifier

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.