Changelog

A legutóbbi kiadások válogatott fénypontjai. A teljes API-verziókért és a visszamenőleges kompatibilitást érintő változások (Breaking Changes) irányelveiért lásd az API-verziókezelés és LTS-irányelvek oldalt.

Részletes változások az egyes végpontokon (endpoints): OpenAPI-specifikáció és interaktív API-referencia.

2026-08 · Keyset kurzor mostantól minden lista-végponton

Javítás: A GET /v1/codes és GET /v1/dpp végpontokhoz készült kurzor-javítás (lásd alább) mostantól az összes többi kurzor-lapozású listára is kiterjesztésre került: GET /v1/qr-codes/:id/comments, /v1/workspaces, /v1/gs1/identifiers, /v1/members, /v1/audit-logs, /v1/admin/orgs, /v1/admin/users és /v1/webhooks/:id/deliveries. Mindegyik kizárólag a created_at mező alapján lapozott; az azonos időbélyeggel rendelkező sorok (egy kötegelt művelet audit bejegyzései, Webhook-újrapróbálkozások, tagok importálása) elveszhettek a következő oldalon. A rendezési kulcs mostantól mindenhol a (created_at, id) pár.
API-változás: Ezeken a listákon a meta.pagination.next_cursor mostantól szintén egy opak (nem átlátszó) érték (base64url) a puszta időbélyeg helyett; az olvashatatlan kurzorok 400-as hibát adnak vissza, a régi időbélyeg-kurzorokat átmenetileg továbbra is elfogadjuk. Kivétel a GET /v1/webhooks/:id/deliveries: ott a next_cursor továbbra is az utolsó kézbesítés azonosítója marad (ismeretlen azonosító → első oldal). Azoknak a klienseknek, amelyek a next_cursor értéket változatlanul küldik vissza — Vezérlőpult, CLI, SDK-k, MCP —, nem kell semmit sem változtatniuk.
Hatás: Nincs szükség migrációra. Ha valaki hiányolt bejegyzéseket a lapozás során ezen listák valamelyikében (pl. az audit naplóban vagy a kézbesítési naplóban a Vezérlőpulton): Soha nem tűntek el — a listák mostantól teljes egészében megjelenítik őket.

2026-08 · Az időbélyegek szerkesztés és törlés után újra OpenAPI-konformak

Javítás: A PATCH /v1/codes/{id} hívás után az updated_at SQLite formátumban, időzóna nélkül tért vissza (2026-08-17 09:00:00), bár az OpenAPI-specifikáció a format: date-time formátumot ígéri, és a létrehozás (POST) az ISO időbélyeget (2026-08-17T09:00:00.000Z) adja vissza. Ugyanez vonatkozott a deleted_at/updated_at értékekre soft-delete esetén, valamint az API-kulcsok, szervezetek, Workspace-ek, tagok, megjegyzések és webhookok szerkesztési/törlési útvonalaira, továbbá az API-kulcsok last_used_at és a webhookok last_triggered_at értékeire. Mostantól minden írási útvonal ISO 8601 (UTC, T és Z) formátumú időbélyeget használ.
Hatás: Azok a kliensek, amelyek az updated_at értéket a new Date(...) függvénnyel elemzik (SDK-k, CLI, Vezérlőpult), a szóközös formátumot helyi időként értelmezték — a CLI az egyszer már szerkesztett kódoknál a helyi eltolódással eltolt időt mutatta (Bécs: −2 h). Ez javításra került. Emellett egy adatmigráció normalizálja a már elmentett, régi formátumú értékeket ISO formátumra, hogy a rendezés és az összehasonlítás a vegyes adatokban is helyes legyen. A mezőnevek és a válaszstruktúra nem változott.
Háttér: Ugyanaz a hibaosztály, mint az alábbi két javítás (API-kulcs lejárata, újraszkennelési cutoff): az SQLite datetime('now') függvénye YYYY-MM-DD HH:MM:SS formátumban ír, míg az összes többi író ISO 8601 formátumot használ. Egy forráskód-védelmi teszt (guard test) a jövőben megakadályozza az újabb előfordulásokat.

2026-08 · A listás lapozás többé nem veszít el batch kódokat

Javítás: A GET /v1/codes és a GET /v1/dpp kizárólag a created_at alapján lapozott. A POST /v1/codes/batch, POST /v1/dpp/batch végpontokból és a CSV/XLSX-importból származó kódok azonban egyetlen időbélyegen osztoznak — amint egy batch nagyobb volt, mint a limit (alapértelmezetten 20), a második oldal már nem adta vissza az ugyanahhoz az időbélyeghez tartozó többi sort. A kódok léteztek és elérhetők voltak a GET /v1/codes/:id útvonalon, de a listában (Vezérlőpult, CLI qr3 list, SDK-k, MCP) soha nem jelentek meg. A kurzor mostantól egy keyset a (created_at, id) felett.
API-változás: A meta.pagination.next_cursor mostantól egy opak érték (base64url) a puszta időbélyeg helyett. Azoknak, akik a kurzort változatlanul adják vissza ?cursor= paraméterként — ahogyan a Vezérlőpult, a CLI, az összes SDK és az MCP-szerver is teszi —, semmit sem kell változtatniuk. A régi időbélyeg-kurzorokat átmenetileg továbbra is elfogadjuk; az olvashatatlan kurzorok mostantól 400-as hibát adnak vissza ahelyett, hogy csendben az első oldalt adnák vissza.
Hatás: Ha egy batch-import után kevesebb kódot látott a listában, mint amennyi létrejött: a kódok soha nem tűntek el — a lista mostantól hiánytalanul megjeleníti őket. Nincs szükség migrációra.

2026-08 · A biztonsági újraszkennelések ismét 24 órás ütemben futnak

Javítás: A cél-URL-ek és a landing page-linkek időszakos újraszkennelése (Google Web Risk) kihagyta azokat a kódokat, amelyek utolsó szkennelése ugyanarra a naptári napra esett, mint a 24 órás cutoff — az időponttól függően az újraszkennelés akár egy további nappal is késhetett. A cutoff kiszámítása mostantól ugyanabban az ISO-formátumban történik, amelyben a szkennelési időbélyegek tárolva vannak.
Hatás: Ha egy cél-URL az utolsó szkennelés után nem biztonságosnak minősül, az ismét a dokumentált 24 órás időablakon belül a kód automatikus szüneteltetését eredményezi. Nincs változás az API-ban vagy a válaszformátumban.

2026-08 · Az API-kulcsok lejárnak a lejárati időpontban

Javítás: Azokat az API-kulcsokat, amelyek expires_at értéke az adott napra esett, UTC szerint éjfélig továbbra is elfogadta a rendszer. A lejárat összehasonlítása mostantól időbélyegként történik karakterlánc helyett — a lejárt kulcsok azonnal 401-es hibát adnak vissza.
Háttér: Az expires_at érték ISO-időbélyegként van tárolva (2026-08-14T09:00:00Z), míg az összehasonlító oldal szóközös formátumot adott vissza (2026-08-14 09:00:00). A nyers karakterlánc-összehasonlítás ezért csak akkor működött helyesen, ha már a dátum is eltért.
Hatás: Nincs szükség migrációra, a GET /v1/api-keys válaszformátuma változatlan marad. Az olvashatatlan lejárati értékek mostantól lejártnak minősülnek az érvényes helyett.

2026-08 · API-referencia: Tenant-kezelés dokumentálva

OpenAPI: A specifikáció — és ezáltal az interaktív referencia — mostantól dokumentálja a szervezeteket (beleértve a GET /v1/organizations/usage végpontot), a Workspace-eket, a tagokat és szerepköröket, valamint az Audit-logokat.
Billing: A díjcsomag-áttekintés (GET /v1/billing/plans) nyilvános; a Checkout (POST /v1/billing/checkout) és a Stripe-ügyfélportál (GET /v1/billing/portal) a szervezet adminisztrátorai számára fenntartott végpontokként vannak megjelölve.
Scan-export: A beolvasási statisztikák (GET /v1/codes/{id}/scans) és a nyersadat-export (…/scans.csv, …/scans.xlsx) teljes körűen dokumentálva vannak — beleértve a GDPR-tájékoztatást: az ip_hash soha nem szerepel az exportban.
Hibakezelés: Újonnan dokumentálásra került a kérés-validáció 400-as válasza is: a törzs a nyers Zod-hiba, nem egy RFC-7807 problémadokumentum — ennek ellenére az application/problem+json Content-Type fejléccel kerül kiküldésre.

2026-08 · Nyilvános fájlhivatkozások másolása

Dashboard: A kód részletező oldalán található nyilvános fájlok mostantól rendelkeznek egy gombbal, amely a nyilvános hivatkozásukat a vágólapra másolja – ez közvetlenül használható egy QR-kód cél-URL-jeként, ha a beolvasásnak azonnal egy adott dokumentumot kell megnyitnia a fájllistát tartalmazó landing page helyett.
API: A fájl-végpontok (/v1/files) mostantól a public_url mezőt is visszaadják. Ez a mező csak a visibility: public beállítású fájloknál van kitöltve – a privát fájlok nem kapnak nyilvános címet.
Működés: A hivatkozás nem igényel bejelentkezést, és közvetlenül a böngészőben nyitja meg a fájlt. A fájl lecserélése változatlanul hagyja a hivatkozást, így a rá nyomtatott kód érvényes marad. Részletek: Fájlok és adatlapok.

2026-07 · Csapatszerepkörök: Szerkesztő törlés nélkül és Admin számlázás

Új: Szerkesztő (törlés nélkül) tagi szerepkör — QR-kódokat, fájlokat és Digital Product Passport-okat hozhat létre és szerkeszthet, de nem törölhet semmit, és nem hozhat létre API-kulcsokat. Minden destruktív végpont szerveroldalon ellenőrzi a szerepkört (403).
Számlázás: A csomag-upgrade-ek és a Stripe ügyfélportál (POST /v1/billing/checkout, GET /v1/billing/portal) mostantól a szervezet adminisztrátorai (Organisations-Administratoren) számára vannak fenntartva — az összes többi szerepkör egy írásvédett csomagáttekintést lát.
Dashboard: A saját szerepkör által nem engedélyezett műveletek elrejtésre kerülnek: Egy Olvasó (Betrachter) például nem látja a létrehozásra, szerkesztésre vagy törlésre szolgáló gombokat; a listák, letöltések és statisztikák láthatóak maradnak. Részletek: Csapat és szerepkörök.

2026-06 · Külső hivatkozások a kód landing page-én

Landing page: A qr3 által hosztolt landing page mostantól képes külső, saját hosztolású hivatkozásokat ({ label, url }) is listázni – a feltöltött fájlok mellett vagy azok helyett, például a saját webhelyen található adatlapokhoz.
API: A POST/PATCH /v1/codes végpontok elfogadnak egy links tömböt (0–20 bejegyzés, http(s), ≤ 2048 karakter). Minden URL-t ellenőriz a Google Web Risk; a nem biztonságos URL-ek 422-es hibát adnak vissza. Egy üres tömb törli az összes hivatkozást.
Dashboard: Hivatkozások hozzáadása, rendezése és eltávolítása a kód részletező oldalán.
Biztonság: A renderelt hivatkozások XSS-biztosak maradnak (escaped, csak http(s)), és az oldal megtartja a noindex fejlécét.

2026-04 · Dashboard-Analytics QR-kódonként

Dashboard: A QR-kód listában található Analytics gomb mostantól megnyitja az adott QR-kód statisztikai oldalát a /dashboard/codes/{id} útvonalon.
Routing: A /dashboard/codes alias továbbra is átirányít a /dashboard oldalra, de már nem kapja el a részletes útvonalakat, mint például a /dashboard/codes/{id}.
API: A részletező oldal közvetlenül a GET /v1/codes/:id hívással tölti be a QR-kódot; ezáltal már nem függ a listázási lapozási (pagination) korlátoktól.
Tesztek: A regressziós tesztek lefedik az alias-átirányítást és a közvetlen kód-betöltést.

2026-04 · Dashboard törlési párbeszédpanel QR-kódokhoz

Dashboard: A QR-kód listában lévő kuka ikon mostantól egy saját React párbeszédpanelt (dialog) nyit meg a natív böngészős felugró ablak (popup) helyett.
Visszajelzés: Törlés után egy toast értesítés jelenik meg a sikerről vagy a hibáról.
Tesztek: A packages/dashboard/tests/dashboard.test.ts megakadályozza a regressziókat a confirm() hívásra a QR-kód törlési folyamatában.

2026-04 · Dashboard rövid link teszt dinamikus QR-kódokhoz

Dashboard: A QR-kód listában szereplő shortcode-ok mostantól közvetlenül kattintható külső átirányítási (redirect) linkekként működnek. A külső link ikon például a wu3qaa mellett megnyitja a https://qr3.app/{shortCode} címet egy új lapon.
i18n: Bővítettük a tooltip szövegeket német és angol nyelven.
Tesztek: A packages/dashboard/tests/dashboard.test.ts védi a link href-et, az új lapon való megnyitást, a noopener noreferrer attribútumot és az ikont a regressziókkal szemben.

2026-04 · Redirect-Worker útvonal dinamikus QR-kódokhoz

Javítás: A https://qr3.app/{shortCode} alatti dinamikus QR-kódokat ismét a redirect-worker dolgozza fel. A production útvonal mostantól a qr3.app/* mintát használja, mivel a Cloudflare Worker útvonalak nem támogatják a :code útvonal-paramétereket.
Megerősítés: A nem egyező útvonalak továbbításra kerülnek a landing-origin felé, hogy a normál oldalakat, mint például a /de/pricing, ne blokkolja a redirect-worker.
Tesztek: A packages/redirect/tests/unit/redirect.test.ts ellenőrzi a wildcard útvonalat, a shortcode feldolgozást és az origin-pass-through működését.

2026-04 · Workspace DPP beolvasási áttekintés (Q3.4.2)

Új: GET /v1/workspace/stats/dpp?days=30 — összesíti az API-key workspace összes dpp_scans adatát (active_dpps, scans_by_day, top_dpps terméknévvel/kategóriával).
Dashboard: Kártya a kezdőlapon (/dashboard) 30 napos oszlopdiagrammal + toplistákkal — a QR-kód kártyákkal párhuzamosan.
Nyilvános: Marketing shortlink GET /dpp/dpp_<id> (egy szegmens) élő demókhoz, a /dpp/{gtin}/{serial} útvonallal párhuzamosan.

2026-04 · DPP beolvasási analitika (Q3.4.1)

Új: GET /v1/dpp/:id/stats?days=30 — a nyilvános GS1-resolver összesített beolvasásai DPP-nként. Mezők: total_scans, period_scans, scans_by_day, top_countries, top_devices, top_representations.
Új: dpp_scans tábla (migráció: 0011) — elkülönítve a scans táblától (redirect-worker). Az IP-címek naponta változó (rotáló) salt segítségével kerülnek hashelésre, a nyers IP-címek soha nem érik el a D1-et.
Dashboard: Mini diagramkártya (SVG, diagramkönyvtár nélkül) a /dashboard/dpp/:dppId oldalon 30 napos oszlopokkal + top 3 lebontással. Empty-state (üres állapot) jelenik meg, amint egy DPP éles, de még nem volt beolvasása.

2026-04 · Élő EU-megfelelőségi szimulátor (Q3.3.7)

Új: POST /v1/dpp/:id/validate-update — részleges frissítéseket szimulál stateless módon (státusz, piaclista, …) perzisztencia nélkül. A válasz tartalmazza az eu_compliance + preview.changed_fields adatokat.
Dashboard: Szimulátor kártya a DPP részleteiben (/dashboard/dpp/:dppId) — chipek a DE/AT/FR/IT/ES/NL + egyéni értékekhez, státusz legördülő menü, Preview EU impact / Save changes / Reset. Nem blokkoló működés Remix useFetcher segítségével.
Megerősítés: Kiszervezett szimulátor segédfunkciók (readUpdatePatchFromForm, marketCountriesKey) + 18 új unit teszt; hibajavítás: az egyedülálló, nem ISO formátumú bemenet már nem törli a piaclistát.

2026-04 · Élő EU-megfelelőségi előnézet a létrehozási űrlapon (Q3.3.6)

Módosítva: A POST /v1/dpp/validate mostantól az eu_compliance adatot is visszaadja — ugyanaz a validátor, mint a GET /v1/dpp/:id/eu-compliance, stateless módon a mentés előtt.
Dashboard: Előnézet a meglévő validációs panel alatt + új Save-Guard-Banner a beküldő gombok előtt, ha hibák/figyelmeztetések vannak (i18n többes szám kezelés DE/EN).

2026-04 · EU-validátor + Textil UI (Q3.3.4 + Q3.3.5)

Új: EU-megfelelőségi validátor 5 textilipari szabállyal (TEXTILE_AGEC_REQUIRED, TEXTILE_MICROPLASTICS_CONSISTENCY, TEXTILE_SVHC_THRESHOLD, TEXTILE_GREENWASHING, TEXTILE_ESPR_READY).
Új: GET /v1/dpp/:id/eu-compliance a következő mezőkkel: compliant / espr_ready / issues[] / summary.
Dashboard: EU-megfelelőségi szakasz a DPP részleteiben (összegző kártyák, csoportosított Issue-kártyák, ESPR-Ready-Badge a fejlécben).

2026-04 · Textil DPP-séma (Q3.3.1–Q3.3.3)

Új: textile kategória kötelező AGEC-lánccal (szövés/kötés → festés/nyomás → konfekcionálás), szálankénti origin_country + recycled_pct, svhc_substances[], ESPR-opt-in (PEF, élettartam, újrahasznosíthatóság).
Új: Alapvető market_countries: string[] mező (ISO 3166-1 alpha-2) minden DPP kategórián — vezérli a Franciaország-specifikus AGEC-szabályokat és a kötelező francia fogyasztói tájékoztatót.
Új: Fogyasztói HTML-sablon AGEC mikroműanyag-figyelmeztető dobozzal, 3 lépcsős származási lánccal (zászló-pille ikonok), SVHC-listával, tartóssági (durability) és újrahasznosíthatósági (recyclability) szakasszal.
Migráció: 0010_dpp_market_countries (D1).

2026-04 · DPP tömeges import (Q3.2.1–Q3.2.5)

Új: A POST /v1/dpp/import elfogad CSV és XLSX formátumokat (Worker-kompatibilis a SheetJS xlsx segítségével, ~283 KB gzip csomagméret).
Skálázott: csomagalapú korlát (Free 100 → Enterprise 10k) + darabolt (chunked) db.batch() 100-asával + 5 MB-os kéréstörzs-korlát (body-limit).
Új: Hibajelentés CSV formátumban a 201-es válasz errors_csv mezőjében; a GET /v1/dpp/import/templates/:category?format=csv|xlsx kész sablonokat biztosít az akkumulátor (battery) és textil kategóriákhoz.
Dashboard: Drag-and-drop feltöltés a /dashboard/dpp/import oldalon sablon-proxyval és beágyazott (inline) CSV-letöltéssel.

Nem kompatibilitást törő (Non-Breaking) — LTS-bővítések

A fent említett változások mindegyike additív:

A meglévő POST /v1/dpp/validate kliensek változtatás nélkül figyelmen kívül hagyják az új eu_compliance mezőt.
A meglévő battery folyamatok változatlanok.
A market_countries opcionális, és alapértelmezetten [] értékű.

Lásd az API-verziókezelés oldalt a Breaking-Change irányelvekért.