Registro de cambios de la API

On Fuel Prices, updated_at and the response's own age_hours/stale flag were running on different clocks: updated_at moves only when a price actually changes, but staleness was computed as if it moved on every confirmation. 46.7% of the priced index showed age_hours ≤48 and stale:false while updated_at was in fact more than 48 hours old, 12,620 stations over a week old. Each price now also carries confirmed_at — the last time we confirmed the price, hour-floored, never earlier than updated_at — and age_hours/stale are computed from it. updated_at's meaning is unchanged: use it when you want to know when the price last moved, use confirmed_at when you want to know how current it is right now. Not present on the frozen v1 contract.

Two language bugs, both silent: sending the canonical grade code as lang=pl (or any of the other 24 site languages) got fuel_type_local back in English regardless — only 10 languages were ever checked against the label table, so anything outside that list fell through to the default UI vocabulary rather than the language you asked for. Separately, lang=tr (or several other valid codes) answered station listings in Ukrainian, because an internal default of uk fired whenever the requested language did not sit in that same 10-language list. Both are fixed: the language you send is now the language you get, across all 25.

Also: brand on Nearby Fuel Stations no longer returns the raw ingest sentinel OTHER for the ~330 stations where we do not know the brand — it is null, consistent with every other unknown field in the response.

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   — (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.