Valutazione dei fornitori di DPP — le nostre risposte

TracePass espone un'API REST documentata che copre passaporti, prodotti, modelli, organizzazioni e webhook. Le superfici di lettura e scrittura sono simmetriche — tutto ciò che si può fare nell'interfaccia può essere gestito tramite l'API.

L'autenticazione avviene tramite chiavi API per organizzazione con permessi delimitati. La specifica OpenAPI è pubblicata per ogni cliente nel portale per sviluppatori — senza barriere NDA, senza l'attrito del "parlate con il nostro team di integrazione".

Ogni modello di categoria viene fornito con il proprio modello CSV — i nomi delle colonne corrispondono allo schema, tipi e vincoli sono validati al caricamento. Trascinate un file nell'interfaccia; l'endpoint di importazione massiva accetta lo stesso CSV tramite API per pipeline automatizzate.

La validazione è per riga con segnalazione degli errori a livello di colonna; le importazioni parziali sono atomiche (o tutte le righe vengono salvate, oppure il file viene rifiutato con un diff). Per i clienti ad alto volume, l'API di importazione supporta lotti multi-file.

Ogni piano a pagamento può instradare i codici QR attraverso il dominio del cliente (ad es. id.vostro-marchio.eu/01/...). TracePass risolve sotto il vostro dominio, quindi la portabilità degli URL è permanente — anche se cambiate fornitore, l'URL sulla confezione continua a funzionare.

Gli account gratuiti / di prova risolvono sotto tracepass.eu/p/...; il passaggio a un piano a pagamento non interrompe i codici QR già in circolazione che hanno avuto origine sul dominio condiviso. Dopo la cancellazione, TracePass continua a risolvere i vostri passaporti esistenti per 30 giorni senza costi (vedere le Condizioni di servizio) — per i clienti a pagamento su un dominio personalizzato, questo offre una finestra per reindirizzare il DNS verso il resolver di un altro fornitore. Dopo il periodo di tolleranza di 30 giorni, gli URL del dominio condiviso restituiscono “scaduto” e TracePass cessa di servire il dominio personalizzato.

Ogni passaporto in TracePass ha come chiave il numero di serie. gs1.serialNumber è il join primario canonico, con SKU/modello come campo secondario per il raggruppamento. Il modello di dati è stato progettato con il numero di serie come priorità, perché la direzione normativa è quella.

I passaporti a livello di numero di serie supportano i dati di ciclo di vita per unità: stato di salute, storico delle riparazioni, trasferimenti di proprietà, stato di fine vita. La creazione massiva e l'aggiornamento massivo per intervallo di numeri di serie sono operazioni di prima classe.

Ogni modifica al passaporto viene registrata con marca temporale, autore e diff a livello di campo. La pagina di dettaglio del passaporto mostra una cronologia delle versioni; ogni versione storica è recuperabile per ID tramite l'API.

Gli URL pubblici dei passaporti servono per impostazione predefinita la versione più recente; ?version=N o ?as_of=DATE restituiscono lo stato storico. È la superficie che le autorità utilizzano durante le richieste di valutazione della conformità.

Ogni passaporto si esporta come JSON-LD tramite l'API o il download dall'interfaccia. L'esportazione conserva i metadati dei campi, l'attribuzione delle fonti, la cronologia delle versioni e le traduzioni.

L'esportazione massiva a livello di tenant raccoglie ogni passaporto, ogni prodotto, ogni modello che avete creato. Gli allegati multimediali (immagini, rapporti di prova, PDF) vengono forniti con URL stabili che restano risolvibili durante il periodo di tolleranza di 30 giorni dopo la cessazione — abbastanza a lungo da migrare a un fornitore successore.

I modelli sono versionati. L'aggiunta di un campo non comporta interruzioni; modificare o rimuovere un campo crea una nuova versione dello schema con un percorso di migrazione esplicito. I passaporti in circolazione restano validi rispetto al loro schema originale; i passaporti modificati vengono validati rispetto alla versione più recente.

Ogni modifica normativa che tracciamo viene registrata nel Regulatory Changelog pubblico con data, ambito e impatto sulla migrazione. I clienti vengono avvisati prima che qualsiasi modifica dello schema entri in vigore.

Ogni URL pubblico di passaporto serve JSON-LD valido quando la richiesta porta Accept: application/ld+json. Lo stesso URL serve HTML per i browser e JSON-LD per i crawler e i sistemi delle autorità — nessun endpoint separato da scoprire.

Gli URL seguono la grammatica di GS1 Digital Link (.../01/{GTIN}/21/{serial}). Il resolver è sottoposto a test di conformità rispetto alla suite di riferimento di GS1.

Ogni passaporto contiene un blocco strutturale `parties` con chiave per ruolo di operatore economico. Ogni voce ha un GLN GS1 validato (13 cifre, cifra di controllo mod-10), denominazione legale, codice paese ISO 3166-1 e URL opzionale. Il GLN viene emesso sia in `gs1:partyGLN` (GS1 Web Vocabulary, preciso secondo specifica) sia in `schema:identifier` con `propertyID: "GS1:GLN"` (mirror schema.org), così i lettori compatibili con DPP e i crawler schema.org standard vedono ciascuno ciò che si aspetta.

Per i fornitori senza GLN, un campo `legacyOperatorId` accetta una partita IVA, un EORI, un codice fiscale nazionale o un codice fornitore interno — ogni parte resta tracciabile anche prima che l'avvio GS1 del fornitore sia completato.

L'applicazione dei ruoli obbligatori per categoria corrisponde al regolamento: i passaporti delle batterie richiedono fabbricante + riciclatore + PRO; i giocattoli richiedono fabbricante + importatore; le categorie che recano imballaggi (FMCG, imballaggi) richiedono il PRO. I ruoli opzionali compaiono nell'editor ma non bloccano la pubblicazione. La stessa mappa dei ruoli alimenta l'editor della dashboard, l'API v1 (`PATCH /api/v1/passports/{id}/parties/{role}`) e i modelli di importazione massiva CSV (colonne con chiavi puntate: `manufacturer.gln`, `recycler.legalName` ecc.).

Due SLA distinti: 99,9% per il portale dell'applicazione in cui voi e il vostro team lavorate; 99,95% per il resolver pubblico che le autorità e i consumatori raggiungono tramite codici QR. Il resolver è preceduto da una CDN e replicato tra più regioni per l'obiettivo più elevato.

La pagina di stato traccia entrambe le superfici in modo indipendente. I crediti per interruzione si applicano per superficie — i crediti del portale non richiedono un'interruzione del resolver, e viceversa.

Database primario: MongoDB Atlas in eu-west-1 (Francoforte). Runtime dell'applicazione: regioni edge UE di Vercel. Consegna delle email: SES in regione UE. Monitoraggio e logging: regione UE. Elenco completo dei subincaricati del trattamento con relative giurisdizioni nella pagina trust.

Non utilizziamo alcun subincaricato del trattamento esclusivamente statunitense nei percorsi dei dati di produzione. Il percorso di elaborazione IA di Anthropic (usato per l'estrazione delle categorie e le traduzioni) viene invocato solo su richiesta del cliente ed è regolato da un esplicito DPA — la pagina trust lo documenta in dettaglio.

DPA standard per responsabile del trattamento disponibile; firmato prima che fluiscano i dati del cliente. Il registro dei subincaricati del trattamento nella pagina trust elenca ogni responsabile con ruolo e giurisdizione; le aggiunte attivano una notifica preventiva ai sensi dell'Articolo 28.

Le richieste di accesso e di cancellazione dell'interessato possono essere soddisfatte rispetto alla superficie di analisi (il contenuto del passaporto in sé è costituito da dati di prodotto, non da dati personali). Notifica delle violazioni: 72 ore dall'incidente confermato, codificata nel DPA.

Backup operativi: ripristino point-in-time di 30 giorni sul database primario. Il ripristino viene testato secondo una pianificazione ricorrente.

Conservazione lungo il ciclo di vita del prodotto: i passaporti restano attivi e interrogabili per l'intera durata di vita normativa applicabile a ciascuna categoria di prodotto, in linea con la pertinente aspettativa di conservazione dell'ESPR o specifica del settore. La durata di vita viene applicata anche dopo la cessazione dell'abbonamento, per tutta la finestra di continuità del resolver.

L'isolamento predefinito è logico: ogni lettura e scrittura è delimitata da companyId, applicato a livello di accesso ai dati (non nel controller). I test verificano che l'ambito non possa essere aggirato nemmeno con un'omissione deliberata di companyId nelle query.

I clienti Enterprise possono richiedere l'isolamento fisico: i loro dati vivono in un cluster MongoDB dedicato, con un'istanza applicativa dedicata. Il prezzo è da concordare; i tempi di attivazione sono di giorni, non settimane.

Quota di passaporti a fasce. Ogni piano include un numero di passaporti; l'eccedenza è misurata a una tariffa pubblicata che diminuisce con la scala. Non addebitiamo mai per scansione — il volume di scansioni dei consumatori è imprevedibile, e non vi invieremo una fattura a sorpresa quando uno dei vostri prodotti diventa di tendenza.

Per i fabbricanti di batterie, veicoli elettrici e pneumatici ad alto volume con obblighi a livello di numero di serie, offriamo un pacchetto a volume di serie con prezzi a costo marginale che rendono sostenibile l'economia su larga scala. Contattateci.

L'esportazione JSON-LD completa di ogni passaporto, prodotto, modello e allegato multimediale è disponibile su richiesta senza costi. Nessuna "tariffa di esportazione".

Dopo la cancellazione, TracePass continua a risolvere i vostri passaporti esistenti per 30 giorni senza costi (codificato nel Contratto quadro di servizio). Durante quella finestra, i codici QR sugli imballaggi già stampati continuano a risolvere verso i vostri dati mentre migrate; su un dominio personalizzato reindirizzate il DNS verso un fornitore successore e i codici stampati non si interrompono mai.

Il cliente è il titolare del trattamento per tutta la durata del rapporto e dopo la cessazione. Source escrow opzionale disponibile su Enterprise: una copia con tag del codice sorgente della nostra applicazione è conservata da una terza parte indipendente, rilasciabile a voi al verificarsi di eventi scatenanti definiti.

Massimale di responsabilità standard: 12× i canoni mensili. I clienti Enterprise possono negoziare una clausola aggiuntiva 24× per profili di esposizione più elevati.

L'assicurazione E&O è in essere; il massimale della polizza è pubblicato nella pagina trust. La pagina trust elenca inoltre le esclusioni dall'indennizzo (rivendicazioni di proprietà intellettuale di terzi, sanzioni normative riconducibili a un errore del fornitore).

Pubblichiamo il risultato del test di conformità a GS1 Digital Link nella pagina trust. Lo Schema.org JSON-LD viene emesso su ogni URL pubblico di passaporto. L'allineamento del vocabolario alle raccomandazioni CIRPASS è documentato campo per campo.

Gli identificatori GS1 GLN (Global Location Number) sono campi di prima classe su ogni passaporto — rigorosa validazione mod-10 a 13 cifre, con chiavi per più ruoli (fabbricante / importatore / mandatario / distributore / riciclatore / organizzazione per la responsabilità del produttore) ed emessi sia nella forma gs1:partyGLN sia in schema:identifier 'GS1:GLN', così i lettori compatibili con DPP e i crawler schema.org standard vedono ciascuno ciò che si aspetta.

Dove la conformità è parziale (ad es. raccomandazioni CIRPASS successive alla nostra ultima revisione di allineamento, o il percorso resolver /414/{gln} che è nella roadmap build-on-first-ask), la lacuna viene nominata esplicitamente con una versione obiettivo.

Per le categorie in cui l'atto delegato non è ancora definitivo, manteniamo nel modello marcatori espliciti per i campi speculativi. I clienti Pro ed Enterprise possono presentare proposte a livello di campo che, dopo una breve revisione, confluiscono nella versione successiva del modello.

I clienti vengono elencati come collaboratori nel blocco di metadati del modello — riconoscimento e tracciabilità del contributo.

I clienti Enterprise possono optare per il source escrow tramite un agente di deposito terzo e indipendente. Una copia con tag del codice sorgente dell'applicazione viene depositata e aggiornata con cadenza ricorrente.

Gli eventi di rilascio sono definiti nell'accordo di escrow e includono tipicamente: insolvenza del fornitore, violazione sostanziale non sanata o interruzione prolungata oltre una soglia definita.