История на промените в API

Разработчически акаунти, свързани с акаунт в Nakordoni Partners със същия имейл, вече могат да подават новини и да управляват своя флот NakBus (NakDriver / NakManager) от partners.nakordoni.eu, с екипни роли (Owner, Manager, Viewer) и вход с едно кликване между двата портала. Страниците на портала за разработчици, 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 е описан заедно с останалите кодове за грешки в справочника.

Truck Parking (/api/v2/data/truck-parkings) връщаше записи с name равно на null и празен address — близо до Bensheim, 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 езика на сайта.

Cheapest Fuel (/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. Справочникът за Nearby Fuel Stations и Cheapest Fuel все още описваше по-стария плосък списък от редове 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 остава с една дестинация на заявка — това днес не се е променило. Промени се само как се комуникират 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 езика на сайта и изрично формулира правилото за една дестинация във 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). Това разделение е реално на самия пункт, но нито един интегратор не може да действа според него: заявка към v2 за 9 на границата UA-PL връщаше 21 от 70-те товарни пункта и нищо не го подсказваше. v4 отговаря на 9 с всички товарни ленти и приема 8 като псевдоним на 9. Всеки ред носи собствен crossing_type, така че обединеният отговор остава проверим.

Във v1 и v2 destination=all продължава да работи до 06.10.2026 и дотогава носи заглавките 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=.

Числовите ID в /border/{origin}/{destination}/{crossing_type} никога не бяха публикувани като таблица, затова интеграторите ги възстановяваха от часовите зони и примерните URL адреси. Сега те са в документацията под Кодове на държави и типове превозни средства, генерирани от същите таблици, спрямо които API валидира — ID на държавите заедно с границите, до които всяко се разгръща, и всеки crossing_type с етикета, който API връща.

Докато ги публикувахме, открихме, че sandbox средата и метаданните на крайната точка описват 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 още преди тя да влезе в сила и се прилагат от 06.10.2026. Моля, приемете ги в таблото си за управление.

Раздел 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-то Best Time to Cross (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 widget с 3 дизайна (light, dark, board), 5 езика (en, uk, pl, de, ru), незадължителен филтър по държава и актуален статус «активно сега». Не е нужен API ключ. Настройте и копирайте кода на nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Предпочитате сурови данни? Продуктът API truck-bans и публичният JSON feed остават достъпни.

Три допълнения, всички обратно съвместими — v1 остава непроменен.

Версиониране на ниво endpoint. Вече има базов URL /api/v2/. То е на ниво отделен endpoint: само endpoint-ите, които действително са се променили, се държат различно под v2; всеки друг endpoint прозрачно връща своя v1 отговор (така че /api/v2/data/queue = същите данни като v1, само с "api_version":"v2"). Няма нужда да мигрирате endpoint-и, които работят.

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)

Всеки checkpoint също получава обект direction {from,to} и булев stale, а ?max_age_min=N връща само наскоро обновените пунктове. (v1 border продължава да връща и двете страни на границата независимо от реда — непроменен.)

Интерактивен Sandbox. Влезлите разработчици вече могат да изпробват всеки endpoint направо от браузъра на Developers → Sandbox — изберете endpoint, версия и един от вашите ключове, променете параметрите и вижте отговора на живо. Тестването в Sandbox има собствен отделен дневен бюджет (50 заявки/ден) и никога не засяга реалната ви API квота.

Документацията вече е разделена по endpoint (Developers → API Docs) с избор на версия при endpoint-ите, които имат повече от една версия.

Във формулата за времето на изчакване са добавени два нови фактора, наред със съществуващите корекции 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 на редове в базата, вътрешни анотации на pipeline, неизползвани/мъртви полета) без реална продуктова стойност:

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

Ако вашата интеграция чете някое от тези полета, моля обновете я — вижте актуалния списък с полета на страницата с документация на съответния продукт.

Дневното използване на квотата (usage.used във всеки отговор) вече може да е десетична стойност (напр. 67.5) вместо винаги цяло число. Това е страничен ефект от това, че queue-advanced се таксува с дробна ставка — вижте по-долу. usage.limit не се засяга и винаги е цяло число. Ако вашият клиент строго типизира usage.used като цяло число, моля разширете го, за да приема десетично число/float.

Тези три продукта вече връщат същите полета за статус на живо, които показва сайтът: 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 ticket от таблото си, за да го активирате.

/api/v1/data/border вече правилно изчислява wait_min за всеки checkpoint в отговора, съответствайки на продуктите queue и multi. Преди това поле винаги беше null.

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

Одобрените разработчици вече могат да свалят усреднени по час исторически данни за граничните опашки за до 5 checkpoint-а (плъзгащ прозорец до 90 дни) като CSV или NDJSON от новия раздел Data export. Данните са само публикувани и проверени за качество; времевите маркери са в UTC. Нуждаете се от достъп? Отворете Data ticket.

Още нямате уебсайт? Вече можете да създадете акаунт за разработчици, като опишете къде и как планирате да използвате данните ни, вместо да сте задължени да въведете URL на активна страница. Добавете реалния URL по-късно от таблото си (Акаунт & данни → Вашият проект), веднага щом сайтът или приложението ви заработи — видима обратна връзка към nakordoni.eu на тази страница се изисква от нашите Условия.

Разработчиците вече могат да изпращат собствени новини, свързани с границите, към новинарската линия на Nakordoni. Ако редакторите ни ги публикуват, получавате индексируема dofollow обратна връзка към вашата услуга (посочен издател + ред за източник) и превеждаме статията на всичките 24 езика безплатно.

Една статия седмично е безплатна; допълнителните статии са платена добавка. Изберете 'може леко да редактираме + да добавим вътрешни връзки' или 'публикуване без промени'. Изпращайте и следете статуса на прегледа в Developers → Submit news.

Multi-Checkpoint API (/api/v1/data/multi) вече таксува квотата като ⌈(N PPIDs × под-продукти) / 2⌉ — половината от цената на еквивалентните индивидуални извиквания. Заявка за 10 checkpoint-а с двата под-продукта вече струва 10 единици вместо 20. Хедърът X-Devapi-Units и meta.units_consumed в отговора отразяват намалената сума.

Извличайте статус на опашката на живо и свежест на данните за до 20 checkpoint-а с едно API извикване — предназначено за създатели на табла, които в момента опитват много PPIDs в цикъл.

Квотата се брои справедливо като N PPIDs × под-продукти заявени, така че общото използване е идентично с индивидуалните извиквания — но с едно отиване-връщане вместо много. Модели от типа 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, възраст на данните и име на checkpoint
• include=update-info — свежест на данните, класификация на източника, възраст в секунди/минути
• Макс 20 PPIDs на заявка; комбинирайте двата под-продукта в едно извикване за пълни данни за таблото
• Отговорът включва meta.units_consumed, за да следите точно използването на квотата

Отговорът на продукта queue вече включва обект snapshot на най-горно ниво с най-новите данни в реално време и изчислено прогнозирано време на изчакване — същата формула, използвана в hero секцията на nakordoni.eu:

snapshot.queue_now  — current cars in queue
snapshot.wait_min   — prognosed wait time (minutes)
snapshot.updated_at — when the queue data was recorded
snapshot.age_min    — minutes since last update
snapshot.source     — data source identifier

Масивът data (исторически записи) е непроменен — това е чисто адитивно допълнение. Клиентите, които не четат snapshot, не се засягат.

Заявявайте всички checkpoint-и на дадена граница + тип превозно средство с едно извикване, вместо да правите по една заявка на PPID.

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

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

Откривайте стойностите на PPID на checkpoint-и по име, без да разглеждате целия указател.

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) следват същия locale.

Порталът Nakordoni Developer API е достъпен на /en/developers. Регистрирайте се за безплатен Explorer ключ (200 заявки/ден), за да получите достъп до данни за граничните опашки, прогнози, цени на горива, шофьорски POIs и още.

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