Jurnal modificări 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.

Asistentul AI de frontieră (/api/v1/data/assistant) răspundea cu 503 internal_error — „Asistent temporar indisponibil” — atunci când aceeași cheie punea aceeași întrebare de două ori în cinci minute. Nimic nu era indisponibil: în majoritatea acestor cazuri răspunsul era deja calculat și gata de livrat. Acum este returnat normal, cu ok: true și HTTP 200.

Dacă repetarea sosește în timp ce primul răspuns încă se scrie, apelul returnează acum 429 cu error.code egal cu duplicate_request în loc de 503, astfel încât o politică de reîncercare să poată distinge „mai încearcă peste o clipă” de o defecțiune reală. Ambele cazuri erau contorizate și în rata de erori a contului dumneavoastră ca erori de server; nu mai sunt. În cerere nu se schimbă nimic — niciun parametru, nicio versiune. duplicate_request este listat împreună cu celelalte coduri de eroare în referință.

Parcările pentru camioane (/api/v2/data/truck-parkings) returnau intrări cu name egal cu null și address gol — lângă Bensheim, 20 din 50. Sunt locuri pe care le avem doar ca o coordonată: nimic de afișat și nimic de potrivit cu propriul set de POI. Ele nu mai fac parte din acest produs: acesta livrează acum numai locații cu nume, în prezent peste 22.000 în toată Europa. Dacă filtrați singuri intrările fără nume, acel cod este acum redundant, dar inofensiv. Răspunsurile devin mai scurte pentru aceleași radius și limit, iar fiecare intrare returnată este utilizabilă.

Separat, aproximativ 10.000 de parcări aveau ca name o pereche brută de coordonate, de exemplu 51.927301,10.14112, în timp ce denumirea reală se afla în address. Acum poartă acea denumire — Ionity, Seesen, Rest Area A5 E35 Kaelberpfad, Bensheim — peste tot unde apar, inclusiv în /api/v1/data/pois. Câmpul id al fiecărui loc rămâne neschimbat, deci o corespondență salvată în cache rămâne valabilă; se schimbă doar name.

snapshot.updated_at din /api/v1/data/queue și /api/v1/data/multi este ora locală în fusul propriu al punctului de trecere (de exemplu Europe/Istanbul, Europe/Sofia, Europe/Budapest, Europe/Warsaw, Europe/Kyiv), iar până acum nimic din răspuns nu indica despre ce fus este vorba, așa că apelantul nu îl putea raporta la un moment precis. snapshot primește suplimentar câmpul timezone (nume IANA), alături de updated_at. Fără parametru nou, fără versiune nouă, fără modificări la celelalte câmpuri.

Până acum fiecare endpoint de combustibil își descria propria acoperire printr-o listă scrisă de mână: AT, DE, DK, ES, FR, HR, IT, LU, PL, PT, SI, iar Polonia era redusă în ea la zona Trójmiasto. Ambele afirmații se învechiseră demult. Acoperirea este acum măsurată din indexul viu al stațiilor și recalculată la fiecare șase ore: 39 de țări au astăzi stații cu prețuri, iar Polonia printre ele în toată țara, nu în trei orașe. În cerere nu se schimbă nimic: niciun parametru, nicio versiune.

Stații de combustibil în apropiere și Cel mai ieftin combustibil: când o căutare nu întoarce nimic, blocul coverage conține acum valorile măsurate station_countries, station_counts, sparse_coverage și measured_at, raportate la sortimentul cerut, nu la combustibil în general. O țară ajunge în sparse_coverage când avem acolo 25 de stații cu prețuri sau mai puține — este o numărătoare, nu o apreciere.

Apare o notă nouă pentru un sortiment pe care îl recunoaștem, dar pe care nimeni nu îl cotează acolo unde ați întrebat. Până acum coverage.fuel_type_note apărea doar când numele de la pompă ne era necunoscut. Acum apare și când numele este recunoscut corect, dar în acea țară pur și simplu nu există niciun preț pentru el; nota indică țările în care sortimentul este cotat și sortimentele pe care le cotăm în jurul dumneavoastră. Numele ceh Natural 100 este exemplul curat: se recunoaște, dar nicio sursă nu îi dă un preț în Cehia. Un răspuns gol nu mai arată ca o cerere stricată.

Sortimente de combustibil (/api/v2/data/fuel-grades) primește priced_countries și priced_station_counts pentru fiecare sortiment, plus priced_here când transmiteți ?country=. Cele două liste înseamnă lucruri diferite: o țară din countries este una în care acceptăm acel nume de la pompă, în timp ce priced_countries arată unde o sursă îl cotează efectiv, așa că priced_here egal cu 0 este un răspuns real, nu o lipsă din răspuns. Sunt livrate și coverage_measured_at, și coverage_note, iar Cache-Control scade de la 24 de ore la 6, potrivit frecvenței de recalculare.

Se recunosc și mai multe nume locale de la pompă, printre ele Klimadiesel 90 (HVO100) și HVO Diesel, Erdgas și Metano, Autogas și Autogaz, DEF pentru AdBlue, precum și o serie de nume comerciale de motorine și benzine premium. Ordinea de recunoaștere este neschimbată, iar potrivirea rămâne exactă, deci niciun nume care funcționa înainte nu înseamnă altceva astăzi, iar un nume nou poate cel mult transforma un răspuns gol într-unul cu prețuri. În același timp, documentația de referință și descrierile endpointurilor au fost corectate în toate cele 25 de limbi ale site-ului.

„Cel mai ieftin combustibil” (/api/v2/data/fuel-cheapest) returna cele mai apropiate stații în ordinea distanței, nu pe cele mai ieftine. Deoarece sortarea era aplicată înainte ca rezultatul să fie limitat la limit, cele mai ieftine stații din raza dvs. puteau lipsi complet din răspuns. Sortarea funcționează din nou corect: mai întâi cel mai mic preț pentru tipul de combustibil solicitat, la egalitate câștigă stația mai apropiată, iar o stație fără preț pentru acel tip apare ultima. Nimic din cerere nu se schimbă — niciun parametru nou, nicio versiune nouă.

Răspunsurile v2 pentru combustibil sunt de asemenea documentate așa cum sunt livrate efectiv: stațiile sosesc sub data.stations[], câte o intrare pentru fiecare stație fizică, iar fiecare tip de combustibil este imbricat în obiectul prices (price, currency, local_name, updated_at, age_hours, stale), plus station_ref, grades, total_found și notices. Referința pentru „Stații de combustibil din apropiere” și „Cel mai ieftin combustibil” încă descria vechea listă plată de rânduri data.data[].

Pe pagina de facturare (fila lunară) sunt disponibile două suplimente peste orice plan, fără a-l schimba: Apeluri suplimentare de prognoză — +100 de apeluri de prognoză și statistici pe zi pentru fiecare bloc, €2 pe lună pentru fiecare bloc, până la 10 blocuri; și Țări suplimentare — +1 țară declarabilă pentru fiecare unitate, €2 pe lună fiecare. Modificarea cantității afișează o ofertă proporțională exactă înainte de orice debitare.

De la 10 noiembrie 2026 fiecare plan include un număr stabilit de țări declarate: Explorer și Student 4, Starter 10, Pro și superioare nelimitat. De la acea dată, o declarație mai lungă decât planul plus țările suplimentare achiziționate nu va mai putea fi salvată; fila Cont îți arată deja limita, iar conturile care o depășesc văd o sugestie în panou. Până pe 10 noiembrie nu se schimbă nimic.

Sandbox-ul API etichetează acum fiecare endpoint din listă cu clasa sa de cotă (Greu / Standard), arată costul de cotă pentru versiunea selectată înainte de a rula ceva, iar după un apel arată cât ar fi costat același apel din cota ta reală — inclusiv formula ceil(N ppids × M sub-products / 2) folosită pentru apelurile de tip /multi.

Este o previzualizare doar pentru citire: apelurile din sandbox se scad din bugetul separat de test al sandbox-ului, niciodată din cota ta reală.

Începând de astăzi, tot ce am anunțat public că urmează să fie retras este închis pentru conturile de dezvoltator create la data anunțului sau ulterior. Dacă ai avut contul înainte de anunț, nu se schimbă nimic — păstrezi perioada de grație completă, până la data retragerii indicată în intrarea care a anunțat-o.

De ce există această regulă. Pe 24 august 2026 am anunțat că truck-bans v1 se retrage pe 8 septembrie 2026. Două conturi s-au înregistrat la câteva zile după acel anunț, și-au construit integrarea pe v1 și au ajuns la câteva ore de un 410 fără ca vreun e-mail al nostru să fi ajuns la ele: și anunțul, și seria de notificări erau anterioare înscrierii lor. Nimic din API nu le-a împiedicat să adopte o versiune despre care spusesem deja că dispare. A fost greșeala noastră, iar aceasta este remedierea — nu poți adopta din nou ceva deja programat pentru eliminare.

Cum arată. Un astfel de apel este refuzat cu 410 Gone și codul de eroare version_closed_to_new_accounts. Mesajul indică data retragerii, data anunțului și versiunea care trebuie folosită în schimb. Este intenționat un cod diferit de version_sunset, pe care îl primește orice cont după ce a trecut data retragerii — suportul poate distinge „ai venit prea târziu ca să începi” de „a dispărut pentru toată lumea” fără să citească vreun log.

Drepturile păstrate se stabilesc după data creării contului, nu după primul apel. Dacă te-ai înregistrat înainte de anunț, dar începi integrarea abia acum, primești totuși perioada de grație completă: e posibil să fi lucrat pe ea tot timpul.

În vigoare de acum pentru truck-bans v1 (anunțat pe 24 august 2026, retras pe 8 septembrie 2026) și automat pentru fiecare retragere pe care o anunțăm de aici înainte. Nu ți se cere nimic nou: fiecare răspuns pe o versiune în curs de retragere poartă deja anteturile Deprecation, Sunset și Link: rel="successor-version", astfel încât o integrare nouă poate vedea retragerea venind fără să citească această pagină.

Continuare a modificării v4 de ieri (tichet pentru dezvoltatori #105). Listele destination separate prin virgulă din v1 și v2 continuă să funcționeze, dar respectă acum același termen ca destination=all: ambele se opresc pe 2026-10-06 (anteturi Deprecation/Sunset până atunci, apoi 400 destination_list_removed, care indică /api/v4/ ca înlocuitor). Verificarea existentă a plafonului de 10 elemente pentru listele cu virgulă rămâne neschimbată până la acea dată.

v4 rămâne cu o singură destinație pe apel — asta nu s-a schimbat azi. S-a schimbat doar modul în care sunt comunicate v1/v2: eroarea 400 pentru destination=all nu mai sugerează o listă cu virgulă drept cale de migrare (ar dispărea la aceeași dată), ci trimite direct la v4.

Corectură în documentație: exemplul v4 de pe acest site suna anterior /api/v4/data/border/1/2,3,4/9 — o listă cu virgulă, pe care v4 o respinge. Acum este /api/v4/data/border/1/2/9. Cine a copiat exemplul vechi ar fi primit un 400 la primul apel; ne cerem scuze.

Cheie nouă tradusă product_border_v4_p_destination apare în toate cele 25 de limbi ale site-ului și enunță explicit regula unei singure destinații în v4, în loc să reia formularea din v1/v2.

/api/v4/data/border/{origin}/{destination}/{crossing_type} este disponibil de astăzi. Față de v2 se schimbă trei lucruri, iar împreună acestea sunt motivul pentru care este o versiune nouă, nu o simplă modificare.

1. Gata cu destination=all. Datele noastre sunt licențiate pe țară (Developer API Terms, secțiunea 7), iar un wildcard care se extinde la "fiecare vecin pentru care deținem date" returnează țări pentru care contul dumneavoastră poate să nu fie aprobat — fără ca nimic din cerere să arate asta. În v4 numiți țara.

2. O singură țară de destinație per apel. /api/v4/data/border/1/2/9 cere o singură frontieră. Listele separate prin virgulă nu sunt acceptate: trimiteți 1/2/9, 1/3/9 și 1/4/9 ca apeluri separate. O listă cu virgule sau all răspunde cu 400 și indică exact apelurile care trebuie trimise, astfel încât nimic nu eșuează în tăcere.

3. Un singur cod pentru camioane. v1 și v2 împărțeau transportul de marfă în 8 (Freight Transport) și 9 (Freight Transport up to 7.5 t). Împărțirea este reală la punctul de trecere, dar niciun integrator nu poate acționa pe baza ei: o cerere v2 pentru 9 la frontiera UA-PL returna 21 din cele 70 de puncte de trecere pentru camioane, fără ca nimic să semnaleze asta. v4 răspunde la 9 cu toate benzile pentru camioane și acceptă 8 ca alias pentru 9. Fiecare rând poartă propriul crossing_type, așa că un răspuns combinat rămâne verificabil.

În v1 și v2, destination=all continuă să funcționeze până la 06.10.2026 și poartă până atunci anteturile Deprecation / Sunset. De la acea dată, și aceste versiuni răspund cu 400 pentru all — restul din v1 și v2 rămâne neatins și disponibil. Aceeași dată se aplică și celorlalte scurtături pentru toate țările: travel-matrix fără ?dest=, bus-carriers cu ?ppid=all și fuel-grades fără ?country=.

v3, anunțat mai devreme astăzi, este înlocuit de v4. v3 se deosebea de v4 doar prin faptul că accepta în continuare o listă cu virgule, iar nicio integrare nu folosește această formă. URL-urile v3 răspund în continuare, așa că nu se strică nimic din ce a fost scris pentru ele, dar v3 nu este documentat și nu va mai fi dezvoltat — migrați la v4.

Restul din v4 este identic cu v2: ordinea direcțională din cale, direction{from,to}, stale și ?max_age_min=.

ID-urile numerice din /border/{origin}/{destination}/{crossing_type} nu au fost niciodată publicate sub formă de tabel, așa că integratorii le-au reconstruit din fusuri orare și din URL-uri de exemplu. Acum se află în documentație, la Coduri de țară și de tip de vehicul, generate din aceleași tabele față de care validează API-ul — ID-urile de țară cu frontierele în care se extinde fiecare și fiecare crossing_type cu eticheta pe care o returnează API-ul.

În timp ce le publicam am descoperit că sandbox-ul și metadatele endpointului descriau 8 drept "truck<7.5t" și 9 drept "truck". Este invers: API-ul etichetează 8 ca Freight Transport și 9 ca Freight Transport up to 7.5 tons, și așa a fost dintotdeauna. Dacă ați ales codul pentru camioane din indiciul parametrului, ați filtrat banda opusă celei dorite. Corectat peste tot, iar v3 elimină complet această alegere.

API Terms v1.1 înlocuiesc v1.0 înainte ca aceștia să intre în vigoare și se aplică de la 06.10.2026. Vă rugăm să îi acceptați în dashboard.

Secțiunea 7 spune acum ce este o Piață: țara ale cărei date le folosiți — acolo unde se află punctul de trecere sau frontiera pe care o solicitați — nu țara în care locuiesc utilizatorii dumneavoastră. Dashboardul nostru afirmase ambele lucruri în locuri diferite; aplicarea a însemnat întotdeauna prima variantă.

Două schimbări în favoarea dumneavoastră. Țările deja aprobate pentru contul dumneavoastră rămân utilizabile în timp ce o modificare ulterioară este în analiză (adăugarea unei țări nu mai suspendă țările pe care le aveți deja). Iar dacă nu am răspuns la o declarație de piață în 5 zile lucrătoare, se aplică limitele complete ale planului dumneavoastră până când o facem.

Secțiunea 10.3 corespunde acum cu ceea ce cere efectiv dashboardul, iar secțiunea 13.2 stabilește o bază de disponibilitate pe care o măsurăm și v-o putem arăta.

Trei produse includ acum un câmp suplimentar data_quality (high sau low) care arată dacă o citire este o observație reală sau o estimare de model, fără sursă de numărare live la acel punct de trecere: queue (la nivelul superior, în snapshot, și pe fiecare rând istoric din data[] — absent pe rândurile de prognoză), update-info (pe plic) și multi (în ambele subobiecte, queue și update_info, pentru fiecare punct de trecere). Nu este un semnal nou — indicatorul de bază exista deja intern —, dar nu a fost niciodată expus, așa că un punct de trecere complet modelat arăta identic cu unul măsurat direct. is_realtime rămâne intenționat neschimbat: continuă să returneze true pentru rândurile modelate, iar schimbarea acestui înțeles ar fi o modificare incompatibilă de nivel v2, pe care nu o facem aici.

Tot din această versiune: produsul queue-advanced nu mai redistribuie date meteo brute de la sursă. weather_main, temperature și wind_speed sunt înlocuite cu un condition_code derivat (scară de risc 0–5, null când nu sunt disponibile date meteo), plus condition și severity.

De la 2026-08-30, o cerere /api/v1/data/multi primește răspuns pentru cel mult 5 puncte de trecere. Un apel care listează mai multe PPID-uri nu este respins: returnează în continuare 200, dar primesc răspuns doar primele 5 ID-uri din ?ppids=. Restul ID-urilor sunt ignorate, returnate în meta.ppid_cap.ignored și nu se scad din cota ta — apelul se taxează după ceea ce returnează efectiv.

Cât timp un apel depășește limita, răspunsul conține antetul X-Devapi-Warning: multi_ppid_cap și un bloc meta.ppid_cap cu cap, enforced_from, enforced, ppids_asked, ppids_answered și ignored[]. Până la 2026-08-30 aceste câmpuri apar cu enforced: false și cu setul complet de rezultate, astfel încât poți vedea schimbarea care urmează în propriile jurnale.

Reducerea de jumătate din cotă rămâne neschimbată. Împarte punctele de trecere în grupuri de câte 5 și trimite câte un apel pe grup în ciclul tău obișnuit de actualizare; pentru interogarea frecventă doar a lungimii cozii și a prospețimii datelor, update-info rămâne produsul mai ieftin din clasa standard.

Interdicția calculată de caniculă din Ucraina — returnată cu include_ua_heat și automat pentru country=UA — răspunde acum pentru intervalul de date pe care îl ceri. Anterior returna următoarele șapte zile indiferent de date_from și date_to, așa că un interval din decembrie aducea în tăcere rândurile din săptămâna curentă. Interdicția este calculată din prognoza meteo, nu citită din calendarul interdicțiilor, deci are două limite pe care calendarul nu le are: nu privește în urmă și se oprește acolo unde se oprește prognoza. Intervalul tău este acum intersectat cu ceea ce acoperă efectiv prognoza, iar noul câmp ua_heat_ban.forecast_horizon indică ultima dată disponibilă. Un interval dincolo de acest orizont nu returnează niciun rând și explică de ce în summary — ceea ce nu înseamnă „fără interdicție”. Răspunsurile v1 rămân neschimbate.

Forma răspunsului nu era documentată nicăieri — singura cale de a afla ce returnează un produs era să îl apelezi. Acum pagina fiecărui produs are, sub tabelul de parametri, un tabel Câmpurile răspunsului cu o scurtă descriere a fiecărui câmp; câmpurile elementelor din liste apar ca items[].name, iar câmpurile de la nivelul plicului (usage, meta, snapshot, resolved_location) apar fără prefix. Sunt documentate 40 din 42 de produse: cele două încă nelansate (weather, road-quality) rămân intenționat fără descriere. Același tabel este publicat în oglinda noastră publică de documentație de pe GitHub.

Fiecare produs de carburant acceptă acum denumirea locală a tipului de carburant, nu doar scrierea noastră internă: ON în Polonia, Nafta în Cehia, Gázolaj în Ungaria, Motorină în România, ДП în Ucraina, Motorin în Turcia, Gasóleo în Portugalia și Spania. Denumirea este interpretată mai întâi în funcție de țară — „95” înseamnă E10 la o pompă daneză și E5 la una poloneză — așa că trimiteți country împreună cu denumirea locală sau coordonate după care putem plasa punctul. Răspunsul conține fuel_type (canonic), fuel_type_requested (exact cum l-ați scris) și fuel_type_local. O denumire pe care nu o putem plasa nu este niciodată înlocuită cu un tip implicit: răspunsul vine gol și spune asta explicit.

Tabelul complet este acum un produs de sine stătător — GET /api/v2/data/fuel-grades[?country=PL][&fuel_type=ON] — tipurile noastre canonice și denumirile lor locale în 41 de țări europene, inclusiv piețe pentru care nu publicăm prețuri. Nivelurile de țară și de regiune ale produselor fuel și fuel-local au primit în plus un obiect grades care leagă fiecare cheie de preț de tipul de carburant și de denumirea lui la pompă.

Produsul truck-bans răspunde acum pentru o dată sau un interval de date la /api/v2/data/truck-bans. Până acum returna întotdeauna următoarele 7 zile și ignora orice dată trimisă, așa că pentru un calendar era nevoie de o cerere pe zi — iar pe un plan cu două cereri pe secundă majoritatea sunt respinse cu 429 qps_exceeded.

Folosiți ?date=YYYY-MM-DD pentru o singură zi sau ?date_from= și ?date_to= pentru un interval. Ambele capete sunt incluse și oricare poate lipsi: începutul este implicit ziua de azi, sfârșitul este începutul plus 7 zile. O fereastră poate acoperi cel mult 92 de zile — una mai lungă este respinsă cu 400 date_range_too_long, în loc să fie tăiată în tăcere. Acesta este un calendar orientat spre viitor: o fereastră poate începe cu cel mult 7 zile în urmă, iar datele mai vechi sunt respinse, nu servite — acoperirea se întinde înainte până la 31 decembrie 2028, în 23 de țări.

Fiecare răspuns conține acum un obiect window care numește exact intervalul acoperit. Este un câmp adăugat și este trimis și în v1, unde v1 își păstrează neschimbată fereastra fixă de 7 zile. De reținut: include_ua_heat acoperă întotdeauna următoarele 7 zile, indiferent de fereastra cerută — este calculat dintr-o prognoză meteo, nu din calendarul de restricții. Amintim că v1 a acestui produs se retrage la 8 septembrie 2026.

Două îmbunătățiri conexe în tot API-ul: orice parametru pe care un produs nu îl acceptă este acum listat în ignored_params în răspuns, în loc să fie ignorat în tăcere, iar erorile de validare de la serviciul de date ajung la dumneavoastră așa cum au fost scrise, cu codul citibil automat în error.reason.

Trei corecții de calitate a răspunsurilor rezultate dintr-un audit al gateway-ului (tichetul #43).

Antetul X-API-Key este acum acceptat, alături de Authorization: Bearer și ?key=. Dacă clientul dumneavoastră HTTP trimite cheile printr-un antet numit X-API-Key, acum funcționează — anterior era ignorat în tăcere, iar apelul era respins cu missing_api_key. Authorization: Bearer rămâne forma documentată și recomandată.

Mesajul de eroare pentru cheia lipsă enumeră acum toate cele trei moduri de autentificare (antetul Bearer, antetul X-API-Key sau ?key=), în loc să trimită doar către pagina de înregistrare.

Directorul checkpoints include acum has_day_stats pe fiecare rând — o valoare booleană suplimentară care arată dacă API-ul „Cel mai bun moment pentru traversare” (day-stats) are date pentru acel punct de trecere. Day-stats există doar pentru o parte dintre punctele de trecere monitorizate; verificați acest indicator înainte de interogare, ca să evitați erori 404 previzibile. Câmpurile existente rămân neschimbate.

De asemenea, corectat în documentație: produsul road-conditions a respectat dintotdeauna un parametru lang pentru localizarea etichetelor — doar că nu era listat.

Două corecții și o versiune nouă pentru produsul truck-bans.

Țările separate prin virgulă funcționează acum. ?country= acceptă o listă de până la 3 coduri ISO-2, de exemplu ?country=DE,RO. O listă mai lungă este respinsă cu 400 too_many_countries, nu tăiată în tăcere — acesta este un calendar de restricții per țară, nu un flux în masă. Anterior acest lucru nu funcționa: separatorul era eliminat, astfel că DE,RO era citit ca un singur token DERO, nu se potrivea cu nimic și returna success: true cu total_bans: 0 — un „nicio restricție” foarte sigur pentru două țări care aveau împreună 22. Dacă ați ocolit problema trimițând câte o cerere pentru fiecare țară, acum o singură cerere le acoperă pe toate și costă un apel în loc de mai multe.

Răspunsurile își raportează acum propria completitudine. Trei câmpuri suplimentare — returned, total_available și truncated — vă spun dacă un răspuns a fost plafonat. În special o cerere fără domeniu returnează o felie plafonată, iar până acum nimic din conținutul răspunsului nu semnala asta. total_bans își păstrează înțelesul actual (rândurile din acest răspuns), deci nu se schimbă nimic din ceea ce parsați deja.

v2 are domeniu obligatoriu per țară. La /api/v2/data/truck-bans, ?country= este obligatoriu, iar o cerere fără domeniu este respinsă cu 400 scope_required — acest produs este un calendar de restricții per țară, nu un flux în masă. v1 rămâne neschimbată astăzi — încă acceptă o cerere fără domeniu și returnează în continuare aceleași 50 de rânduri plafonate ca întotdeauna, deci nimic din ce aveți în funcțiune nu se strică acum. v1 a acestui produs se retrage pe 8 septembrie 2026. Funcționează normal până pe 7 septembrie inclusiv; de pe 8 septembrie o cerere v1 este respinsă cu 410 Gone și un mesaj care indică v2. Până atunci, fiecare răspuns v1 include Deprecation: true, un antet Sunset cu acea dată și un antet Link care numește versiunea succesoare, astfel încât o bibliotecă client poate afișa termenul fără ca cineva să citească această pagină. Pentru migrare: schimbați segmentul de versiune în /api/v2/data/truck-bans și transmiteți ?country=.

O corecție de documentație: parametrul date a fost eliminat. A fost listat mult timp, dar nu a fost niciodată citit de serviciu, așa că orice cerere care îl trimitea primea în tăcere fereastra implicită de 7 zile, nu ziua cerută. Pentru a selecta o zi, filtrați tabloul upcoming_bans după câmpul său date. Un cod ISO-3 precum DEU nu mai este rezolvat nici el la un nume de țară în sumar, unde producea înșelătorul „No truck ban data for: Germany.”

Produsul truck-bans returnează acum restricții de circulație la nivel național pentru încă cinci țări: Belgia (BE), Belarus (BY), Muntenegru (ME), Macedonia de Nord (MK) și Suedia (SE). Acoperirea existentă pentru Bulgaria, Grecia și Portugalia a fost extinsă și actualizată — restricțiile grecești ajung acum până în septembrie 2027, iar Portugalia este din nou populată.

Structura răspunsului rămâne neschimbată. Rândurile noi au aceleași chei ca orice altă restricție: date, time_from, time_until, restriction_type, restriction_details, min_weight_tons și details_url. Când o restricție se aplică doar în anumite condiții — de exemplu, interdicțiile de vară din Belarus se aplică peste 25 °C — condiția este menționată în restriction_details, așa că citiți acest câmp înainte de a avertiza un șofer. min_weight_tons este null atunci când regula vizează o categorie de transport (mărfuri periculoase), nu un tonaj.

Produsele fuel-stations și fuel-cheapest returnează acum prețuri pe stație în Polonia. Acoperirea este parțială — zona Tricity (Gdańsk, Gdynia, Sopot) — de aceea Polonia este semnalată într-un nou tablou aditiv coverage.sparse_coverage, alături de lista existentă coverage.station_countries. O țară listată în sparse_coverage are date pe stații doar pentru o parte din teritoriu; o interogare în altă zonă a acelei țări returnează o listă goală împreună cu nota de acoperire, exact ca înainte. Prețurile poloneze sunt exprimate în PLN.

Și eroarea pentru interogările în masă este mai clară: când lipsește lat, mesajul scope_required indică acum produsul fuel (?country=XX) pentru prețuri medii la nivel de țară.

GET /api/v2/data/fuel-local?lat=&lon= determină acum prețul pe trei niveluri în loc de două: station, apoi region, apoi country. Noul nivel intermediar există pentru Ucraina, unde prețurile pe stații nu există nicăieri: un punct din Ucraina primește acum media regiunii sale în loc de media națională și revine la media națională doar când pentru regiune nu există cotații.

Un răspuns de la nivelul region conține codul regiunii (o valoare ISO 3166-2, precum UA-46), region_name și region_center_dist_km, plus aceleași chei de preț ca nivelul de țară. Ramificați în continuare codul după resolution, niciodată după forma răspunsului; răspunsurile station și country rămân neschimbate.

Noul endpoint GET /api/v2/data/fuel-local?lat=&lon= returnează cel mai bun preț disponibil la carburant pentru orice punct din Europa. Acolo unde există date pe stații, răspunde cu prețurile celor mai apropiate stații, altfel cu media națională a țării în care se află punctul – inclusiv Ucraina, unde prețurile pe stații nu există nicăieri.

Fiecare răspuns conține câmpul resolution, care indică nivelul ce a răspuns: station (o listă de stații cu distance_km, fiecare în moneda proprie) sau country (un obiect cu mediile naționale). Ramificați codul după resolution, niciodată după forma răspunsului. Disponibil începând cu /api/v2/; fuel, fuel-stations și fuel-cheapest rămân neschimbate.

Produsele fuel-stations și fuel-cheapest acoperă acum mult mai multe stații din Germania, iar prețurile sunt actualizate pe tot parcursul zilei — inclusiv în zonele rurale. Parametrul fuel_type acceptă 13 tipuri de carburant: diesel, e5, e10, superplus, super100, premdiesel, truckdiesel, hvo, lpg, cng, adblue, e85 și lng. Când nicio stație nu corespunde interogării, răspunsul include un obiect coverage cu lista țărilor pentru care există date despre stații.

Parametrul radius= este acum acceptat ca alias compatibil pentru radius_km în toate produsele care îl documentează. Produsele fuel-stations și fuel-cheapest returnează un obiect aditiv coverage (lista țărilor cu stații plus o notă) în loc de un rezultat gol fără explicații atunci când nicio stație nu corespunde. Obiectele punctelor de frontieră din route-plan includ acum cheia aditivă wait_basis (car_lane față de vehicle_lane), astfel încât clienții să știe când datele de așteptare pentru camioane provin de fapt de pe banda pentru autoturisme. Potrivirea punctelor de trecere pentru camioane de-a lungul unei rute este semnificativ mai precisă: revenirea la banda pentru autoturisme în cazul perechilor de puncte fără date pentru camioane, o protecție împotriva direcției greșite, o limită de distanță mai strictă și eliminarea duplicatelor de treceri aflate în aceeași poziție. Toate modificările sunt aditive, fără modificări incompatibile.

Pagina de start pentru dezvoltatori are acum secțiuni cu ancore (#products, #plans, #quickstart, #integrations, #datasets, #apps, #companies, #showcase) și navigare rapidă, iar fiecare card de produs face trimitere la propria pagină de documentație. Noua secțiune Mobile apps prezintă Kordon Online și Truck Bans cu linkuri către Google Play. Completare traduceri: istoricul plăților, erorile de autentificare, linkurile sandbox și butonul de selectare a planului sunt acum localizate în toate cele 25 de limbi.

Răspunsul beacon-ului flotei (POST /api/v1/fleet_position.php) include acum un array messages care livrează mesajele în așteptare de la proprietar către șofer. Nou flux JSON live doar pentru proprietar (?ajax=live) și un card „Mesaje către șoferi” pe tabloul de bord al flotei. Nouă pagină de invitație pentru șofer /{lang}/get-nakbus (25 de limbi).

Au fost localizate titlul, descrierea și parametrii product_fleet_vehicles/live/history, precum și parametrii istoricului flotei în toate cele 25 de limbi ale portalului pentru dezvoltatori.

/api/v1/data/truck-bans returnează acum același set de câmpuri de nivel superior, indiferent de interogarea care a declanșat răspunsul. Anterior, o interogare pentru o țară fără interdicții de calendar, un ppid nerecunoscut sau o potrivire normală în baza de date puteau omite fiecare câmpuri diferite (de ex. country, covered_countries, ppid). Acum fiecare răspuns include în mod constant 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 și upcoming_bans (null sau gol acolo unde nu se aplică), simplificând analizarea datelor pe partea de client.

Nouă produse noi per serviciu. Cele bazate pe locație acceptă lat/lon sau city + country (geocodăm orașul pentru dvs.): /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 (stații clasate după preț pentru un tip de combustibil) și /api/v2/data/internet-points; rezultatele conțin distance_km și sunt limitate de radius. /api/v2/data/vignettes răspunde dacă o țară necesită vinietă, cu prețuri actuale. Produsul existent pois acceptă acum lon și radius conform documentației, iar modul mode=nearest al produsului fuel acceptă și el lon. Toate nouă sunt disponibile în sandbox.

Fiecare interdicție din /api/v1/data/truck-bans include acum restriction_type (General / Local / Sunday / Holiday / Seasonal), restriction_details (zona exactă sau drumurile afectate) și min_weight_tons. details_url indică acum paginile pe țară de pe nakordoni.eu. Un nou parametru opțional lang selectează limba numelor țărilor și a rezumatului; implicit este acum engleza.

Un ?ppid= incorect returnează acum motivul real în loc de un simplu "Request failed": eroarea numește parametrul, formatul așteptat id_<number> și trimite la /api/v1/data/checkpoints. Tabelele de parametri pentru stats, forecast, update-info, weather și bus-carriers afișează acum exemplul id_13 în toate cele 25 de limbi.

Noua interfață a portalului (bară superioară, meniu lateral cu pictograme, panou KPI, aranjamente pe carduri) este acum experiența implicită pentru toate conturile de dezvoltator autentificate — mai devreme decât lansarea planificată pe 10 august. Folosiți ?v=1 pentru a reveni oricând la aranjamentul clasic.

Toate paginile portalului pentru dezvoltatori — pagina principală, documentația, panoul de control, AI Studio, sandbox, tichetele, cererile, exportul, flota, știrile, jurnalul de modificări și paginile de cont — nu mai încarcă niciun script și niciun spațiu publicitar. Acest lucru se aplică în tot portalul, nu doar la autentificare și înregistrare ca înainte.

Planifică toată călătoria transfrontalieră dintr-un singur apel: /api/v2/data/route-plan întoarce ruta, punctele de trecere aflate efectiv pe ea, cu coada în timp real sau o prognoză pentru ora sosirii tale, și opririle pe care șoferul le face cu adevărat — pauze de odihnă, masă, alimentare — pe o singură axă a timpului.

Frontiera face parte din această axă. O coadă lungă contează drept pauza deja scadentă și resetează contorul de condus, așa că trei ore de așteptare nu apar niciodată ca trei ore plus un set complet de pauze pe care nu le-a făcut nimeni. Autoturismele urmează un model de conducere sănătoasă; autobuzele și camioanele primesc odihna obligatorie conform UE 561/2006, iar timpul de serviciu al autobuzelor este calibrat pe peste 1000 de orare internaționale licențiate. Adaugă stop_places=1 pentru a numi o zonă de odihnă sau o benzinărie reală la fiecare oprire și via=lat,lon pentru a trece prin alt punct de frontieră.

Nou în meniul portalului: Prezentare — o prezentare vie, mereu actuală, a platformei de date nakordoni, personalizată pentru piața dumneavoastră (asigurări, turism, logistică, transportatori, media, navigație, carburanți, fintech, sector public sau proiecte personale). Arată volume reale ale platformei pe 30 de zile, propriul dumneavoastră consum de API, statistici privind timpul de răspuns și limitele, precum și o recomandare de plan atunci când apelurile ating limitele nivelului gratuit. Alegeți sau confirmați piața (sau piețele) pe pagină, în profil — ori la înregistrare. Se deschide automat la prima vizită; deschiderea automată poate fi dezactivată chiar din pagină.

Dacă un asistent are un flux activat, dar apelul nu poartă contextul de care are nevoie acel flux — de exemplu queue fără ppid— fluxul este acum omis înainte de orice cerere și nu este taxat. Anterior era apelat oricum, eșua și tot costa o unitate. Studioul arată de ce are nevoie fiecare flux, recalculează prețul pe măsură ce completați contextul și marchează rezultatele ✓ executat / ⊘ omis, netaxat / ✕ eșuat; API-ul returnează data.feeds_skipped , care vă spune exact ce parametru să transmiteți.

Răspunsurile nu mai menționează fluxuri, surse de date sau orice altceva tehnic: un flux lipsă înseamnă cel mult o propoziție simplă către utilizatorul final, niciodată o denumire internă. Fluxurile cu filtre doar opționale (precum fuel restrâns la o țară pentru care nu avem date) revin acum la setul larg de date în loc să nu returneze nimic.

Nou: /{lang}/developers/studio. Construiți un asistent AI care răspunde pe baza conținutului dumneavoastră și a datelor noastre live de la frontieră. Dați-ne fișierele markdown sau doar indicați paginile, iar noi le preluăm și le indexăm — dumneavoastră întrețineți doar propriile fișiere. Alegeți ce fluxuri ale noastre poate folosi (coadă, prognoză, alternative, statistici zilnice, carburanți, interdicții pentru camioane, duminici comerciale, sărbători, starea drumurilor, transportatori de autobuze, POI, valută), alegeți un nivel de model (rapid / echilibrat / pro — acesta stabilește prețul), scrieți-vă propriile instrucțiuni cu substituenți {{feed.slug}} care indică exact unde ajung datele noastre în răspuns și adăugați o frază de încheiere proprie, atașată fiecărui răspuns. Șabloane gata făcute: asistent personal de călătorie, asistent de lucru/transport marfă, asistent de vânzări pentru asigurări și Cartea Verde.

Testați-l în studio (30 de răspunsuri pe zi, separat de cota dumneavoastră API), apoi apelați-l în producție la GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Prețul per răspuns = unitățile nivelului de model + 1 unitate pentru fiecare flux activat, returnat în X-Devapi-Units. Produsul există doar în v2 — o adresă v1 returnează unsupported_version. Produsul existent assistant rămâne neschimbat.

Fiecare asistent funcționează sub o politică de conținut a platformei care are întâietate față de instrucțiunile dumneavoastră: fără a se da drept autorități, fără ajutor pentru eludarea controlului de frontieră sau vamal, fără cifre inventate, fără limbaj vulgar. Sunt verificate atât instrucțiunile, cât și răspunsurile; apelurile blocate sunt înregistrate.

Nou: un server MCP real la https://nakordoni.eu/mcp, care expune un subset sigur, doar pentru citire, al API-ului (status, checkpoints, border queue, live queue, forecast) sub formă de instrumente MCP. Aceeași cheie API și cotă ca la API-ul REST. Cardul serverului la /.well-known/mcp/server-card.json. Consultați secțiunea Server MCP din documentație.

Redenumirea în „Live Queue & Freshness API”, descrisă mai jos, nu a ajuns de fapt în pagina de documentație . Pagina afișează titlul fiecărui produs printr-o căutare de traducere care recurge la titlul punctului final doar când nu există traducere — iar o traducere exista deja, înghețată la numele vechi, în toate cele 25 de limbi ale interfeței. De acum are întâietate față de orice actualizare viitoare a titlului de bază, până când este actualizată și ea.

Cheia de traducere a fost redenumită în toate cele 25 de limbi, astfel încât pagina de documentație corespunde. Nicio modificare de punct final, parametri sau răspuns — doar textul titlului.

Dacă interogați frecvent datele cozii live, s-ar putea să consumați inutil cotă grea. /update-info este de clasă standard și returnează deja valoarea live:

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

Returnează queue_now, freshness, age_minutes, is_realtime, status, timestamp și timezone. Folosiți-l pentru reîmprospătarea frecventă din cota zilnică standard și păstrați /queue, /multi și /forecast (toate de clasă grea) pentru momentele în care aveți nevoie de wait_min, de câmpurile de tendință sau de istoric.

Nimic nu s-a schimbat în punctul final propriu-zis — doar în documentația sa. Era listat drept „Data Freshness API”, iar descrierea menționa doar evaluarea prospețimii, niciodată queue_now, așa că era ușor de trecut cu vederea. Acum se numește „Live Queue & Freshness API”, cu câmpurile returnate enumerate explicit. Mulțumim dezvoltatorului care a semnalat acest lucru.

Unele cereri eșuate returnau HTTP 200 cu ok: true și eroarea ascunsă în data — astfel, tiparul documentat if (!ok) throw nu le putea detecta, iar apelul era totuși taxat. Apelurile afectate returnează acum HTTP 400 cu ok: false și un error.code / error.messagecorect, conform documentației. Observat la fuel-cities cu o țară neacceptată și la travel-matrix cu coordonate greșite.

Separat: un parametru obligatoriu lipsă returna 500 internal_error în loc de 400 bad_request (corpul unui răspuns 4xx din serviciul intern era eliminat înainte de a i se citi starea). Acum returnează 400 bad_request cu mesajul serviciului intern — de exemplu search fără ?name=.

Răspunsurile reușite sunt neschimbate până la ultimul octet — aceleași câmpuri, aceiași parametri, același cost de cotă. Dacă clientul dumneavoastră ramifică deja pe ok, nu trebuie să schimbați nimic. Dacă ignora ok și citea direct data , va vedea acum plicuri de eroare la apeluri care oricum eșuau mereu.

A fost remediată o eroare din cauza căreia /multi putea returna un număr greșit de mașini în coadă pentru unele puncte de trecere — mai ales cele din Balcani și de la granița Ungaria–Serbia — ori de câte ori cache-ul său era rece. Varianta de rezervă citea un tabel care, pentru acele treceri, nu conține date despre coadă și raporta valori fără legătură drept număr de mașini. Exemple măsurate: un punct cu 12 mașini raporta 6, iar altele cu cozi reale raportau 0.

Trei schimbări pe care le puteți observa:

• found: false înseamnă acum că într-adevăr nu există date recente despre coadă. Înainte puteați primi found: true cu un queue_now: 0inventat.
• wait_status, trend_percent și trend_direction sunt returnate acum și la cererile „reci” — înainte erau null .
• Punctul final recurge la varianta de rezervă și atunci când instantaneul său din cache este învechit (mai vechi de 24 h), nu doar când lipsește.

Nicio modificare a parametrilor cererii, a costului de cotă sau a structurii răspunsului.

A fost corectată o eroare prin care fiecare apel /multi era facturat de două ori — o dată printr-o verificare generică de 1 unitate și încă o dată prin formula proprie de cost variabil a endpointului (N PPID-uri × subproduse). Un apel costă acum exact ⌈(N×M)/2⌉ unități, conform documentației, fără taxă suplimentară.

De asemenea, pe pagina de documentație a fost adăugată o insignă de clasă a cotei (Standard/Heavy) pentru fiecare produs, astfel încât să fie clar dintr-o privire ce cotă zilnică folosește un endpoint.

country și countries au fost unificate într-un singur parametru (1-15 coduri separate prin virgulă). Parametru nou compare_to: comparație între sărbători identice și diferite pe mai multe țări, se combină cu upcoming+days. lang acceptă acum mai multe limbi (adaugă un obiect names). days=0 sau omis înseamnă acum fără limită în modul upcoming.

Sărbători legale oficiale pentru fiecare țară europeană — date, denumiri locale și tip. Se bazează pe același serviciu Nager.Date / OpenHolidaysAPI (cu un calendar Kosovo calculat local) care alimentează pagina calendarului de sărbători de pe nakordoni.eu și factorii de calendar ai sistemului de predicție.

• ?country=PL&year=2026 — lista completă a sărbătorilor pe un an pentru o țară
• ?upcoming=1&days=30 — listă simplă a sărbătorilor apropiate din mai multe țări
• Fără parametri — index al unui set de bază de țări, cu următoarea sărbătoare pentru fiecare

Am adăugat produsul currency — cursuri de schimb bazate pe EUR pentru PLN, CZK, HUF, USD, GBP, CHF, NOK și UAH, preluate de la Frankfurter (BCE) și stocate în cache 6 ore. Fără parametri, returnează întotdeauna tabelul complet de cursuri. Consultați documentația.

Încorporați interdicțiile de circulație pentru camioane din Europa, în timp real, pe propriul site — un widget iframe gratuit cu 3 designuri (light, dark, board), 5 limbi (en, uk, pl, de, ru), un filtru opțional pe țară și status «activ acum» în timp real. Nu este necesară o cheie API. Configurați și copiați codul la nakordoni.eu/en/for_truck_drivers/traffic_bans/widget. Preferați datele brute? Produsul API truck-bans și fluxul JSON public rămân disponibile.

Trei adăugiri, toate compatibile retroactiv — v1 rămâne neschimbat.

Versionare per endpoint. Există acum un URL de bază /api/v2/. Funcționează per endpoint: doar endpoint-urile care s-au schimbat efectiv se comportă diferit sub v2; orice alt endpoint servește în mod transparent răspunsul v1 (astfel, /api/v2/data/queue = aceleași date ca v1, doar cu "api_version":"v2"). Nu este nevoie să migrați endpoint-urile care funcționează.

border v2 este direcțional. Ordinea din cale reprezintă direcția de deplasare:

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)

Fiecare checkpoint primește în plus un obiect direction {from,to} și un boolean stale, iar ?max_age_min=N returnează doar punctele de trecere actualizate recent. (v1 border returnează în continuare ambele părți ale graniței, indiferent de ordine — neschimbat.)

Sandbox interactiv. Dezvoltatorii autentificați pot încerca acum orice endpoint direct din browser la Developers → Sandbox — alegeți un endpoint, o versiune și una dintre cheile dumneavoastră, ajustați parametrii și vedeți răspunsul în timp real. Testarea în Sandbox are propriul buget zilnic separat (50 de apeluri/zi) și nu afectează niciodată cota API live.

Documentația este acum împărțită pe endpoint (Developers → API Docs), cu un selector de versiune la endpoint-urile care au mai multe versiuni.

Doi factori noi integrați în formula timpului de așteptare, alături de ajustările existente section_mode și de vreme:

• service_rate — mașini/min măsurate, procesate în prezent, față de rata de bază configurată a checkpoint-ului. Multiplicativ, limitat la 0.5x-1.5x.
• shift_change — impactul schimbului de tură al polițiștilor de frontieră la 08:00/20:00, ora locală a checkpoint-ului. Aditiv (minute), nu multiplicativ — aplicat doar în intervalul de +/-60 de minute față de un schimb, necesită un istoric minim de eșantioane, limitat la +/-120 de minute.

advanced_wait_min este acum round(base_wait × section_mode × weather × service_rate) + shift_change.adjustment_min. Ambii factori se reflectă și în driver_reported.prognosed_advanced_wait_min pentru comparații istorice.

În cadrul unei revizuiri de securitate/confidențialitate, următoarele câmpuri au fost eliminate — expuneau detalii interne de implementare (taxonomia surselor noastre de date din amonte, ID-uri de rânduri din baza de date, adnotări interne de pipeline, câmpuri neutilizate/moarte) fără o valoare reală pentru produs:

• id și corrected — eliminate din obiectele de rând ale queue
• source (șir brut, de ex. "line") — eliminat din queue, multi și update-info. update-info și blocul update_info al multi conțin în continuare source_category/source_label_en (un mic vocabular public); blocul queue al queue și al multi nu mai conține niciun câmp source
• traffic_status — eliminat din border; era mereu null și nu a fost niciodată populat de vreo parte a sistemului

Dacă integrarea dumneavoastră citește vreunul dintre aceste câmpuri, vă rugăm să o actualizați — consultați lista curentă de câmpuri pe pagina de documentație a produsului respectiv.

Consumul zilnic al cotei (usage.used în fiecare răspuns) poate fi acum o valoare zecimală (de ex. 67.5) în loc să fie mereu un număr întreg. Acesta este un efect secundar al faptului că queue-advanced este taxat la o rată fracționară — vedeți mai jos. usage.limit nu este afectat și este întotdeauna un număr întreg. Dacă clientul dumneavoastră tratează strict usage.used ca număr întreg, vă rugăm să îl extindeți pentru a accepta o valoare zecimală/float.

Aceste trei produse returnează acum aceleași câmpuri de status live pe care le afișează site-ul: wait_status (green/yellow/red, pe baza istoricului recent al acestui checkpoint) și trend_percent/trend_direction (up/up-slight/down/down-slight/stable, comparând ultimele 3 ore). Pur aditiv.

Rândurile data[] din /api/v1/data/queue aveau anterior wait_time: null pentru majoritatea surselor — doar câteva fluxuri din amonte raportează direct un timp de așteptare. Rândurile fără acesta primesc acum estimarea standard , marcată cu un nou boolean wait_time_estimated, astfel încât să puteți distinge o valoare raportată real de una calculată.

queue-advanced costă acum 1.5 units pe apel în loc de 1 (reflectând căutările suplimentare de trafic/vreme/rapoarte ale șoferilor pe care le efectuează) — vedeți usage.used mai sus. Răspunsul nu mai include nici total_crossing_time, iar driver_reported este acum doar {wait_min, ts, age_min} — câmpurile anterioare de comparație prognoză-realitate (prognosed_wait_min, diff_min, historical_section_mode, historical_weather etc.) au fost eliminate. section_mode, weather, advanced_wait_min și exceeds_crossing_time rămân neschimbate.

/api/v1/data/truck-bans returnează acum, pentru fiecare țară din bans_by_country, un status (active/clear) plus active_window, next_window, local_time și tz — calculate în fusul orar propriu al țării respective, astfel încât nu mai trebuie să evaluați dumneavoastră intervalele brute de interdicție în raport cu un ceas. Răspunsul adaugă și o listă covered_countries la nivel superior și un marcaj temporal as_of în UTC.

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

Pur aditiv — câmpurile existente current_bans/upcoming_bans/bans_by_country rămân neschimbate. Un ?country= necunoscut returnează acum un rezultat gol cu countries_not_covered în loc de interdicțiile fiecărei țări.

Un produs nou, opțional, care ajustează timpul de așteptare standard în funcție de fluxul de trafic în timp real și de vreme. Returnează detalierea completă a fiecărei ajustări.

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

Acordat la cerere — deschideți un tichet Data din panoul dumneavoastră pentru a-l activa.

/api/v1/data/border calculează acum corect wait_min pentru fiecare checkpoint din răspuns, la fel ca produsele queue și multi. Anterior, acest câmp era mereu null.

/api/v1/data/forecast utilizează acum în mod fiabil modelul ensemble v4 pentru orice valoare prediction_steps (anterior, unele orizonturi nestandard puteau reveni în tăcere la un model mai vechi). Factorul meteo care alimentează ensemble-ul a fost de asemenea corectat și reflectă acum cu adevărat condițiile în timp real (ploaie, ninsoare, vânt, ceață) în loc să raporteze mereu indisponibil.

Dezvoltatorii aprobați pot descărca acum date istorice ale cozilor de la frontieră, mediate orar, pentru până la 5 checkpoint-uri (fereastră glisantă de până la 90 de zile), în format CSV sau NDJSON, din noul tab Data export. Sunt disponibile doar date publicate și verificate calitativ; marcajele temporale sunt în UTC. Aveți nevoie de acces? Deschideți un tichet Data.

Încă nu aveți un site? Puteți crea acum un cont de dezvoltator descriind unde și cum intenționați să folosiți datele noastre, în loc să fiți obligat să introduceți URL-ul unei pagini live. Adăugați URL-ul real mai târziu din panoul dumneavoastră (Account & data → Proiectul dumneavoastră), imediat ce site-ul sau aplicația este live — un link vizibil către nakordoni.eu pe acea pagină este obligatoriu conform Termenilor noștri.

Dezvoltatorii pot trimite acum propriile știri legate de frontieră către fluxul de știri Nakordoni. Dacă editorii noștri le publică, primiți un backlink dofollow indexabil către serviciul dumneavoastră (semnătura editorului + rândul sursei) și traducem articolul în toate cele 24 de limbi gratuit.

Un articol pe săptămână este gratuit; articolele suplimentare sunt un supliment plătit. Alegeți 'putem edita ușor + adăuga linkuri interne' sau 'publicăm ca atare'. Trimiteți și urmăriți starea verificării la Developers → Submit news.

Multi-Checkpoint API (/api/v1/data/multi) taxează acum cota la ⌈(N PPIDs × sub-products) / 2⌉ — jumătate din costul apelurilor individuale echivalente. O cerere pentru 10 checkpoint-uri cu ambele sub-products costă acum 10 units în loc de 20. Antetul X-Devapi-Units și meta.units_consumed din răspuns reflectă suma redusă.

Obțineți statusul cozii în timp real și prospețimea datelor pentru până la 20 de checkpoint-uri într-un singur apel API — conceput pentru dezvoltatorii de dashboard-uri care interoghează în prezent multe PPID-uri într-o buclă.

Cota se contorizează echitabil ca N PPIDs × sub-products solicitate, astfel încât utilizarea totală este identică cu apelurile individuale — dar cu o singură comunicare dus-întors în loc de mai multe. Tiparele de tip GreenTravel scad de la 24+ apeluri/oră la 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 curent, wait_min estimat, vechimea datelor și numele checkpoint-ului
• include=update-info — prospețimea datelor, clasificarea sursei, vechimea în secunde/minute
• Maximum 20 de PPID-uri per cerere; combinați ambele sub-products într-un singur apel pentru date complete de dashboard
• Răspunsul include meta.units_consumed, astfel încât să puteți urmări cu precizie utilizarea cotei

Răspunsul produsului queue include acum un obiect snapshot la nivel superior, cu cele mai recente date în timp real și un timp de așteptare prognozat calculat — aceeași formulă folosită în secțiunea hero de pe nakordoni.eu:

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

Tabloul data (intrări istorice) rămâne neschimbat — aceasta este o adăugire pur aditivă. Clienții care nu citesc snapshot nu sunt afectați.

Interogați toate checkpoint-urile de la o anumită graniță + un tip de vehicul într-un singur apel, în loc să faceți o cerere per PPID.

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

• Acceptă o singură țară de destinație, o listă separată prin virgulă sau all pentru a se extinde deodată la fiecare vecin monitorizat.
• Rezultate sortate după queue_now crescător (cea mai scurtă coadă prima).
• Complet localizat: adăugați ?lang=uk (sau oricare dintre cele 22 de limbi acceptate) pentru a obține numele checkpoint-urilor în acea limbă.

Descoperiți valorile PPID ale checkpoint-urilor după nume, fără a răsfoi întregul director.

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

• Acceptă un singur nume sau o listă separată prin virgulă (până la 20).
• Caută în toate cele 24 de limbi de traducere — introduceți un nume în ucraineană, poloneză, germană sau orice limbă acceptată și îl va găsi.
• Returnează toate PPID-urile din acea locație, grupate după tipul de vehicul (mașină / autobuz / pieton / camion).

Produsul alternatives acceptă acum ?lang= în toate cele 22 de limbi acceptate (anterior doar 12).

Noul parametru crossing_type vă permite să suprascrieți filtrul tipului de vehicul — de ex. introduceți crossing_type=4 pentru a obține alternative pentru mașini chiar și atunci când interogați de la un PPID de autobuz.

Câmpul crossing_type_label din răspunsurile checkpoints, border și search este acum tradus în limba solicitată, în toate cele 22 de limbi acceptate. Câmpurile cu numele țărilor (origin_name, destination_name) urmează aceeași setare regională.

Portalul Nakordoni Developer API este activ la /en/developers. Înscrieți-vă pentru o cheie Explorer gratuită (200 de cereri/zi) pentru a accesa datele cozilor de la frontieră, prognoze, prețuri la carburanți, POI-uri pentru șoferi și multe altele.

Produse disponibile la lansare: checkpoints, queue, stats, day-stats, forecast, alternatives, update_info, fuel, pois, truck_bans, trading_sundays, bus_carriers, road_conditions, assistant.