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-თან ახლოს 50-იდან 20 ასეთი იყო. ეს ის ადგილებია, რომლებსაც მხოლოდ კოორდინატის სახით ვინახავთ: არაფერია გამოსატანი და არაფერია თქვენს საკუთარ 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, ხოლო პოლონეთი მასში Trójmiasto-ს რეგიონამდე იყო შევიწროებული. ორივე მტკიცება დიდი ხნის წინ მოძველდა. დაფარვა ახლა სადგურების ცოცხალი ინდექსიდან იზომება და ყოველ ექვს საათში ხელახლა გამოითვლება: 39 ქვეყანაში დღეს არის სადგურები ფასებით, მათ შორის პოლონეთში მთელ ქვეყანაში, და არა სამ ქალაქში. თავად მოთხოვნაში არაფერი იცვლება: არც პარამეტრი, არც ვერსია.

Nearby Fuel Stations და Cheapest Fuel: როცა ძიება ცარიელი ბრუნდება, ბლოკი coverage ახლა შეიცავს გაზომილ station_countries, station_counts, sparse_coverage და measured_at მნიშვნელობებს, შევიწროებულს თქვენ მიერ მოთხოვნილ საწვავის სახეობაზე და არა საწვავზე ზოგადად. ქვეყანა sparse_coverage-ში ხვდება მაშინ, როცა იქ 25 ან ნაკლები ფასიანი სადგური გვაქვს — ეს დათვლაა და არა შეფასება.

გაჩნდა ახალი შენიშვნა იმ სახეობისთვის, რომელსაც ვცნობთ, მაგრამ რომელსაც იქ, სადაც იკითხეთ, არავინ აფასებს. აქამდე coverage.fuel_type_note ჩნდებოდა მხოლოდ მაშინ, როცა თავად სვეტის სახელი ჩვენთვის უცნობი იყო. ახლა ის ჩნდება მაშინაც, როცა სახელი სწორად ამოიცნობა, მაგრამ ამ ქვეყანაში მისთვის უბრალოდ ფასი არ არსებობს; შენიშვნა ასახელებს ქვეყნებს, სადაც ეს სახეობა ფასდება, და იმ სახეობებს, რომლებსაც თქვენს გარშემო ვაფასებთ. ჩეხური სახელი Natural 100 სუფთა მაგალითია: ის ამოიცნობა, მაგრამ ჩეხეთში მას არცერთი წყარო ფასს არ აძლევს. ცარიელი პასუხი აღარ გამოიყურება გაფუჭებულ მოთხოვნად.

Fuel Grades (/api/v2/data/fuel-grades) იღებს priced_countries-სა და priced_station_counts-ს ყოველი სახეობისთვის, ასევე priced_here-ს, როცა გადასცემთ ?country=-ს. ორი სია სხვადასხვა რამეს ნიშნავს: ქვეყანა countries-ში ის ქვეყანაა, სადაც ამ სვეტის სახელს ვიღებთ, ხოლო priced_countries გვიჩვენებს, სად აფასებს მას წყარო სინამდვილეში, ამიტომ priced_here ნულით ნამდვილი პასუხია და არა ხარვეზი პასუხში. თან მოჰყვება 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 თვეში. რაოდენობის შეცვლისას ზუსტი პროპორციული ანგარიში ჩანს, სანამ რაიმე თანხა ჩამოიჭრება.

2026 წლის 10 ნოემბრიდან თითოეული გეგმა მოიცავს დეკლარირებული ქვეყნების განსაზღვრულ რაოდენობას: Explorer და Student 4, Starter 10, Pro და ზემოთ შეუზღუდავი. ამ თარიღიდან ვერ შეინახება დეკლარაცია, რომელიც აღემატება გეგმას პლუს შეძენილ დამატებით ქვეყნებს; ჩანართი „ანგარიში“ უკვე გიჩვენებთ თქვენს ლიმიტს, ხოლო ანგარიშები, რომლებიც მას უკვე აჭარბებენ, ხედავენ შეთავაზებას დაფაზე. 10 ნოემბრამდე არაფერი იცვლება.

API sandbox ახლა სიაში ყოველ ბოლო წერტილს ნიშნავს მისი კვოტის კლასით (მძიმე / სტანდარტული), აჩვენებს არჩეული ვერსიის კვოტის ხარჯს სანამ რამეს გაუშვებთ, ხოლო გამოძახების შემდეგ აჩვენებს, რა დაუჯდებოდა იგივე გამოძახება თქვენს რეალურ კვოტას — მათ შორის ფორმულა ceil(N ppids × M sub-products / 2), რომელიც გამოიყენება /multi ფორმის გამოძახებებისთვის.

ეს მხოლოდ წასაკითხი გადახედვაა: sandbox-ის გამოძახებები ჩამოიჭრება sandbox-ის ცალკე სატესტო ბიუჯეტიდან და არასოდეს თქვენი რეალური კვოტიდან.

დღეიდან ყველაფერი, რაც საჯაროდ გამოვაცხადეთ გასაუქმებლად, დახურულია დეველოპერული ანგარიშებისთვის, რომლებიც შეიქმნა გამოცხადების თარიღს ან მის შემდეგ. თუ თქვენი ანგარიში გამოცხადებამდე არსებობდა, არაფერი იცვლება — გრჩებათ სრული საშეღავათო პერიოდი იმ გაუქმების თარიღამდე, რომელიც მითითებულია მისი გამოცხადების ჩანაწერში.

რატომ არსებობს ეს წესი. 2026 წლის 24 აგვისტოს გამოვაცხადეთ, რომ truck-bans v1 უქმდება 2026 წლის 8 სექტემბერს. ორი ანგარიში ამ გამოცხადებიდან რამდენიმე დღეში დარეგისტრირდა, ინტეგრაცია v1-ზე ააგო და 410-მდე საათები დარჩა, თუმცა ჩვენი არცერთი ელფოსტა მათ არ მისვლია: გამოცხადებაც და შეტყობინებების პარტიაც მათ რეგისტრაციას უსწრებდა. API-ში ვერაფერმა შეაჩერა ისინი, აეღოთ ვერსია, რომელზეც უკვე გვქონდა ნათქვამი, რომ ქრებოდა. ეს ჩვენი შეცდომა იყო და ეს არის მისი გამოსწორება — ვერ დაიწყებთ იმის გამოყენებას, რაც უკვე დაგეგმილია მოსაშორებლად.

როგორ გამოიყურება. ასეთ მოთხოვნაზე პასუხი არის უარი 410 Gone-ით და შეცდომის კოდით version_closed_to_new_accounts. შეტყობინება ასახელებს გაუქმების თარიღს, გამოცხადების თარიღს და იმ ვერსიას, რომელიც სანაცვლოდ უნდა გამოიყენოთ. ეს განზრახ სხვა კოდია, ვიდრე version_sunset, რომელსაც ყველა ანგარიში იღებს მას შემდეგ, რაც თავად გაუქმების თარიღი გავა — მხარდაჭერას ლოგის კითხვის გარეშე შეუძლია გაარჩიოს „დაგვიანებით მოხვედით დასაწყებად“ და „ეს ყველასთვის აღარ არსებობს“.

შენარჩუნება განისაზღვრება ანგარიშის შექმნის თარიღით და არა პირველი მოთხოვნით. თუ დარეგისტრირდით გამოცხადებამდე, მაგრამ ინტეგრაციას მხოლოდ ახლა იწყებთ, მაინც იღებთ სრულ საშეღავათო პერიოდს: შესაძლოა თავიდანვე მასზე აგებდით.

ძალაშია ახლავე truck-bans v1-ისთვის (გამოცხადდა 2026 წლის 24 აგვისტოს, უქმდება 2026 წლის 8 სექტემბერს) და ავტომატურად ყველა გაუქმებისთვის, რომელსაც ამიერიდან გამოვაცხადებთ. თქვენგან ახალი არაფერი მოითხოვება: გასაუქმებელ ვერსიაზე ყოველი პასუხი უკვე ატარებს Deprecation, Sunset და Link: rel="successor-version" ჰედერებს, ასე რომ ახალ ინტეგრაციას მოახლოებული გაუქმება ამ გვერდის წაკითხვის გარეშეც დაენახება.

გუშინდელი v4 ცვლილების გაგრძელება (დეველოპერული ბილეთი #105). v1-სა და v2-ში მძიმეებით გამოყოფილი destination სიები კვლავ მუშაობს, მაგრამ ახლა ექვემდებარება იმავე ვადას, რასაც destination=all: ორივე ჩერდება 2026-10-06 თარიღს (მანამდე Deprecation/Sunset ჰედერები, შემდეგ 400 destination_list_removed, რომელიც ჩამნაცვლებლად ასახელებს /api/v4/-ს). მძიმეებიანი სიების არსებული 10-ელემენტიანი ლიმიტის შემოწმება ამ თარიღამდე უცვლელი რჩება.

v4 რჩება ერთ დანიშნულებაზე თითო გამოძახებაში — ეს დღეს არ შეცვლილა. შეიცვალა მხოლოდ ის, როგორ ვაწვდით ინფორმაციას v1/v2-ზე: destination=all-ის 400 შეცდომა აღარ გვთავაზობს მძიმეებიან სიას მიგრაციის გზად (ის იმავე თარიღს დაიხურებოდა), არამედ პირდაპირ 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 საზღვარზე აბრუნებდა 70 სატვირთო გადასასვლელიდან 21-ს და ამაზე არაფერი მიუთითებდა. v4 პასუხობს 9-ს ყველა სატვირთო ზოლით და იღებს 8-ს როგორც 9-ის ალიასს. თითოეულ სტრიქონს აქვს საკუთარი crossing_type, ამიტომ გაერთიანებული პასუხი შესამოწმებელი რჩება.

v1-სა და v2-ში destination=all მუშაობს 2026 წლის 6 ოქტომბრამდე და მანამდე ატარებს Deprecation / Sunset სათაურებს. ამ თარიღიდან ეს ვერსიებიც 400-ით პასუხობენ all-ზე — v1-ისა და v2-ის დანარჩენი ნაწილი უცვლელია და ხელმისაწვდომი რჩება. იგივე თარიღი ვრცელდება სხვა „ყველა ქვეყნის“ მალსახმობებზე: travel-matrix ?dest=-ის გარეშე, bus-carriers ?ppid=all-ით და fuel-grades ?country=-ის გარეშე.

v3, რომელიც დღესვე ადრე გამოცხადდა, ჩანაცვლებულია v4-ით. v3 v4-სგან მხოლოდ იმით განსხვავდებოდა, რომ ჯერ კიდევ იღებდა მძიმიან სიას, და ამ ფორმას არცერთი ინტეგრაცია არ იყენებს. v3-ის URL-ები კვლავ პასუხობენ, რომ მათზე დაწერილი არაფერი გაფუჭდეს, მაგრამ v3 არ არის დოკუმენტირებული და აღარ განვითარდება — გადადით v4-ზე.

დანარჩენი ყველაფერი v4-ში v2-ის იდენტურია: მიმართულებითი გზის თანმიმდევრობა, direction{from,to}, stale და ?max_age_min=.

/border/{origin}/{destination}/{crossing_type}-ში გამოყენებული რიცხვითი იდენტიფიკატორები არასოდეს გამოქვეყნებულა ცხრილის სახით, ამიტომ ინტეგრატორები მათ დროის სარტყლებიდან და მაგალითის URL-ებიდან აღადგენდნენ. ახლა ისინი დოკუმენტაციაშია, განყოფილებაში ქვეყნებისა და ტრანსპორტის ტიპების კოდები, და გენერირდება იმავე ცხრილებიდან, რომლებზეც API ამოწმებს მოთხოვნებს — ქვეყნების იდენტიფიკატორები იმ საზღვრებთან ერთად, რომლებშიც თითოეული იშლება, და ყოველი 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-ს მის ძალაში შესვლამდე და მოქმედებს 2026 წლის 6 ოქტომბრიდან. გთხოვთ, დაეთანხმოთ მათ თქვენს დაფაზე.

სექცია 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-ს, მაგრამ პასუხი გაიცემა მხოლოდ ?ppids=-ში მითითებულ პირველ 5 ID-ზე. დანარჩენი 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) — პრეფიქსის გარეშე. აღწერილია 42-დან 40 პროდუქტი: ორი ჯერ გაშვებული არ არის (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 დღით ადრე, ხოლო უფრო ძველი თარიღები უარყოფილია და არ გაიცემა — დაფარვა წინ ვრცელდება 2028 წლის 31 დეკემბრამდე 23 ქვეყანაში.

ყოველი პასუხი ახლა შეიცავს ობიექტს window, რომელიც ასახელებს ზუსტად დაფარულ დიაპაზონს. ეს დამატებითი ველია და იგზავნება v1-შიც, სადაც v1 უცვლელად ინარჩუნებს თავის ფიქსირებულ 7-დღიან ფანჯარას. გაითვალისწინეთ: include_ua_heat ყოველთვის მოიცავს მომდევნო 7 დღეს, რომელ ფანჯარასაც არ უნდა ითხოვდეთ — ის გამოითვლება ამინდის პროგნოზიდან და არა აკრძალვების კალენდრიდან. შეგახსენებთ, რომ ამ პროდუქტის v1 წყვეტს მუშაობას 2026 წლის 8 სექტემბერს.

ორი დაკავშირებული გაუმჯობესება მთელ 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-ს — დამატებითი ლოგიკური ველი, რომელიც გამცნობთ, აქვს თუ არა Best Time to Cross (day-stats) API-ს მონაცემები ამ სასაზღვრო გამშვები პუნქტისთვის. 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 გაუქმდება 2026 წლის 8 სექტემბერს. ის ნორმალურად მუშაობს 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-ის ბმულებით. თარგმანის შევსება: ბილინგის ისტორია, შესვლის შეცდომები, sandbox-ის ბმულები და გეგმის არჩევის ღილაკი ახლა ლოკალიზებულია ყველა 25 ენაზე.

Fleet beacon-ის პასუხი (POST /api/v1/fleet_position.php) ახლა შეიცავს messages მასივს, რომელიც აწვდის მფლობელი→მძღოლის მოლოდინში მყოფ შეტყობინებებს. ახალი, მხოლოდ მფლობელისთვის ხელმისაწვდომი live JSON ფიდი (?ajax=live) და „შეტყობინებები მძღოლებისთვის" ბარათი fleet-ის დაფაზე. ახალი მძღოლის მოწვევის გვერდი /{lang}/get-nakbus (25 ენაზე).

ლოკალიზებულია product_fleet_vehicles/live/history-ის title, desc და fleet-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-ს დოკუმენტაციის მიხედვით, ხოლო პროდუქტ fuel-ის რეჟიმი mode=nearest ასევე იღებს lon-ს. ყველა ცხრავე ხელმისაწვდომია sandbox-ში.

ყოველი აკრძალვა /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-შია — v1 URL აბრუნებს 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), არასავალდებულო ქვეყნების ფილტრით და «active now» ცოცხალი სტატუსით. API გასაღები საჭირო არ არის. მოირგეთ და დააკოპირეთ კოდი აქ: nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. გირჩევნიათ ნედლი მონაცემები? truck-bans API პროდუქტი და საჯარო JSON ფიდი კვლავ ხელმისაწვდომია.

სამი დამატება, ყველა უკუთავსებადი — v1 უცვლელია.

თითო endpoint-ის ვერსირება. ახლა არსებობს /api/v2/ საბაზისო URL. ის თითო 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)

თითოეული საკონტროლო პუნქტი ასევე იღებს direction {from,to} ობიექტს და stale ლოგიკურ მნიშვნელობას, ხოლო ?max_age_min=N აბრუნებს მხოლოდ ახლახან განახლებულ გადაკვეთებს. (v1 border კვლავ აბრუნებს საზღვრის ორივე მხარეს რიგითობის მიუხედავად — უცვლელი.)

ინტერაქტიული Sandbox. ავტორიზებულ დეველოპერებს ახლა შეუძლიათ სცადონ ნებისმიერი endpoint ბრაუზერიდან აქ: Developers → Sandbox — აირჩიეთ endpoint, ვერსია და ერთ-ერთი თქვენი გასაღები, შეასწორეთ პარამეტრები და იხილეთ ცოცხალი პასუხი. Sandbox-ის ტესტირებას აქვს საკუთარი ცალკე დღიური ბიუჯეტი (50 calls/day) და არასოდეს ეხება თქვენს ცოცხალ 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-ში ისტორიული შედარებებისთვის.

უსაფრთხოების/კონფიდენციალურობის მიმოხილვის ფარგლებში, შემდეგი ველები ამოღებულია — ისინი ავლენდნენ შიდა იმპლემენტაციის დეტალებს (ჩვენი წყაროს მონაცემთა ტაქსონომია, DB row ID-ები, შიდა pipeline-ის ანოტაციები, გამოუყენებელი/მკვდარი ველები) რეალური პროდუქტული ღირებულების გარეშე:

• id და corrected — ამოღებულია queue row ობიექტებიდან
• 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[] row-ებს ადრე ჰქონდათ wait_time: null წყაროების უმეტესობისთვის — მხოლოდ რამდენიმე წყარო აცხადებს მოცდის დროს პირდაპირ. row-ები მის გარეშე ახლა იღებენ სტანდარტულ შეფასებას, მონიშნულს ახალი wait_time_estimated ლოგიკური მნიშვნელობით, ასე რომ შეგიძლიათ განასხვავოთ რეალურად მოხსენებული მაჩვენებელი გამოთვლილისგან.

queue-advanced ახლა ღირს 1.5 ერთეული ზარზე 1-ის ნაცვლად (რაც ასახავს დამატებით traffic/weather/driver-report ძებნებს, რომლებსაც ის ასრულებს) — იხილეთ 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 სია და as_of UTC დროის აღნიშვნა.

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 საკონტროლო პუნქტისთვის ორივე sub-product-ით ახლა ღირს 10 ერთეული 20-ის ნაცვლად. X-Devapi-Units ჰედერი და meta.units_consumed პასუხში ასახავს ფასდაკლებულ ოდენობას.

მიიღეთ ცოცხალი რიგის სტატუსი და მონაცემთა სიახლე 20-მდე საკონტროლო პუნქტისთვის ერთ API ზარში — შექმნილია დაფის შემქმნელებისთვის, რომლებიც ამჟამად ბევრ PPID-ს ითხოვენ ციკლში.

კვოტა სამართლიანად ითვლება როგორც 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 PPID მოთხოვნაზე; დააკომბინირეთ ორივე sub-product ერთ ზარში დაფის სრული მონაცემებისთვის
• პასუხი შეიცავს meta.units_consumed-ს, რათა ზუსტად აკონტროლოთ კვოტის მოხმარება

queue პროდუქტის პასუხი ახლა შეიცავს ზედა დონის snapshot ობიექტს უახლესი რეალურ დროის მონაცემებით და გამოთვლილი პროგნოზირებული მოცდის დროით — იგივე ფორმულა, რომელიც გამოიყენება nakordoni.eu-ს hero სექციაზე:

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 თარგმანის ენაში — გადაეცით სახელი უკრაინულად, პოლონურად, გერმანულად ან ნებისმიერ მხარდაჭერილ ენაზე და ის დაემთხვევა.
• აბრუნებს ყველა PPID-ს ამ ლოკაციაზე ტრანსპორტის ტიპის მიხედვით დაჯგუფებულს (car / bus / pedestrian / truck).

alternatives პროდუქტი ახლა იღებს ?lang=-ს ყველა 22 მხარდაჭერილ ენაზე (იყო მხოლოდ 12).

ახალი crossing_type პარამეტრი გაძლევთ ტრანსპორტის ტიპის ფილტრის გადაფარვის შესაძლებლობას — მაგ. გადაეცით crossing_type=4, რომ მიიღოთ ავტომობილის ალტერნატივები მაშინაც კი, როცა ითხოვთ bus 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.