Журнал змін 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.

Прикордонний AI-асистент (/api/v1/data/assistant) відповідав 503 internal_error — «Асистент тимчасово недоступний» — коли той самий ключ ставив те саме запитання двічі протягом п'яти хвилин. Насправді ніщо не було недоступним: у більшості таких випадків відповідь уже була обчислена й готова до видачі. Тепер вона повертається штатно, з ok: true та HTTP 200.

Якщо повтор надходить, поки перша відповідь ще формується, виклик тепер повертає 429 з error.code = duplicate_request замість 503 — щоб політика повторів могла відрізнити «спробуйте за мить» від справжнього збою. Обидва випадки також зараховувалися до рівня помилок вашого акаунта як серверні; більше цього немає. У самому запиті нічого не змінюється — жодного параметра, жодної версії. duplicate_request наведено разом з іншими кодами помилок у довіднику.

Стоянки для вантажівок (/api/v2/data/truck-parkings) повертали записи з name = null і порожньою address — біля Бенсгайма 20 із 50. Це місця, які ми зберігаємо лише як координату: нічого показати й нічого зіставити з вашим набором POI. Вони більше не входять до цього продукту: тепер він віддає лише іменовані локації, наразі понад 22 000 по Європі. Якщо ви самі відфільтровували записи без назви, той код тепер зайвий, але нешкідливий. Відповіді для тих самих radius і limit стають коротшими, і кожен запис, що повертається, придатний до використання.

Окремо: близько 10 000 стоянок мали в полі name сиру пару координат, наприклад 51.927301,10.14112, тоді як справжня назва була в address. Тепер вони мають саме цю назву — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — усюди, де з'являються, зокрема в /api/v1/data/pois. id кожного місця не змінюється, тож збережена відповідність лишається чинною; змінюється тільки name.

snapshot.updated_at у /api/v1/data/queue і /api/v1/data/multi — це місцевий час у власному поясі пункту пропуску (наприклад, Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), і досі у відповіді ніде не було вказано, який саме це пояс, тож клієнт не міг звести його до конкретного моменту часу. snapshot отримує додаткове поле timezone (назва IANA) поруч із updated_at. Жодного параметра, жодної версії, жодних інших змін полів.

Раніше кожен паливний ендпоінт описував власне покриття списком, складеним вручну: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, а Польща в ньому зводилася до Тримістя. Обидва твердження давно застаріли. Тепер покриття вимірюється за живим індексом станцій і перераховується кожні шість годин: 39 країн сьогодні мають станції з цінами, і Польща серед них по всій країні, а не в трьох містах. У самому запиті не змінюється нічого: ані параметра, ані версії.

Найближчі АЗС та Найдешевше пальне: коли пошук нічого не повертає, блок coverage тепер містить виміряні station_countries, station_counts, sparse_coverage і measured_at, звужені до того сорту пального, який ви запитали, а не до пального загалом. Країна потрапляє до sparse_coverage, якщо ми маємо в ній 25 станцій із цінами або менше — це підрахунок, а не оцінка.

З'явилося нове пояснення для сорту, який ми розпізнаємо, але який ніхто не тарифікує там, де ви запитали. Досі coverage.fuel_type_note виникало лише тоді, коли сама назва на колонці була нам невідома. Тепер воно з'являється й тоді, коли назва розпізнана правильно, але в цій країні для неї просто немає жодної ціни; у ньому названо країни, де цей сорт тарифікується, і сорти, які ми тарифікуємо поруч із вами. Чеська назва Natural 100 — чистий приклад: вона розпізнається, але жоден постачальник даних не дає на неї ціни в Чехії. Порожня відповідь більше не виглядає як зламаний запит.

Сорти пального (/api/v2/data/fuel-grades) отримує priced_countries і priced_station_counts для кожного сорту, а також priced_here, якщо ви передаєте ?country=. Ці списки означають різне: країна в countries — це країна, де ми приймаємо таку назву на колонці, а priced_countries — це там, де постачальник даних справді дає ціну, тож priced_here зі значенням 0 — це справжня відповідь, а не прогалина у відповіді. Разом із ними передаються coverage_measured_at і coverage_note, а Cache-Control знижено з 24 годин до 6, щоб відповідати частоті перерахунку.

Розпізнається й більше місцевих назв на колонках, серед них Klimadiesel 90 (HVO100) та HVO Diesel, Erdgas та Metano, Autogas та Autogaz, DEF для AdBlue, а також низка брендових назв преміальних дизелів і бензинів. Порядок розпізнавання не змінився, а зіставлення лишається точним, тож жодна назва, що працювала раніше, сьогодні не означає нічого іншого, а нова назва може хіба що перетворити порожню відповідь на відповідь із цінами. Водночас виправлено довідкову документацію та описи ендпоінтів усіма 25 мовами сайту.

«Найдешевше пальне» (/api/v2/data/fuel-cheapest) повертав найближчі заправки за відстанню замість найдешевших. Оскільки сортування застосовувалося до того, як результат обрізався до вашого limit, найдешевші заправки у вашому радіусі могли повністю випадати з відповіді. Сортування знову працює правильно: спочатку найдешевша ціна для запитаної марки пального, за рівності ціни перемагає найближча заправка, а заправка без ціни на цю марку опиняється останньою. У самому запиті нічого не змінюється — ані параметрів, ані версії.

Відповіді пального v2 також задокументовано такими, якими вони фактично повертаються: заправки надходять у data.stations[], по одному запису на фізичну заправку, а кожна марка пального вкладена в об'єкт prices (price, currency, local_name, updated_at, age_hours, stale), а також station_ref, grades, total_found і notices. Довідка для «Найближчих заправок» та «Найдешевшого пального» досі описувала старіший плоский список рядків data.data[].

На сторінці оплати (вкладка «Щомісяця») доступні два додатки до будь-якого тарифу, не змінюючи його: Додаткові виклики прогнозів — +100 викликів прогнозів і статистики на добу за блок, €2 на місяць за блок, до 10 блоків; і Додаткові країни — +1 країна для декларування за одиницю, €2 на місяць за кожну. Зміна кількості показує точний пропорційний розрахунок ще до списання коштів.

З 10 листопада 2026 кожен тариф включає певну кількість задекларованих країн: Explorer і Student — 4, Starter — 10, Pro і вище — без обмежень. Від цієї дати декларацію, довшу за тариф плюс придбані додаткові країни, зберегти не вдасться; вкладка «Акаунт» уже показує ваш ліміт, а акаунти, які його перевищують, бачать підказку на дашборді. До 10 листопада нічого не змінюється.

Пісочниця API тепер позначає кожен ендпоінт у списку його класом квоти (Важкий / Стандартний), показує вартість у квоті для обраної версії ще до запуску, а після виклику показує, скільки той самий виклик коштував би з вашої робочої квоти, — включно з формулою ceil(N ppids × M sub-products / 2), що застосовується до викликів у форматі /multi.

Це попередній перегляд лише для читання: самі виклики в пісочниці списуються з окремого тестового бюджету пісочниці, а не з вашої робочої квоти.

Від сьогодні все, що ми публічно оголосили таким, що виводиться з експлуатації, закрите для акаунтів розробників, створених у день оголошення або пізніше. Якщо ваш акаунт існував до оголошення, нічого не змінюється — ви зберігаєте повний пільговий період аж до дати виведення, зазначеної в записі, який його оголосив.

Навіщо це правило. 24 серпня 2026 року ми оголосили, що truck-bans v1 виводиться з експлуатації 8 вересня 2026 року. Два акаунти зареєструвалися за кілька днів після того оголошення, побудували інтеграцію на v1 і опинилися за кілька годин від 410, хоча жоден наш лист до них так і не дійшов: і оголошення, і розсилка сповіщень передували їхній реєстрації. Ніщо в API не завадило їм узяти версію, про зникнення якої ми вже сказали. Це була наша помилка, і це — її виправлення: не можна почати використовувати те, що вже заплановано до видалення.

Як це виглядає. Такий виклик відхиляється з 410 Gone і кодом помилки version_closed_to_new_accounts. У повідомленні названо дату виведення, дату оголошення та версію, яку слід використовувати натомість. Це навмисно інший код, ніж version_sunset, який отримує будь-який акаунт після того, як настала сама дата виведення — підтримка відрізнить «ви прийшли надто пізно, щоб починати» від «це зникло для всіх», не читаючи логів.

Збереження прав визначається датою створення акаунта, а не першим викликом. Якщо ви зареєструвалися до оголошення, але починаєте інтеграцію лише зараз, повний пільговий період усе одно ваш: цілком можливо, що ви весь цей час на нього орієнтувалися.

Діє вже зараз для truck-bans v1 (оголошено 24 серпня 2026 року, виводиться 8 вересня 2026 року) і автоматично для кожного виведення, яке ми оголосимо надалі. Від вас нічого нового не потрібно: кожна відповідь на версії, що виводиться, вже несе заголовки Deprecation, Sunset і Link: rel="successor-version", тож нова інтеграція побачить наближення виведення, не читаючи цієї сторінки.

Продовження вчорашньої зміни у v4 (тікет розробників #105). Списки destination через кому у v1 і v2 продовжують працювати, але тепер підпадають під той самий строк, що й destination=all: обидва припиняють роботу 2026-10-06 (до того — заголовки Deprecation/Sunset, після — 400 destination_list_removed із зазначенням /api/v4/ як заміни). Наявна перевірка ліміту в 10 елементів для списків через кому до цієї дати не змінюється.

v4 і далі приймає одну destination на виклик — сьогодні це не змінювалося. Змінилося лише формулювання для v1/v2: помилка 400 для destination=all більше не пропонує список через кому як шлях міграції (він помер би тієї самої дати), а одразу вказує на v4.

Виправлення в документації: приклад v4 на цьому сайті раніше мав вигляд /api/v4/data/border/1/2,3,4/9 — це список через кому, який v4 відхиляє. Тепер там /api/v4/data/border/1/2/9. Той, хто скопіював старий приклад, отримав би 400 на першому ж виклику; перепрошуємо.

Новий перекладений ключ product_border_v4_p_destination доступний усіма 25 мовами сайту й прямо описує правило «одна destination» у v4, замість того щоб підставляти формулювання з v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} працює з сьогодні. Порівняно з v2 змінюються три речі — і разом вони пояснюють, чому це нова версія, а не правка.

1. Більше жодного destination=all. Наші дані ліцензуються окремо по країнах (Developer API Terms, розділ 7), а шаблон, який розгортається в «усі сусідні країни, дані про які в нас є», повертає країни, на які ваш акаунт може не мати дозволу, — і в самому запиті цього ніяк не видно. У v4 країну ви називаєте самі.

2. Одна країна призначення на запит. /api/v4/data/border/1/2/9 запитує один кордон. Списки через кому не приймаються: надсилайте 1/2/9, 1/3/9 і 1/4/9 окремими запитами. Список через кому або all отримує у відповідь 400 і перелік точних запитів, які треба надіслати, — тож нічого не ламається мовчки.

3. Один код для вантажівок. v1 і v2 ділили вантажний транспорт на 8 (Freight Transport) і 9 (Freight Transport up to 7.5 t). На самому пункті пропуску цей поділ реальний, але жоден інтегратор не може на нього спертися: запит 9 до v2 на кордоні UA-PL повертав 21 із 70 вантажних пунктів пропуску, і ніде про це не було сказано. v4 у відповідь на 9 віддає всі вантажні смуги, а 8 приймає як синонім 9. Кожен рядок несе власний crossing_type, тож об'єднану відповідь усе одно можна розібрати.

У v1 і v2 destination=all працює до 2026-10-06 і до того часу віддає заголовки Deprecation / Sunset. Від цієї дати ці версії теж відповідають 400 на all — решта v1 і v2 не змінюється й лишається доступною. Та сама дата стосується інших скорочень «усі країни»: travel-matrix без ?dest=, bus-carriers з ?ppid=all і fuel-grades без ?country=.

v3, оголошену сьогодні раніше, замінює v4. v3 відрізнялася від v4 лише тим, що ще приймала список через кому, і жодна інтеграція такої форми не використовує. URL v3 продовжують відповідати, тож ніщо написане під них не зламається, але v3 не документується й далі не розвиватиметься — переходьте на v4.

Усе інше у v4 — як у v2: спрямований порядок сегментів шляху, direction{from,to}, stale і ?max_age_min=.

Числові ідентифікатори в /border/{origin}/{destination}/{crossing_type} ніколи не публікувалися таблицею, тож інтегратори відновлювали їх за часовими поясами та прикладами URL. Тепер вони є в документації, у розділі Country and vehicle-type codes, і формуються з тих самих таблиць, за якими API робить перевірку, — ідентифікатори країн разом із кордонами, у які кожен із них розгортається, і кожен crossing_type із міткою, яку повертає API.

Публікуючи їх, ми виявили, що пісочниця та метадані ендпоїнтів описують 8 як «truck<7.5t», а 9 — як «truck». Це навпаки: API позначає 8 як Freight Transport, а 9 — як Freight Transport up to 7.5 tons, і так було завжди. Якщо ви брали код вантажівки з підказки до параметра, то фільтрували смугу, протилежну до потрібної. Виправлено всюди, а v3 прибирає цей вибір узагалі.

API Terms v1.1 замінюють v1.0 ще до того, як та набрала чинності, і діють від 2026-10-06. Прийміть їх у своїй панелі.

Розділ 7 тепер визначає, що таке Ринок: це країна, чиї дані ви використовуєте, — та, де розташований пункт пропуску або кордон, який ви запитуєте, — а не країна, де живуть ваші користувачі. Наша панель у різних місцях казала і те, і те; на практиці застосовувалося завжди перше.

Дві зміни на вашу користь. Країни, вже схвалені для вашого акаунта, лишаються доступними, поки розглядається пізніша зміна (додавання країни більше не призупиняє ті, що у вас уже є). І якщо ми не відповіли на декларацію ринку протягом 5 робочих днів, до моменту відповіді діють повні ліміти вашого тарифу.

Розділ 10.3 тепер відповідає тому, що насправді запитує панель, а розділ 13.2 фіксує основу доступності, яку ми вимірюємо й можемо вам показати.

Три продукти тепер несуть додаткове поле data_quality (high або low), яке показує, чи є показник реальним спостереженням, чи модельною оцінкою за відсутності живого джерела підрахунку на цьому пункті пропуску: queue (у верхньорівневому snapshot і в кожному історичному рядку в data[] — на прогнозних рядках його немає), update-info (в обгортці) і multi (в обох підоб'єктах, queue і update_info, для кожного пункту пропуску). Це не новий сигнал — сам прапорець уже існував усередині, — але назовні він ніколи не віддавався, тож повністю змодельований пункт пропуску виглядав так само, як виміряний напряму. is_realtime навмисно не змінено: для модельних рядків він і далі має значення true, а зміна цього сенсу була б ламкою зміною рівня v2, якої ми тут не робимо.

Також у цьому релізі: продукт queue-advanced більше не поширює сирі погодні дані від постачальника. weather_main, temperature і wind_speed замінено похідними condition_code (шкала небезпеки 0–5, null, коли погодних даних немає), condition і severity.

З 2026-08-30 один запит /api/v1/data/multi обробляється щонайбільше для 5 пунктів пропуску. Виклик, у якому перелічено більше PPID, не відхиляється: він і далі повертає 200, але відповідь дається лише для перших 5 ID у ?ppids=. Решта ID ігноруються, повертаються у meta.ppid_cap.ignored і не списуються з вашої квоти — оплачується лише те, що виклик справді повернув.

Поки виклик перевищує ліміт, у відповіді є заголовок X-Devapi-Warning: multi_ppid_cap і блок meta.ppid_cap з полями cap, enforced_from, enforced, ppids_asked, ppids_answered та ignored[]. До 2026-08-30 ці поля з'являються зі значенням enforced: false і повним набором результатів, тож ви побачите майбутню зміну у власних логах.

Знижка на квоту в розмірі половини лишається без змін. Розділіть свої пункти пропуску на групи по 5 і надсилайте один виклик на групу у звичайному циклі оновлення; для частого опитування лише довжини черги та свіжості даних дешевшим продуктом стандартного класу лишається update-info.

Розрахована заборона через спеку в Україні — повертається з include_ua_heat, а для country=UA автоматично — тепер відповідає за той період дат, який ви запитуєте. Раніше вона повертала найближчі сім днів незалежно від date_from і date_to, тож для грудневого періоду тихо приходили рядки цього тижня. Заборона обчислюється з прогнозу погоди, а не читається з календаря заборон, тому має дві межі, яких у календаря немає: вона не дивиться назад і закінчується там, де закінчується прогноз. Тепер ваш період перетинається з тим, що реально охоплює прогноз, а нове поле ua_heat_ban.forecast_horizon називає останню доступну дату. Період за цією межею повертає порожній список і пояснює причину в summary — це не те саме, що «заборони немає». Відповіді v1 не змінилися.

Форму відповіді раніше ніде не було описано — єдиний спосіб дізнатися, що повертає продукт, був його викликати. Тепер на сторінці кожного продукту під таблицею параметрів є таблиця Поля відповіді з коротким описом кожного поля; поля елементів списку показані як items[].name, а поля рівня конверта (usage, meta, snapshot, resolved_location) — без префікса. Описано 40 продуктів із 42: два ще не запущені (weather, road-quality) свідомо залишилися без опису. Та сама таблиця публікується в нашому відкритому дзеркалі документації на GitHub.

Тепер кожен паливний продукт приймає локальну назву марки, а не лише наше внутрішнє написання: ON у Польщі, Nafta у Чехії, Gázolaj в Угорщині, Motorină у Румунії, ДП в Україні, Motorin у Туреччині, Gasóleo у Португалії та Іспанії. Назва розпізнається передусім за країною — «95» це E10 на данській колонці й E5 на польській — тож надсилайте country разом із локальною назвою або координати, за якими точку можна визначити. У відповіді повертаються fuel_type (канонічна), fuel_type_requested (як ви написали) і fuel_type_local. Назву, яку ми не змогли розпізнати, ми ніколи не підміняємо маркою за замовчуванням: відповідь приходить порожня і прямо про це каже.

Уся таблиця тепер окремий продукт — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — наші канонічні марки та їхні локальні назви в 41 країні Європи, зокрема на ринках, де ми не подаємо цін. Крім того, країнний і регіональний рівні fuel та fuel-local отримали об'єкт grades, який зіставляє кожен ключ ціни з маркою та її назвою на заправці.

Продукт truck-bans тепер відповідає на запит про конкретну дату або діапазон дат за адресою /api/v2/data/truck-bans. Досі він завжди повертав найближчі 7 днів і ігнорував будь-яку передану дату, тож щоб скласти календар, доводилося робити один запит на кожен день — а на тарифі з двома запитами на секунду більшість із них відхиляється з 429 qps_exceeded.

Використовуйте ?date=YYYY-MM-DD для одного дня або ?date_from= та ?date_to= для діапазону. Обидві межі включно, будь-яку з них можна не вказувати: початок за замовчуванням — сьогодні, кінець — початок плюс 7 днів. Вікно може охоплювати щонайбільше 92 дні — довше відхиляється з 400 date_range_too_long, а не обрізається мовчки. Це календар, спрямований у майбутнє: вікно може починатися щонайбільше 7 днів тому, а старіші дати відхиляються, а не видаються — покриття сягає вперед до 31 грудня 2028 року у 23 країнах.

Кожна відповідь тепер містить об'єкт window, який називає точний охоплений діапазон. Це додаткове поле, і воно надсилається також у v1, причому v1 зберігає своє незмінне вікно на 7 днів. Зверніть увагу: include_ua_heat завжди охоплює найближчі 7 днів, яке б вікно ви не запитали, — він обчислюється з прогнозу погоди, а не з календаря заборон. Нагадуємо, що v1 цього продукту припиняє роботу 8 вересня 2026 року.

Два пов'язані покращення в усьому API: будь-який параметр, якого продукт не приймає, тепер перелічено у полі ignored_params у відповіді, а не відкидається мовчки; а помилки перевірки від сервісу даних тепер доходять до вас так, як їх написано, з машинозчитуваним кодом у error.reason.

Три виправлення якості відповідей за підсумками аудиту шлюзу (тікет #43).

Заголовок X-API-Key тепер приймається — поряд із Authorization: Bearer та ?key=. Якщо ваш HTTP-клієнт надсилає ключі в заголовку з іменем X-API-Key, це тепер працює — раніше він мовчки ігнорувався, а виклик відхилявся як missing_api_key. Authorization: Bearer лишається задокументованою рекомендованою формою.

Повідомлення про відсутній ключ тепер називає всі три способи автентифікації (заголовок Bearer, заголовок X-API-Key або ?key=) замість самого лише посилання на сторінку реєстрації.

Довідник checkpoints тепер містить has_day_stats у кожному рядку — додаткове булеве поле, яке показує, чи має API «Найкращий час для перетину» (day-stats) дані для цього пункту пропуску. Day-stats існує лише для частини моніторених пунктів пропуску; перевіряйте цей прапорець перед опитуванням, щоб уникнути передбачуваних 404. Наявні поля не змінилися.

Також виправлено в документації: продукт road-conditions завжди враховував параметр lang для локалізації підписів — його просто не було в списку.

Два виправлення та одна нова версія продукту truck-bans.

Перелік країн через кому тепер працює. ?country= приймає список до 3 кодів ISO-2, наприклад ?country=DE,RO. Довший список відхиляється з 400 too_many_countries, а не мовчки обрізається — це календар заборон для окремої країни, а не масовий фід. Раніше це не працювало: роздільник видалявся, тож DE,RO читалося як єдиний токен DERO, не збігалося ні з чим і повертало success: true з total_bans: 0 — впевнене «заборон немає» для двох країн, у яких разом було 22. Якщо ви обходили це окремим запитом на кожну країну, тепер один запит покриває їх усі й коштує один виклик замість кількох.

Відповіді тепер повідомляють про власну повноту. Три додаткові поля — returned, total_available і truncated — показують, чи була відповідь обрізана. Зокрема, запит без прив'язки до країни повертає обрізаний зріз, і досі ніщо в тілі відповіді про це не свідчило. total_bans зберігає своє значення (рядки в цій відповіді), тож те, що ви вже розбираєте, не змінюється.

v2 обмежена однією країною. На /api/v2/data/truck-bans параметр ?country= є обов'язковим, а запит без прив'язки відхиляється з 400 scope_required — цей продукт є календарем заборон для окремої країни, а не масовим фідом. v1 сьогодні не змінюється — вона й далі приймає запит без прив'язки та й далі повертає ті самі обрізані 50 рядків, що й завжди, тож ніщо з того, що у вас працює, зараз не ламається. v1 цього продукту виводиться з експлуатації 8 вересня 2026 року. Вона працює у звичайному режимі до 7 вересня включно; з 8 вересня запит до v1 відхиляється з 410 Gone і повідомленням, що вказує на v2. До того часу кожна відповідь v1 містить Deprecation: true, заголовок Sunset із цією датою та заголовок Link з назвою версії-наступниці, тож клієнтська бібліотека може показати дедлайн без того, щоб хтось читав цю сторінку. Щоб мігрувати: змініть сегмент версії на /api/v2/data/truck-bans і передайте ?country=.

Одне виправлення в документації: параметр date видалено. Він довго був у списку, але сервіс його ніколи не читав, тож будь-який запит, що його надсилав, мовчки отримував типове вікно на 7 днів замість запитаного дня. Щоб вибрати день, фільтруйте масив upcoming_bans за полем date. Код ISO-3, як-от DEU, також більше не перетворюється на назву країни у зведенні, де він давав оманливе «No truck ban data for: Germany.»

Продукт truck-bans тепер повертає загальнонаціональні обмеження руху ще для п'яти країн: Бельгії (BE), Білорусі (BY), Чорногорії (ME), Північної Македонії (MK) та Швеції (SE). Наявне покриття Болгарії, Греції та Португалії розширено й оновлено — грецькі обмеження тепер доходять до вересня 2027 року, а Португалія знову наповнена даними.

Структура відповіді не змінилася. Нові рядки мають ті самі ключі, що й будь-яка інша заборона: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons і details_url. Якщо обмеження діє лише за певної умови — наприклад, білоруські літні заборони діють при температурі понад 25 °C — цю умову вказано в restriction_details, тож читайте це поле, перш ніж попереджати водія. min_weight_tons дорівнює null, коли правило стосується класу перевезень (небезпечні вантажі), а не тоннажу.

Продукти fuel-stations і fuel-cheapest тепер повертають ціни по окремих АЗС у Польщі. Покриття часткове — агломерація Труймісто (Гданськ, Гдиня, Сопот), — тому Польщу вказано в новому додатковому масиві coverage.sparse_coverage поряд із наявним списком coverage.station_countries. Країна зі списку sparse_coverage має дані по АЗС лише для частини своєї території; запит в іншому місці цієї країни повертає порожній список разом із приміткою про покриття, як і раніше. Польські ціни подано в PLN.

Помилка масового запиту теж стала зрозумілішою: якщо lat відсутній, повідомлення scope_required тепер вказує на продукт fuel (?country=XX) для середніх цін по країні.

GET /api/v2/data/fuel-local?lat=&lon= тепер визначає ціну за трьома рівнями замість двох: station, потім region, потім country. Новий проміжний рівень існує для України, де даних по окремих АЗС немає ніде: точка в Україні тепер отримує середню ціну по своїй області замість середньої по країні й повертається до середньої по країні лише тоді, коли для області немає котирувань.

Відповідь рівня region містить код області (значення ISO 3166-2, наприклад UA-46), region_name і region_center_dist_km, а також ті самі цінові ключі, що й рівень країни. Далі розгалужуйте код за resolution, а не за формою відповіді; відповіді station і country не змінилися.

Новий ендпоінт GET /api/v2/data/fuel-local?lat=&lon= повертає найкращу доступну ціну на пальне для будь-якої точки Європи. Він відповідає цінами найближчих АЗС там, де є дані по окремих станціях, а в інших випадках — середньою ціною по країні, у якій розташована точка, зокрема для України, де даних по окремих АЗС немає ніде.

Кожна відповідь містить поле resolution, яке називає рівень, що відповів: station (список станцій із distance_km, кожна у своїй валюті) або country (один об'єкт із середніми цінами по країні). Розгалужуйте код за resolution, а не за формою відповіді. Доступно починаючи з /api/v2/; fuel, fuel-stations і fuel-cheapest не змінилися.

Продукти fuel-stations і fuel-cheapest тепер охоплюють значно більше заправок у Німеччині, а ціни оновлюються протягом дня — зокрема й у сільській місцевості. Параметр fuel_type приймає 13 типів пального: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 та lng. Якщо жодна заправка не відповідає запиту, у відповіді повертається об'єкт coverage зі списком країн, для яких є дані про заправки.

Параметр radius= тепер приймається як сумісний аліас до radius_km в усіх продуктах, де він задокументований. Продукти fuel-stations і fuel-cheapest повертають додатковий об'єкт coverage (перелік країн із заправками та примітка) замість мовчазної порожньої відповіді, коли жодна заправка не підходить. Об'єкти кордонів у route-plan тепер містять додатковий ключ wait_basis (car_lane проти vehicle_lane), щоб клієнт бачив, коли дані про очікування для вантажівок узяті з легкової смуги. Зіставлення вантажних пунктів пропуску вздовж маршруту стало значно точнішим: запасний варіант із легкової смуги для пар пунктів без даних по вантажній смузі, захист від неправильного напрямку, суворіший поріг відстані та вилучення дублів переходів з однаковими координатами. Усі зміни є додатковими, зворотну сумісність не порушено.

На сторінці для розробників тепер є розділи з якорями (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) та навігацією переходів, а кожна картка продукту веде на власну сторінку документації. Новий розділ Mobile apps представляє Kordon Online і Truck Bans із посиланнями на Google Play. Довнесення перекладів: історія платежів, помилки входу, посилання на пісочницю та кнопка вибору тарифу тепер локалізовані для всіх 25 мов.

Відповідь маяка автопарку (POST /api/v1/fleet_position.php) тепер містить масив messages, що передає повідомлення від власника до водія, які очікують доставки. Новий JSON-потік у реальному часі лише для власника (?ajax=live) та картка «Повідомлення водіям» на панелі автопарку. Нова сторінка запрошення водія /{lang}/get-nakbus (25 мов).

Локалізовано назву, опис і параметри product_fleet_vehicles/live/history та параметри історії автопарку для всіх 25 мов порталу розробників.

/api/v1/data/truck-bans тепер повертає однаковий набір полів верхнього рівня незалежно від того, який запит спричинив відповідь. Раніше запит для країни без календарних заборон, нерозпізнаний ppid або звичайний збіг у базі даних могли по-різному пропускати поля (наприклад, country, covered_countries, ppid). Тепер кожна відповідь послідовно містить 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 і upcoming_bans (null або порожнє значення, якщо не застосовується), що спрощує розбір даних на стороні клієнта.

Дев'ять нових продуктів для окремих сервісів. Ті, що працюють з локацією, приймають lat/lon або city + country (ми самі геокодуємо місто за вас): /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 (станції, ранжовані за ціною для типу пального) та /api/v2/data/internet-points; результати містять distance_km і обмежені radius. /api/v2/data/vignettes відповідає, чи вимагає країна віньєтку, з актуальними цінами. Наявний продукт pois тепер підтримує lon і radius, як і задокументовано, а режим mode=nearest продукту fuel також приймає lon. Усі дев'ять доступні у пісочниці.

Кожна заборона в /api/v1/data/truck-bans тепер містить restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (точну зону дії або перелік доріг) та min_weight_tons. details_url тепер веде на сторінки для конкретних країн на nakordoni.eu. Новий необов'язковий параметр lang визначає мову назв країн і підсумку; за замовчуванням тепер англійська.

Некоректний ?ppid= тепер повертає справжню причину замість короткого "Request failed": помилка називає параметр, очікуваний формат id_<number> і вказує на /api/v1/data/checkpoints. Таблиці параметрів для stats, forecast, update-info, weather та bus-carriers тепер показують приклад id_13 всіма 25 мовами.

Оновлена оболонка порталу (верхня панель, бічне меню з іконками, панель KPI, картковий вигляд) тепер є стандартною для всіх авторизованих акаунтів розробників — раніше, ніж планований запуск 10 серпня. Щоб будь-коли повернутися до класичного вигляду, використовуйте ?v=1 для повернення до класичного вигляду будь-коли.

Усі сторінки порталу розробника — головна, документація, панель керування, AI Studio, пісочниця, тікети, запити, експорт, автопарк, новини, журнал змін і сторінки акаунта — більше не завантажують жодних рекламних скриптів чи рекламних блоків. Це діє на всьому порталі, а не лише на сторінках входу та реєстрації, як раніше.

Плануйте всю прикордонну поїздку одним запитом: /api/v2/data/route-plan повертає маршрут, пункти пропуску, які справді лежать на ньому, з живою чергою або прогнозом на час вашого прибуття, і зупинки, які водій дійсно робить — перерви на відпочинок, їжу, заправку — на одній шкалі часу.

Кордон є частиною цієї шкали. Довга черга зараховується як перерва, що вже назріла, і скидає лічильник часу за кермом, тож тригодинне очікування ніколи не подається як три години плюс повний набір перерв, яких ніхто не робив. Для авто діє модель безпечного водіння; автобуси та вантажівки отримують обов'язковий відпочинок за ЄС 561/2006, а сервісні витрати автобусів відкалібровані на понад 1000 ліцензованих міжнародних розкладів. Додайте stop_places=1, щоб для кожної зупинки назвати реальну зону відпочинку чи заправку, і via=lat,lon, щоб прокласти шлях через інший пункт пропуску.

Нове в меню порталу: Презентація — жива, завжди актуальна презентація дата-платформи nakordoni, персоналізована під ваш ринок (страхування, туризм, логістика, перевізники, медіа, навігація, паливо, фінтех, державний сектор або особисті проєкти). Вона показує реальні обсяги платформи за 30 днів, ваше власне використання API, статистику часу відповіді та лімітів, а також рекомендацію тарифу, коли ваші виклики впираються в межі безкоштовного рівня. Оберіть або підтвердьте свій ринок (чи кілька) на сторінці, у профілі — або під час реєстрації. Вона відкривається автоматично під час першого відвідування; автовідкриття можна вимкнути на самій сторінці.

Якщо в асистента увімкнено стрічку, але виклик не несе потрібного їй контексту — наприклад, queue без ppid— стрічка тепер пропускається ще до будь-якого запиту і не тарифікується. Раніше її все одно викликали, вона завершувалася помилкою і все одно коштувала одиницю. Студія показує, що потрібно кожній стрічці, перераховує ціну в міру заповнення контексту й позначає результати ✓ виконано / ⊘ пропущено, без оплати / ✕ помилка; API повертає data.feeds_skipped , де точно вказано, який параметр передати.

Відповіді більше не згадують стрічки, джерела даних чи будь-що технічне: відсутня стрічка — це щонайбільше одне звичайне речення для кінцевого користувача, ніколи не внутрішня назва. Стрічки лише з необов'язковими фільтрами (наприклад, fuel , звужена до країни, для якої в нас немає даних) тепер повертаються до широкого набору даних замість того, щоб не повертати нічого.

Нове: /{lang}/developers/studio. Створіть AI-асистента, який відповідає на основі ваших матеріалів і наших живих прикордонних даних. Надайте нам свій markdown або просто назвіть сторінки — ми їх завантажимо та проіндексуємо; ви підтримуєте лише власні файли. Оберіть, які з наших стрічок він може використовувати (черга, прогноз, альтернативи, денна статистика, паливо, заборони для вантажівок, торгові неділі, свята, стан доріг, автобусні перевізники, POI, валюта), оберіть рівень моделі (швидкий / збалансований / професійний — саме він визначає ціну), напишіть власні інструкції з заповнювачами {{feed.slug}} , які точно вказують, де наші дані з'являться у відповіді, і додайте власне завершальне речення, що додається до кожної відповіді. Готові шаблони: персональний туристичний асистент, робочий/вантажний асистент, асистент з продажу страхування та Зеленої карти.

Протестуйте його в студії (30 відповідей на день, окремо від вашої квоти API), а потім викликайте в продакшені через GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Ціна за відповідь = одиниці рівня моделі + 1 одиниця за кожну увімкнену стрічку; повертається в X-Devapi-Units. Продукт доступний лише у v2 — URL v1 повертає unsupported_version. Наявний продукт assistant не змінюється.

Кожен асистент працює за політикою вмісту платформи, яка має пріоритет над вашими інструкціями: жодного видавання себе за посадовців, жодної допомоги в обході прикордонного чи митного контролю, жодних вигаданих цифр, жодної лайки. Перевіряються і інструкції, і відповіді; заблоковані виклики журналюються.

Нове: справжній MCP-сервер за адресою https://nakordoni.eu/mcp, що надає безпечну підмножину API лише для читання (status, checkpoints, border queue, live queue, forecast) у вигляді MCP-інструментів. Той самий API-ключ і квота, що й у REST API. Картка сервера за адресою /.well-known/mcp/server-card.json. Див. розділ MCP-сервер у документації.

Перейменування на «Live Queue & Freshness API», описане нижче, фактично не дійшло до сторінки документації . Сторінка виводить назву кожного продукту через пошук перекладу, який звертається до назви ендпойнта лише тоді, коли перекладу немає — а переклад уже існував, зафіксований на старій назві, всіма 25 мовами інтерфейсу. Відтепер він має пріоритет над будь-яким майбутнім оновленням базової назви, доки не буде оновлений і сам.

Ключ перекладу перейменовано всіма 25 мовами, тож сторінка документації тепер збігається. Жодних змін ендпойнта, параметрів чи відповіді — лише текст назви.

Якщо ви часто опитуєте дані живої черги, ви, можливо, витрачаєте важку квоту без потреби. /update-info належить до стандартного класу і вже повертає актуальне значення:

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

Він повертає queue_now, freshness, age_minutes, is_realtime, status, timestamp і timezone. Використовуйте його для частого оновлення за рахунок стандартної денної квоти, а /queue, /multi і /forecast (усі важкого класу) залиште для випадків, коли потрібні wait_min, поля тренду чи історія.

У самому ендпойнті нічого не змінилося — лише в його документації. Він значився як «Data Freshness API», а його опис згадував тільки оцінку свіжості й жодного разу queue_now, тож його легко було проґавити. Тепер він має назву «Live Queue & Freshness API» з переліком полів, які повертаються. Дякуємо розробнику, який на це звернув увагу.

Деякі невдалі запити повертали HTTP 200 з ok: true і помилкою, схованою всередині data — тож задокументований шаблон if (!ok) throw не міг їх виявити, а виклик усе одно тарифікувався. Такі виклики тепер повертають HTTP 400 з ok: false і належними error.code / error.message, як задокументовано. Помічено на fuel-cities з непідтримуваною країною та на travel-matrix з некоректними координатами.

Окремо: відсутній обов'язковий параметр повертав 500 internal_error замість 400 bad_request (тіло відповіді 4xx від внутрішнього сервісу відкидалося до того, як прочитували його статус). Тепер повертається 400 bad_request з повідомленням від внутрішнього сервісу — наприклад, search без ?name=.

Успішні відповіді залишилися незмінними до байта — ті самі поля, ті самі параметри, та сама вартість квоти. Якщо ваш клієнт уже розгалужується за ok, змінювати нічого не потрібно. Якщо ж він ігнорував ok і читав data напряму, він тепер бачитиме конверти помилок на викликах, які й так завжди були невдалими.

Виправлено помилку, через яку /multi міг повертати неправильну кількість у черзі для деяких пунктів пропуску — переважно балканських і на кордоні Угорщина–Сербія — щоразу, коли його кеш був холодним. Резервний шлях читав таблицю, яка для цих пунктів не містить даних про чергу, і подавав сторонні значення як кількість авто. Виміряні приклади: пункт із 12 авто показував 6, а кілька пунктів зі справжніми чергами показували 0.

Три зміни, які ви можете помітити:

• found: false тепер означає, що свіжих даних про чергу справді немає. Раніше ви могли отримати found: true з вигаданим queue_now: 0.
• wait_status, trend_percent і trend_direction тепер повертаються на «холодних» запитах — раніше вони були null .
• Ендпойнт також переходить на резервний шлях, коли його кешований знімок застарілий (старший за 24 год), а не лише коли його немає.

Жодних змін у параметрах запиту, вартості квоти чи структурі відповіді.

Виправлено помилку, через яку кожен виклик /multi тарифікувався двічі — спочатку загальною перевіркою на 1 одиницю, а потім власною формулою змінної вартості ендпоінту (N PPID × підпродукти). Тепер виклик коштує рівно ⌈(N×M)/2⌉ одиниць, як і задокументовано, без додаткового нарахування.

Також на сторінці документації додано значок класу квоти (Standard/Heavy) для кожного продукту, щоб було одразу зрозуміло, яку денну квоту витрачає ендпоінт.

country та countries об'єднано в один параметр (1-15 кодів через кому). Новий параметр compare_to: порівняння однакових і різних свят між країнами, поєднується з upcoming+days. lang тепер приймає кілька мов (додає об'єкт names). days=0 або відсутній тепер означає без обмеження в режимі upcoming.

Офіційні державні свята для кожної європейської країни — дати, місцеві назви та тип. Працює на тому самому сервісі Nager.Date / OpenHolidaysAPI (з локально обчисленим календарем Косова), що й сторінка календаря свят nakordoni.eu та календарні фактори системи прогнозування.

• ?country=PL&year=2026 — повний річний перелік свят для однієї країни
• ?upcoming=1&days=30 — плоский список найближчих свят по країнах
• Без параметрів — індекс базового набору країн із найближчим святом для кожної

Додано продукт currency — курси обміну на основі EUR для PLN, CZK, HUF, USD, GBP, CHF, NOK та UAH, з джерела Frankfurter (ECB), кешуються на 6 годин. Без параметрів, завжди повертає повну таблицю курсів. Див. документацію.

Вбудуйте актуальні європейські заборони руху вантажівок на власний сайт — безкоштовний iframe-віджет із 3 дизайнами (light, dark, board), 5 мовами (en, uk, pl, de, ru), необов'язковим фільтром за країнами та живим статусом «зараз діє». Ключ API не потрібен. Налаштуйте та скопіюйте код на nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Потрібні сирі дані? Продукт API truck-bans та публічний JSON-фід залишаються доступними.

Три доповнення, усі зворотно сумісні — v1 без змін.

Версіонування на рівні ендпоінтів. Тепер є базова URL-адреса /api/v2/. Воно діє на рівні ендпоінтів: інакше поводяться лише ті ендпоінти, що дійсно змінилися; кожен інший ендпоінт прозоро віддає свою відповідь v1 (тож /api/v2/data/queue = ті самі дані, що й v1, лише з "api_version":"v2"). Мігрувати ендпоінти, які працюють, не потрібно.

border v2 є напрямленим. Порядок у шляху задає напрямок руху:

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)

Кожен пункт пропуску також отримує об'єкт direction {from,to} та булеве значення stale, а ?max_age_min=N повертає лише нещодавно оновлені пункти. (v1 border досі повертає обидві сторони кордону незалежно від порядку — без змін.)

Інтерактивний Sandbox. Авторизовані розробники тепер можуть спробувати будь-який ендпоінт із браузера на Developers → Sandbox — оберіть ендпоінт, версію та один зі своїх ключів, змініть параметри й побачте живу відповідь. Тестування в Sandbox має власний окремий добовий ліміт (50 calls/day) і ніколи не зачіпає вашу робочу квоту API.

Документацію тепер розділено за ендпоінтами (Developers → API Docs) із перемикачем версій на ендпоінтах, що мають більш ніж одну версію.

Два нових фактори додано до формули часу очікування, поряд із наявними коригуваннями section_mode та погодою:

• service_rate — виміряна кількість авто/хв, що зараз обробляються, порівняно з налаштованою базовою швидкістю пункту пропуску. Мультиплікативний, у межах 0.5x-1.5x.
• shift_change — вплив власної локальної зміни варти прикордонників о 08:00/20:00 на пункті пропуску. Адитивний (хвилини), а не мультиплікативний — застосовується лише в межах +/-60 хвилин від зміни, потребує мінімальної історії вибірки, обмежений до +/-120 хвилин.

advanced_wait_min тепер дорівнює round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Обидва фактори також відображаються в driver_reported.prognosed_advanced_wait_min для історичних порівнянь.

У межах перегляду безпеки/приватності видалено такі поля — вони розкривали внутрішні деталі реалізації (нашу таксономію джерел даних, ідентифікатори рядків БД, внутрішні анотації конвеєра, невикористані/мертві поля) без реальної продуктової цінності:

• id та corrected — видалено з об'єктів рядків queue
• source (сирий рядок, напр. "line") — видалено з queue, multi та update-info. update-info та multi (його блок update_info) досі містять source_category/source_label_en (невеликий публічний словник); queue та multi (його блок queue) більше не містять жодного поля джерела
• traffic_status — видалено з border; воно завжди було null і ніколи не заповнювалося жодною частиною системи

Якщо ваша інтеграція читає будь-яке з цих полів, оновіть її — див. поточний перелік полів на сторінці документації відповідного продукту.

Добове використання квоти (usage.used у кожній відповіді) тепер може бути десятковим значенням (напр. 67.5) замість завжди цілого числа. Це побічний ефект того, що queue-advanced тарифікується за дробовою ставкою — див. нижче. usage.limit не зачіпається й завжди є цілим числом. Якщо ваш клієнт строго типізує usage.used як ціле число, розширте його до прийняття десяткового/дробового значення.

Ці три продукти тепер повертають ті самі поля живого статусу, що показує сайт: wait_status (green/yellow/red, на основі власної нещодавньої історії цього пункту пропуску) та trend_percent/trend_direction (up/up-slight/down/down-slight/stable, порівняння останніх 3 годин). Суто адитивне.

У /api/v1/data/queue рядки data[] раніше мали wait_time: null для більшості джерел — лише кілька зовнішніх фідів повідомляють час очікування напряму. Рядки без нього тепер отримують стандартну оцінку , позначену новим булевим значенням wait_time_estimated, щоб ви могли відрізнити реально повідомлене значення від обчисленого.

queue-advanced тепер коштує 1.5 одиниці за виклик замість 1 (відображаючи додаткові запити трафіку/погоди/повідомлень водіїв, які він робить) — див. usage.used вище. Відповідь також більше не містить total_crossing_time, а driver_reported тепер лише {wait_min, ts, age_min} — попередні поля порівняння прогнозу з реальністю (prognosed_wait_min, diff_min, historical_section_mode, historical_weather тощо) видалено. section_mode, weather, advanced_wait_min та exceeds_crossing_time без змін.

/api/v1/data/truck-bans тепер повертає для кожної країни в bans_by_country значення status (active/clear) плюс active_window, next_window, local_time та tz — обчислені у власному часовому поясі цієї країни, тож вам більше не потрібно самостійно звіряти сирі вікна заборон із годинником. Відповідь також додає список covered_countries верхнього рівня та UTC-мітку часу as_of.

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

Суто адитивне — наявні поля current_bans/upcoming_bans/bans_by_country без змін. Невідомий ?country= тепер повертає порожній результат із countries_not_covered замість заборон усіх країн.

Новий підключуваний продукт, що коригує стандартний час очікування з урахуванням живого потоку трафіку та погоди. Повертає повну розбивку кожного коригування.

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

Надається за запитом — відкрийте тикет Data у своїй панелі, щоб увімкнути його.

/api/v1/data/border тепер коректно обчислює wait_min для кожного пункту пропуску у відповіді, як у продуктах queue та multi. Раніше це поле завжди було null.

/api/v1/data/forecast тепер надійно використовує ансамблеву модель v4 для будь-якого значення prediction_steps (раніше деякі нестандартні горизонти могли тихо відкочуватися до старішої моделі). Погодний фактор, що живить ансамбль, також виправлено, і він тепер справді відображає живі умови (дощ, сніг, вітер, туман) замість того, щоб завжди повідомляти про недоступність.

Схвалені розробники тепер можуть завантажувати усереднені за годину історичні дані черг на кордоні для до 5 пунктів пропуску (ковзне вікно до 90 днів) у форматі CSV або NDJSON з нової вкладки Data export. Дані лише опубліковані та перевірені на якість; мітки часу в UTC. Потрібен доступ? Відкрийте тикет Data.

Ще немає сайту? Тепер ви можете створити акаунт розробника, описавши, де і як плануєте використовувати наші дані, замість того щоб обов'язково вводити URL робочої сторінки. Додайте справжню URL пізніше зі своєї панелі (Account & data → Your project), щойно ваш сайт чи застосунок запрацює — видиме зворотне посилання на nakordoni.eu на цій сторінці вимагається нашими Умовами.

Розробники тепер можуть надсилати власні прикордонні новини до стрічки новин Nakordoni. Якщо наші редактори їх опублікують, ви отримаєте індексоване dofollow-посилання на ваш сервіс (згадка видавця + рядок джерела), і ми безкоштовно перекладемо статтю всіма 24 мовами.

Одна стаття на тиждень безкоштовно; додаткові статті — платне доповнення. Оберіть 'ми можемо трохи відредагувати + додати внутрішні посилання' або 'опублікувати як є'. Надсилайте та відстежуйте статус перевірки в розділі Developers → Submit news.

Multi-Checkpoint API (/api/v1/data/multi) тепер списує квоту за формулою ⌈(N PPIDs × sub-products) / 2⌉ — половина вартості еквівалентних окремих викликів. Запит на 10 пунктів пропуску з обома суб-продуктами тепер коштує 10 одиниць замість 20. Заголовок X-Devapi-Units та meta.units_consumed у відповіді відображають знижену суму.

Отримуйте живий статус черг та свіжість даних для до 20 пунктів пропуску одним викликом API — розроблено для творців дашбордів, які зараз опитують багато PPIDs у циклі.

Квота чесно рахується як N PPIDs × sub-products запитаних, тож загальне використання ідентичне окремим викликам — але з одним зверненням замість багатьох. Патерни в стилі GreenTravel зменшуються з 24+ викликів/годину до 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, оцінений wait_min, вік даних та назва пункту пропуску
• include=update-info — свіжість даних, класифікація джерела, вік у секундах/хвилинах
• Максимум 20 PPIDs на запит; поєднайте обидва суб-продукти в одному виклику для повних даних дашборда
• Відповідь містить meta.units_consumed, щоб ви могли точно відстежувати використання квоти

Відповідь продукту queue тепер містить об'єкт snapshot верхнього рівня з найсвіжішими даними в реальному часі та обчисленим прогнозованим часом очікування — та сама формула, що використовується в hero-секції 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

Масив data (історичні записи) без змін — це суто адитивне доповнення. Клієнти, які не читають snapshot, не зачіпаються.

Запитуйте всі пункти пропуску на заданому кордоні + тип транспорту одним викликом замість того, щоб робити окремий запит на кожен PPID.

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

• Підтримує одну країну призначення, список через кому або all для розгортання на всіх відстежуваних сусідів одразу.
• Результати відсортовано за queue_now за зростанням (спершу найкоротша черга).
• Повністю локалізовано: додайте ?lang=uk (або будь-яку з наших 22 підтримуваних мов), щоб отримати назви пунктів пропуску цією мовою.

Знаходьте значення PPID пунктів пропуску за назвою без перегляду всього каталогу.

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

• Приймає одну назву або список через кому (до 20).
• Шукає в усіх 24 мовах перекладу — передайте назву українською, польською, німецькою чи будь-якою підтримуваною мовою, і вона співпаде.
• Повертає всі PPIDs у цій локації, згруповані за типом транспорту (легковик / автобус / пішохід / вантажівка).

Продукт alternatives тепер приймає ?lang= усіма 22 підтримуваними мовами (було лише 12).

Новий параметр crossing_type дозволяє перевизначити фільтр типу транспорту — напр. передайте crossing_type=4, щоб отримати альтернативи для легковиків навіть під час запиту з автобусного PPID.

Поле crossing_type_label у відповідях checkpoints, border та search тепер перекладається на запитану мову всіма 22 підтримуваними мовами. Поля назв країн (origin_name, destination_name) слідують тій самій локалі.

Портал Nakordoni Developer API працює за адресою /en/developers. Зареєструйте безкоштовний ключ Explorer (200 requests/day), щоб отримати доступ до даних черг на кордоні, прогнозів, цін на пальне, POI для водіїв тощо.

Продукти, доступні на старті: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.