API-ի փոփոխությունների ամսագիր
API-ի բոլոր կարևոր փոփոխությունները։ Նորերը վերևում։ v1 կայունություն — Breaking changes-ներ նոր տարբերակ չկա։
If an assistant has a feed enabled but the call does not carry the context that feed needs — queue without a ppid, for example — the feed is now skipped before any request is made and is not charged. Previously it was called anyway, failed, and still cost a unit. The studio shows what each feed needs, recalculates the price as you fill the context in, and marks results ✓ ran / ⊘ skipped, not charged / ✕ failed; the API returns data.feeds_skipped telling you exactly which parameter to pass.
Answers no longer mention feeds, data sources or anything technical: a missing feed is at most one plain sentence to the end user, never an internal name. Feeds with only optional filters (such as fuel narrowed to a country we have no data for) now fall back to the broad dataset instead of returning nothing.
New: /{lang}/developers/studio. Build an AI assistant that answers from your content and our live border data. Give us your markdown, or just name the pages and we fetch and index them — you only ever maintain your own files. Pick which of our feeds it may use (queue, forecast, alternatives, day-stats, fuel, truck bans, trading Sundays, holidays, road conditions, bus carriers, POIs, currency), pick a model tier (fast / balanced / pro — that is what sets the price), write your own instructions with {{feed.slug}} placeholders saying exactly where our data lands in the answer, and add a closing sentence of your own that is appended to every reply. Ready-made blueprints: personal travel assistant, work/freight assistant, insurance & Green Card sales assistant.
Test it in the studio (30 answers/day, separate from your API quota), then call it in production at GET /api/v2/data/assistant-custom?assistant_id=N&q=…. Price per answer = model tier units + 1 unit per enabled feed, returned in X-Devapi-Units. The product is v2-only — a v1 URL returns unsupported_version. The existing assistant product is unchanged.
Every assistant runs under a platform content policy that outranks your instructions: no impersonating officials, no help evading border or customs control, no invented numbers, no profanity. Instructions and answers are both screened; blocked calls are logged.
Նոր՝ իրական MCP սերվեր https://nakordoni.eu/mcp հասցեով, որը API-ի անվտանգ, միայն կարդալու ենթաբազմությունը (status, checkpoints, border queue, live queue, forecast) տրամադրում է որպես MCP գործիքներ։ Նույն API բանալին և քվոտան, ինչ REST API-ում։ Սերվերի քարտը՝ /.well-known/mcp/server-card.json հասցեով։ Տե՛ս MCP սերվեր բաժինը փաստաթղթերում։
The retitle to "Live Queue & Freshness API" below did not actually reach the docs page. The page renders each product title through a translation lookup that falls back to the endpoint's title only when no translation exists — and a translation already existed, frozen at the old name, in all 25 UI languages. It now wins over any future update to the underlying title until it is updated too.
Retitled the translation key in all 25 languages so the docs page matches. No endpoint, parameter or response change — title text only.
If you poll live queue data frequently, you may be spending heavy quota you do not need to. /update-info is standard-class and already returns the live figure:
GET /api/v1/data/update-info?ppid=id_13
It returns queue_now, freshness, age_minutes, is_realtime, status, timestamp and timezone. Use it for the frequent refresh against your standard daily quota, and keep /queue, /multi and /forecast (all heavy-class) for when you need wait_min, the trend fields or history.
Nothing changed in the endpoint itself — only its documentation. It was listed as the "Data Freshness API" and its description mentioned only the freshness rating, never queue_now, so it was easy to miss. It is now titled "Live Queue & Freshness API" with the returned fields spelled out. Thanks to the developer who raised this.
Some failed requests were returning HTTP 200 with ok: true and the error buried inside data — so the documented if (!ok) throw pattern could not detect them, and the call was still billed. Affected calls now return HTTP 400 with ok: false and a proper error.code / error.message, as documented. Seen on fuel-cities with an unsupported country and travel-matrix with malformed coordinates.
Separately, a missing required parameter returned 500 internal_error instead of 400 bad_request (an upstream 4xx body was being discarded before its status was read). It now returns 400 bad_request with the upstream message — e.g. search without ?name=.
Successful responses are byte-for-byte unchanged — same fields, same params, same quota cost. If your client already branches on ok, no change is needed. If it ignored ok and read data directly, it will now see error envelopes on calls that were always failing.
Fixed a bug where /multi could return a wrong queue count for some checkpoints — mainly Balkan and Hungary–Serbia crossings — whenever its cache was cold. The fallback read a table that, for those crossings, holds no queue data, and reported unrelated values as car counts. Measured examples: a checkpoint with 12 cars reported 6, and several with real queues reported 0.
Three changes you may notice:
found: falsenow means there is genuinely no recent queue data. Previously you could receivefound: truewith a fabricatedqueue_now: 0.wait_status,trend_percentandtrend_directionare now returned on cold requests — they werenullbefore.- The endpoint also falls back when its cached snapshot is stale (older than 24h), not only when it is missing.
No changes to request parameters, quota cost or response shape.
Ուղղվել է սխալ, որի պատճառով յուրաքանչյուր /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 հոսքը դեռ հասանելի են։
border և ինտերակտիվ Sandbox
Երեք հավելում, բոլորն էլ հետընթաց համատեղելի — 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-ների վրա, որոնք ունեն մեկից ավելի տարբերակ։
queue-advanced՝ երկու նոր ճշգրտման գործոն
Սպասման ժամանակի բանաձևի մեջ ներդրվեցին երկու նոր գործոն՝ առկա 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-ում՝ պատմական համեմատությունների համար։
queue, border, multi, update-info-ից
Անվտանգության/գաղտնիության վերանայման շրջանակում հեռացվեցին հետևյալ դաշտերը — դրանք բացահայտում էին ներքին իրականացման մանրամասներ (մեր վերընթաց տվյալների աղբյուրի տաքսոնոմիան, DB row ID-ները, ներքին pipeline-ի ծանոթագրությունները, չօգտագործվող/մեռյալ դաշտերը)՝ առանց իրական արտադրանքային արժեքի․
idևcorrected— հեռացվեցինqueuerow օբյեկտներիցtmin/tpercar— հեռացվեցինqueue,borderևmulti-ից (սպասման ժամանակի բանաձևի հաստատունները. արդեն հաշվարկվածwait_min/wait_time-ը չի ազդվում)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-ն այժմ կարող է լինել կոտորակային թիվ
Օրական քվոտայի օգտագործումը (usage.used յուրաքանչյուր պատասխանում) այժմ կարող է լինել տասնորդական արժեք (օր․ 67.5) միշտ ամբողջ թիվ լինելու փոխարեն։ Սա queue-advanced-ի կոտորակային դրույքով գանձման կողմնակի հետևանք է — տե՛ս ստորև։ usage.limit-ը չի ազդվում և միշտ ամբողջ թիվ է։ Եթե ձեր հաճախորդը խստորեն տիպավորում է usage.used-ը որպես ամբողջ թիվ, խնդրում ենք ընդլայնել այն՝ տասնորդական/float ընդունելու համար։
wait_status և trend_percent/trend_direction ավելացվեցին border, multi և queue-advanced-ին
Այս երեք արտադրանքներն այժմ վերադարձնում են նույն կենդանի-կարգավիճակի դաշտերը, որ ցույց է տալիս կայքը՝ wait_status (green/yellow/red, հիմնված այս անցակետի սեփական վերջին պատմության վրա) և trend_percent/trend_direction (up/up-slight/down/down-slight/stable, համեմատելով վերջին 3 ժամը)։ Զուտ հավելյալ։
queue՝ wait_time-ն այժմ լրացվում է յուրաքանչյուր պատմական row-ում
/api/v1/data/queue-ի data[] row-երը նախկինում ունեին wait_time: null աղբյուրների մեծ մասի համար — միայն մի քանի վերընթաց հոսք է ուղղակիորեն հայտնում սպասման ժամանակ։ Առանց դրա row-երն այժմ ստանում են ստանդարտ tmin + queue×tpercar գնահատականը՝ նշված նոր wait_time_estimated բուլյանով, այնպես որ կարող եք տարբերել իրական հայտնված ցուցանիշը հաշվարկվածից։
queue-advanced՝ գանձվում է 1.5x-ով, պատասխանը կրճատված է
queue-advanced-ն այժմ արժե 1.5 միավոր մեկ կանչի համար՝ 1-ի փոխարեն (արտացոլելով լրացուցիչ traffic/weather/driver-report որոնումները, որ այն կատարում է) — տե՛ս usage.used վերևում։ Պատասխանը նաև այլևս չի ներառում tmin, tpercar կամ 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-ն անփոփոխ են։
active_window / next_window)
/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-ով՝ յուրաքանչյուր երկրի արգելքների փոխարեն։
queue-advanced)
Նոր ընտրովի արտադրանք, որը ստանդարտ սպասման ժամանակը հարմարեցնում է կենդանի երթևեկության հոսքին և եղանակին։ Վերադարձնում է յուրաքանչյուր ճշգրտման ամբողջական վերլուծությունը։
GET /api/v1/data/queue-advanced?ppid=id_13
Տրվում է ըստ հարցման — այն միացնելու համար բացե՛ք Data տոմս ձեր վահանակից։
/api/v1/data/border-ն այժմ ճիշտ հաշվարկում է wait_min-ը (և վերադարձնում tmin/tpercar) պատասխանի յուրաքանչյուր անցակետի համար՝ համապատասխանելով 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-ն արտացոլում են զեղչված գումարը։
multi)
Ստացե՛ք կենդանի հերթի կարգավիճակ և տվյալների թարմություն մինչև 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 — tmin + queue_now × tpercar (minutes) snapshot.tmin — minimum crossing time (minutes) snapshot.tpercar — added time per vehicle (minutes) snapshot.updated_at — when the queue data was recorded snapshot.age_min — minutes since last update snapshot.source — data source identifier
data զանգվածը (պատմական գրառումներ) անփոփոխ է — սա զուտ հավելյալ ավելացում է։ Այն հաճախորդները, որոնք չեն կարդում snapshot, չեն ազդվում։
border)
Հարցում արե՛ք տվյալ սահմանի + տրանսպորտի տեսակի բոլոր անցակետերը մեկ կանչում՝ յուրաքանչյուր PPID-ի համար առանձին հարցում անելու փոխարեն։
GET /api/v1/data/border/{origin}/{destination}/{crossing_type}
- Աջակցում է մեկ նպատակակետ երկիր, ստորակետով բաժանված ցանկ կամ
all՝ բոլոր վերահսկվող հարևանների միանգամից ընդլայնման համար։ - Արդյունքները դասավորված են ըստ
queue_nowաճման (ամենակարճ հերթն առաջինը)։ - Ամբողջովին տեղայնացված. ավելացրե՛ք
?lang=uk(կամ մեր 22 աջակցվող լեզուներից որևէ մեկը)՝ այդ լեզվով անցակետերի անվանումներ ստանալու համար։
search)
Գտե՛ք անցակետի PPID արժեքներն ըստ անվան՝ առանց ամբողջ ցուցակը թերթելու։
GET /api/v1/data/search?name=Krakovets,Shehyni&lang=en
- Ընդունում է մեկ անուն կամ ստորակետով բաժանված ցանկ (մինչև 20)։
- Որոնում է բոլոր 24 թարգմանության լեզուներում — փոխանցե՛ք անունը ուկրաիներեն, լեհերեն, գերմաներեն կամ որևէ աջակցվող լեզվով, և այն կհամընկնի։
- Վերադարձնում է այդ վայրի բոլոր PPID-ները՝ խմբավորված ըստ տրանսպորտի տեսակի (car / bus / pedestrian / truck)։
crossing_type վերասահմանում
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։
Այս ամսագիրը ընդգրկում է հանրային API-ի փոփոխությունները։ Ներքին թարմացումները ցուցակված չեն։