API o'zgarishlar jurnali

If an assistant has a feed enabled but the call does not carry the context that feed needs — queue without a ppid, for example — the feed is now skipped before any request is made and is not charged. Previously it was called anyway, failed, and still cost a unit. The studio shows what each feed needs, recalculates the price as you fill the context in, and marks results ✓ ran / ⊘ skipped, not charged / ✕ failed; the API returns data.feeds_skipped telling you exactly which parameter to pass.

Answers no longer mention feeds, data sources or anything technical: a missing feed is at most one plain sentence to the end user, never an internal name. Feeds with only optional filters (such as fuel narrowed to a country we have no data for) now fall back to the broad dataset instead of returning nothing.

New: /{lang}/developers/studio. Build an AI assistant that answers from your content and our live border data. Give us your markdown, or just name the pages and we fetch and index them — you only ever maintain your own files. Pick which of our feeds it may use (queue, forecast, alternatives, day-stats, fuel, truck bans, trading Sundays, holidays, road conditions, bus carriers, POIs, currency), pick a model tier (fast / balanced / pro — that is what sets the price), write your own instructions with {{feed.slug}} placeholders saying exactly where our data lands in the answer, and add a closing sentence of your own that is appended to every reply. Ready-made blueprints: personal travel assistant, work/freight assistant, insurance & Green Card sales assistant.

Test it in the studio (30 answers/day, separate from your API quota), then call it in production at GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Price per answer = model tier units + 1 unit per enabled feed, returned in X-Devapi-Units. The product is v2-only — a v1 URL returns unsupported_version. The existing assistant product is unchanged.

Every assistant runs under a platform content policy that outranks your instructions: no impersonating officials, no help evading border or customs control, no invented numbers, no profanity. Instructions and answers are both screened; blocked calls are logged.

Yangilik: https://nakordoni.eu/mcp manzilidagi haqiqiy MCP server, API-ning xavfsiz, faqat o'qish uchun mo'ljallangan qismini (status, checkpoints, border queue, live queue, forecast) MCP vositalari sifatida taqdim etadi. REST API bilan bir xil API kaliti va kvota. Server kartasi /.well-known/mcp/server-card.json manzilida. Hujjatlardagi MCP server bo'limiga qarang.

The retitle to "Live Queue & Freshness API" below did not actually reach the docs page. The page renders each product title through a translation lookup that falls back to the endpoint's title only when no translation exists — and a translation already existed, frozen at the old name, in all 25 UI languages. It now wins over any future update to the underlying title until it is updated too.

Retitled the translation key in all 25 languages so the docs page matches. No endpoint, parameter or response change — title text only.

If you poll live queue data frequently, you may be spending heavy quota you do not need to. /update-info is standard-class and already returns the live figure:

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

It returns queue_now, freshness, age_minutes, is_realtime, status, timestamp and timezone. Use it for the frequent refresh against your standard daily quota, and keep /queue, /multi and /forecast (all heavy-class) for when you need wait_min, the trend fields or history.

Nothing changed in the endpoint itself — only its documentation. It was listed as the "Data Freshness API" and its description mentioned only the freshness rating, never queue_now, so it was easy to miss. It is now titled "Live Queue & Freshness API" with the returned fields spelled out. Thanks to the developer who raised this.

Some failed requests were returning HTTP 200 with ok: true and the error buried inside data — so the documented if (!ok) throw pattern could not detect them, and the call was still billed. Affected calls now return HTTP 400 with ok: false and a proper error.code / error.message, as documented. Seen on fuel-cities with an unsupported country and travel-matrix with malformed coordinates.

Separately, a missing required parameter returned 500 internal_error instead of 400 bad_request (an upstream 4xx body was being discarded before its status was read). It now returns 400 bad_request with the upstream message — e.g. search without ?name=.

Successful responses are byte-for-byte unchanged — same fields, same params, same quota cost. If your client already branches on ok, no change is needed. If it ignored ok and read data directly, it will now see error envelopes on calls that were always failing.

Fixed a bug where /multi could return a wrong queue count for some checkpoints — mainly Balkan and Hungary–Serbia crossings — whenever its cache was cold. The fallback read a table that, for those crossings, holds no queue data, and reported unrelated values as car counts. Measured examples: a checkpoint with 12 cars reported 6, and several with real queues reported 0.

Three changes you may notice:

• found: false now means there is genuinely no recent queue data. Previously you could receive found: true with a fabricated queue_now: 0.
• wait_status, trend_percent and trend_direction are now returned on cold requests — they were null before.
• The endpoint also falls back when its cached snapshot is stale (older than 24h), not only when it is missing.

No changes to request parameters, quota cost or response shape.

Har bir /multi chaqiruvi ikki marta hisoblanadigan xato tuzatildi — avval umumiy 1 birlik tekshiruvi orqali, keyin esa endpointning o'z o'zgaruvchan narx formulasi orqali (N PPID × quyi mahsulotlar). Endi chaqiruv hujjatlashtirilganidek aynan ⌈(N×M)/2⌉ birlikka tushadi, qo'shimcha to'lovsiz.

Shuningdek, hujjatlar sahifasida har bir mahsulotga kvota sinfi belgisi (Standard/Heavy) qo'shildi, shunda endpoint qaysi kunlik kvotadan foydalanishi bir qarashda ma'lum bo'ladi.

country va countries bitta parametrga birlashtirildi (1-15 vergul bilan ajratilgan kod). Yangi compare_to parametri: mamlakatlar o'rtasida bir xil yoki turli bayramlarni taqqoslash, upcoming+days bilan birga ishlaydi. lang endi bir nechta tilni qabul qiladi (names obyektini qo'shadi). days=0 yoki tushirib qoldirilgan endi upcoming rejimida cheklov yo'q degani.

Har bir Yevropa mamlakati bo'yicha rasmiy davlat bayramlari — sanalar, mahalliy nomlar va turi. nakordoni.eu bayramlar kalendari sahifasini va bashorat tizimining kalendar omillarini ta'minlaydigan xuddi shu Nager.Date / OpenHolidaysAPI xizmatiga asoslangan (mahalliy hisoblangan Kosovo kalendari bilan).

• ?country=PL&year=2026 — bitta mamlakat uchun to'liq yillik bayramlar ro'yxati
• ?upcoming=1&days=30 — mamlakatlar bo'yicha yaqinlashib kelayotgan bayramlarning tekis ro'yxati
• Parametrsiz — asosiy mamlakatlar to'plamining indeksi, har birining keyingi bayrami bilan

currency mahsuloti qo'shildi — PLN, CZK, HUF, USD, GBP, CHF, NOK va UAH uchun EUR asosidagi ayirboshlash kurslari, Frankfurter (ECB) manbasidan olinib, 6 soat keshlanadi. Parametrsiz, har doim to'liq kurslar jadvalini qaytaradi. hujjatlarni ko'ring.

Yevropa yuk mashinalari harakatiga real vaqtdagi taqiqlarni o'z veb-saytingizga joylashtiring — 3 dizaynli (light, dark, board), 5 tilli (en, uk, pl, de, ru), ixtiyoriy mamlakat bo'yicha filtri va «active now» jonli holati bo'lgan bepul iframe vidjeti. API kaliti kerak emas. Kodni bu yerda sozlab, nusxalab oling: nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Xom ma'lumotni afzal ko'rasizmi? truck-bans API mahsuloti va ochiq JSON tasmasi hamon mavjud.

Uchta qo'shimcha, barchasi orqaga mos — v1 o'zgarishsiz.

Har bir endpoint bo'yicha versiyalash. Endi /api/v2/ asosiy URL mavjud. U har bir endpoint bo'yicha: faqat haqiqatan o'zgargan endpointlar v2 da boshqacha ishlaydi; qolgan har bir endpoint o'zining v1 javobini shaffof tarzda beradi (shuning uchun /api/v2/data/queue = v1 dagi xuddi shu ma'lumot, faqat "api_version":"v2" bilan). Ishlayotgan endpointlarni ko'chirish shart emas.

border v2 yo'nalishlidir. Yo'l tartibi — sayohat yo'nalishi:

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)

Har bir nazorat punkti shuningdek direction {from,to} obyektini va stale mantiqiy qiymatini oladi, ?max_age_min=N esa faqat yaqinda yangilangan o'tish joylarini qaytaradi. (v1 border tartibdan qat'i nazar chegaraning ikkala tomonini ham qaytaradi — o'zgarishsiz.)

Interaktiv Sandbox. Tizimga kirgan ishlab chiquvchilar endi istalgan endpointni brauzerdan bu yerda sinab ko'rishlari mumkin: Developers → Sandbox — endpoint, versiya va kalitlaringizdan birini tanlab, parametrlarni o'zgartiring va jonli javobni ko'ring. Sandbox sinovining o'ziga xos alohida kunlik byudjeti bor (50 calls/day) va sizning jonli API kvotangizga hech qachon tegmaydi.

Hujjatlar endi har bir endpoint bo'yicha ajratilgan (Developers → API Docs), bittadan ortiq versiyasi bor endpointlarda versiya tanlagichi bilan.

Kutish vaqti formulasiga mavjud section_mode va ob-havo tuzatishlari bilan bir qatorda ikkita yangi omil qo'shildi:

• service_rate — hozir qayta ishlanayotgan o'lchangan mashina/daqiqa nisbatan nazorat punktining sozlangan bazaviy tezligiga. Ko'paytiruvchi, 0.5x-1.5x oralig'ida chegaralangan.
• shift_change — nazorat punktining o'z mahalliy 08:00/20:00 chegarachilar smenasi almashinuvining ta'siri. Qo'shimcha (daqiqalar), ko'paytiruvchi emas — faqat smenadan +/-60 daqiqa ichida qo'llaniladi, minimal namuna tarixini talab qiladi, +/-120 daqiqaga chegaralangan.

advanced_wait_min endi round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Ikkala omil ham tarixiy taqqoslashlar uchun driver_reported.prognosed_advanced_wait_min da aks etadi.

Xavfsizlik/maxfiylik ko'rigi doirasida quyidagi maydonlar olib tashlandi — ular haqiqiy mahsulot qiymatiga ega bo'lmagan ichki amalga oshirish tafsilotlarini (bizning manba taksonomiyasi, DB row ID lari, ichki pipeline izohlari, ishlatilmaydigan/o'lik maydonlar) oshkor qilardi:

• id va corrected — queue row obyektlaridan olib tashlandi
• tmin/tpercar — queue, border va multi dan olib tashlandi (kutish vaqti formulasining doimiylari; allaqachon hisoblangan wait_min/wait_time ta'sirlanmaydi)
• source (xom satr, masalan "line") — queue, multi va update-info dan olib tashlandi. update-info va multi ning update_info bloki hamon source_category/source_label_en ni (kichik ochiq lug'at) olib yuradi; queue va multi ning queue bloki endi hech qanday source maydonini olib yurmaydi
• traffic_status — border dan olib tashlandi; u har doim null edi va tizimning hech qaysi qismi tomonidan hech qachon to'ldirilmagan

Agar integratsiyangiz shu maydonlardan birortasini o'qisa, uni yangilang — tegishli mahsulotning hujjatlar sahifasidagi joriy maydonlar ro'yxatini ko'ring.

Kunlik kvota sarfi (har bir javobdagi usage.used) endi har doim butun son bo'lish o'rniga o'nlik qiymat (masalan 67.5) bo'lishi mumkin. Bu queue-advanced ning kasrli stavkada hisoblanishining yon ta'siri — quyiga qarang. usage.limit ta'sirlanmaydi va har doim butun son. Agar mijozingiz usage.used ni qat'iy butun son sifatida turlasa, uni o'nlik/float qabul qiladigan qilib kengaytiring.

Bu uch mahsulot endi veb-sayt ko'rsatadigan xuddi shu jonli holat maydonlarini qaytaradi: wait_status (green/yellow/red, ushbu nazorat punktining o'z so'nggi tarixiga asoslangan) va trend_percent/trend_direction (up/up-slight/down/down-slight/stable, so'nggi 3 soatni taqqoslab). Sof qo'shimcha.

/api/v1/data/queue ning data[] row larida ilgari ko'pchilik manbalar uchun wait_time: null bo'lardi — faqat bir nechta manba kutish vaqtini to'g'ridan-to'g'ri xabar qiladi. Usiz row lar endi standart tmin + queue×tpercar bahosini oladi, yangi wait_time_estimated mantiqiy qiymati bilan belgilanadi, shuning uchun haqiqiy xabar qilingan ko'rsatkichni hisoblanganidan ajrata olasiz.

queue-advanced endi bir qo'ng'iroqqa 1 o'rniga 1.5 birlik turadi (u bajaradigan qo'shimcha traffic/weather/driver-report qidiruvlarini aks ettirib) — yuqoridagi usage.used ni ko'ring. Javob shuningdek endi tmin, tpercar yoki total_crossing_time ni o'z ichiga olmaydi, driver_reported esa endi shunchaki {wait_min, ts, age_min} — oldingi bashorat-haqiqat taqqoslash maydonlari (prognosed_wait_min, diff_min, historical_section_mode, historical_weather va h.k.) olib tashlandi. section_mode, weather, advanced_wait_min va exceeds_crossing_time o'zgarishsiz.

/api/v1/data/truck-bans endi bans_by_country dagi har bir mamlakat uchun status (active/clear) plus active_window, next_window, local_time va tz ni qaytaradi — o'sha mamlakatning o'z vaqt mintaqasida hisoblangan, shuning uchun endi xom taqiq oynalarini soatga nisbatan o'zingiz baholashingiz shart emas. Javobga shuningdek yuqori darajadagi covered_countries ro'yxati va as_of UTC vaqt belgisi qo'shiladi.

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

Sof qo'shimcha — mavjud current_bans/upcoming_bans/bans_by_country maydonlari o'zgarishsiz. Noma'lum ?country= endi har bir mamlakatning taqiqlari o'rniga countries_not_covered bilan bo'sh natija qaytaradi.

Standart kutish vaqtini jonli transport oqimi va ob-havoga moslashtiradigan yangi ixtiyoriy mahsulot. Har bir moslashtirishning to'liq tahlilini qaytaradi.

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

So'rov bo'yicha beriladi — uni yoqish uchun boshqaruv panelingizdan Data tiketini oching.

/api/v1/data/border endi javobdagi har bir nazorat punkti uchun wait_min ni to'g'ri hisoblaydi (va tmin/tpercar ni qaytaradi), queue va multi mahsulotlariga mos ravishda. Ilgari bu maydon har doim null edi.

/api/v1/data/forecast endi istalgan prediction_steps qiymati uchun v4 ansambl modelini ishonchli tarzda ishlatadi (ilgari ba'zi nostandart gorizontlar sekin eski modelga qaytishi mumkin edi). Ansamblni ta'minlaydigan ob-havo omili ham tuzatildi va endi har doim mavjud emas deb xabar qilish o'rniga jonli sharoitlarni (yomg'ir, qor, shamol, tuman) chinakam aks ettiradi.

Tasdiqlangan ishlab chiquvchilar endi 5 tagacha nazorat punkti uchun (90 kungacha siljuvchi oyna) soatlik o'rtachalangan tarixiy chegara navbati ma'lumotlarini yangi Data export yorlig'idan CSV yoki NDJSON sifatida yuklab olishlari mumkin. Ma'lumotlar faqat chop etilgan va sifati tekshirilgan; vaqt belgilari UTC da. Kirish kerakmi? Data tiketini oching.

Hali veb-saytingiz yo'qmi? Endi jonli sahifa URL ini kiritishga majbur bo'lish o'rniga, ma'lumotlarimizni qayerda va qanday ishlatmoqchi ekaningizni tasvirlab, ishlab chiquvchi hisobini yaratishingiz mumkin. Saytingiz yoki ilovangiz ishga tushishi bilan haqiqiy URL ni keyinroq boshqaruv panelingizdan qo'shing (Account & data → Your project) — o'sha sahifada nakordoni.eu ga ko'rinadigan orqaga havola bizning Shartlarimiz bilan talab qilinadi.

Ishlab chiquvchilar endi o'zlarining chegaraga oid yangiliklarini Nakordoni yangiliklar tasmasiga yuborishlari mumkin. Agar muharrirlarimiz uni chop etsa, siz o'z xizmatingizga indekslanadigan dofollow orqaga havola olasiz (nashriyot imzosi + manba satri) va biz maqolani barcha 24 tilga bepul tarjima qilamiz.

Haftasiga bitta maqola bepul; qo'shimcha maqolalar pullik qo'shimcha. 'biz uni yengil tahrirlashimiz + ichki havolalar qo'shishimiz mumkin' yoki 'o'zgartirilmasdan chop etish' ni tanlang. Yuboring va ko'rib chiqish holatini bu yerda kuzating: Developers → Submit news.

Multi-Checkpoint API (/api/v1/data/multi) endi kvotani ⌈(N PPIDs × sub-products) / 2⌉ sifatida hisoblaydi — ekvivalent alohida qo'ng'iroqlarning yarmi narxi. Ikkala sub-product bilan 10 ta nazorat punktiga so'rov endi 20 o'rniga 10 birlik turadi. Javobdagi X-Devapi-Units sarlavhasi va meta.units_consumed chegirmali miqdorni aks ettiradi.

Bitta API qo'ng'irog'ida 20 tagacha nazorat punkti uchun jonli navbat holati va ma'lumotlar yangiligini oling — hozir ko'plab PPID larni tsiklda so'raydigan boshqaruv paneli quruvchilari uchun mo'ljallangan.

Kvota so'ralgan N PPIDs × sub-products sifatida adolatli hisoblanadi, shuning uchun umumiy sarf alohida qo'ng'iroqlarga bir xil — ammo ko'p o'rniga bitta murojaat bilan. GreenTravel uslubidagi shablonlar soatiga 24+ qo'ng'iroqdan 2 taga tushadi.

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

• include=queue — joriy queue_now, taxminiy wait_min, ma'lumot yoshi va nazorat punkti nomi
• include=update-info — ma'lumotlar yangiligi, manba tasnifi, soniya/daqiqadagi yoshi
• So'rovga ko'pi bilan 20 PPID; to'liq boshqaruv paneli ma'lumotlari uchun ikkala sub-product ni bitta qo'ng'iroqda birlashtiring
• Javob meta.units_consumed ni o'z ichiga oladi, shuning uchun kvota sarfini aniq kuzatishingiz mumkin

queue mahsuloti javobi endi eng so'nggi real vaqtdagi ma'lumot va hisoblangan bashorat qilingan kutish vaqti bilan yuqori darajadagi snapshot obyektini o'z ichiga oladi — nakordoni.eu hero bo'limida ishlatiladigan xuddi shu formula:

snapshot.queue_now  — current cars in queue
snapshot.wait_min   — tmin + queue_now × tpercar (minutes)
snapshot.tmin       — minimum crossing time (minutes)
snapshot.tpercar    — added time per vehicle (minutes)
snapshot.updated_at — when the queue data was recorded
snapshot.age_min    — minutes since last update
snapshot.source     — data source identifier

data massivi (tarixiy yozuvlar) o'zgarishsiz — bu sof qo'shimcha to'ldiruv. snapshot ni o'qimaydigan mijozlar ta'sirlanmaydi.

Har bir PPID ga bitta so'rov qilish o'rniga berilgan chegara + transport turi bo'yicha barcha nazorat punktlarini bitta qo'ng'iroqda so'rang.

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

• Bitta manzil mamlakatni, vergul bilan ajratilgan ro'yxatni yoki har bir kuzatiladigan qo'shnini bir vaqtning o'zida kengaytirish uchun all ni qo'llab-quvvatlaydi.
• Natijalar queue_now bo'yicha o'sish tartibida saralangan (eng qisqa navbat birinchi).
• To'liq lokalizatsiyalangan: o'sha tildagi nazorat punktlari nomlarini olish uchun ?lang=uk (yoki bizning 22 qo'llab-quvvatlanadigan tildan istalganini) qo'shing.

To'liq katalogni ko'rib chiqmasdan nazorat punktining PPID qiymatlarini nomi bo'yicha toping.

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

• Bitta nomni yoki vergul bilan ajratilgan ro'yxatni (20 tagacha) qabul qiladi.
• Barcha 24 tarjima tilida qidiradi — nomni ukrain, polyak, nemis yoki istalgan qo'llab-quvvatlanadigan tilda bering, u mos keladi.
• O'sha joydagi barcha PPID larni transport turi bo'yicha guruhlangan holda qaytaradi (car / bus / pedestrian / truck).

alternatives mahsuloti endi ?lang= ni barcha 22 qo'llab-quvvatlanadigan tilda qabul qiladi (faqat 12 ta edi).

Yangi crossing_type parametri transport turi filtrini almashtirishga imkon beradi — masalan, bus PPID dan so'raganda ham mashina alternativalarini olish uchun crossing_type=4 ni bering.

crossing_type_label maydoni checkpoints, border va search javoblarida endi so'ralgan tilga barcha 22 qo'llab-quvvatlanadigan tilda tarjima qilinadi. Mamlakat nomi maydonlari (origin_name, destination_name) xuddi shu lokalga ergashadi.

Nakordoni Developer API portali bu yerda ishga tushdi: /en/developers. Chegara navbati ma'lumotlari, bashoratlar, yoqilg'i narxlari, haydovchi POI lari va boshqalarga kirish uchun bepul Explorer kalitiga (200 requests/day) ro'yxatdan o'ting.

Ishga tushirishda mavjud mahsulotlar: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.