Chi opera nel settore immobiliare, negli studi notarili, o più in generale si occupa di dati catastali in Italia, ha già una propria opinione maturata su SISTER. Non è necessario ricordare cosa sia una visura catastale. È sufficiente pensare all'ultima sessione di lavoro sul portale - il login SPID che scade, i form da ricompilare, i risultati in HTML da ricopiare manualmente - per riconoscere un problema che il settore conosce da anni.
SISTER funziona, per quello che è stato progettato: una consultazione alla volta, pensata per l'operatore umano. Il problema è che il contesto operativo intorno a SISTER è profondamente cambiato, mentre il portale è rimasto sostanzialmente fermo.
Chi effettua due visure al mese non affronta particolari difficoltà. Chi ne gestisce duecento alla settimana, sì.
Il limite strutturale
La questione di fondo è nota a chiunque abbia provato a costruire qualcosa sopra i dati catastali italiani: non esiste un'interfaccia programmatica. SISTER non espone API, non restituisce JSON, non prevede un flusso machine-to-machine. Non si tratta di una dimenticanza - non è stato progettato per quello. È un portale web con form HTML, pensato per restituire documenti a un utente con un browser.
Le conseguenze sono concrete e ben note nel settore.
Uno studio notarile che deve chiudere la cessione di un portafoglio con duecento unità immobiliari ha bisogno di duecento visure, una alla volta, con la sessione SPID che scade periodicamente e richiede un nuovo login. Uno sviluppatore che sta costruendo un prodotto PropTech e necessita della rendita catastale aggiornata come input di una pipeline dati non ha altra strada ufficiale che la consultazione manuale. Un fondo immobiliare che deve monitorare periodicamente la situazione catastale dei propri asset affronta lo stesso processo del privato che controlla casa propria - replicato centinaia di volte.
Nel frattempo, in diversi paesi europei i sistemi catastali espongono servizi WFS, endpoint INSPIRE, in alcuni casi API REST complete. In Italia, 85 milioni di particelle - una delle banche dati immobiliari più ampie del continente - restano accessibili attraverso un form HTML.
Cosa fa visura-api
visura-api nasce come risposta a questo problema. Il principio è lineare: se il portale non fornisce un'API, è possibile costruirne una sopra.
In pratica, il servizio si interpone tra l'applicazione dell'utente e SISTER. Una chiamata REST - POST /visura con provincia, comune, foglio, particella - attiva un browser headless (Playwright + Chromium) che esegue l'intera sequenza che altrimenti andrebbe svolta manualmente: apertura di SISTER, compilazione dei moduli, attesa del risultato, lettura dal DOM e restituzione in JSON.
Non si tratta di un aggiramento di sistemi di sicurezza. Il servizio utilizza le credenziali SPID dell'utente, le stesse necessarie per un accesso manuale. La differenza è che l'operazione viene eseguita programmaticamente.
Tre modalità di estrazione
Il servizio copre i casi d'uso più ricorrenti nell'operatività professionale:
Immobili per particella - dato foglio e particella, restituisce quanto esposto da SISTER: categoria, classe, consistenza, rendita, indirizzo. In formato strutturato, non in un PDF da interpretare.
Intestatari - per ogni immobile identificato, i titolari di diritti reali: proprietari, usufruttuari, nudi proprietari, con le rispettive quote.
Sezioni censuarie - estrazione massiva delle sezioni territoriali per provincia. Una funzionalità rivolta a chi costruisce database geografici completi o conduce analisi territoriale su scala regionale.
Lo stack tecnico
FastAPI come layer HTTP: il modello async si presta a gestire richieste che impiegano 30-60 secondi, dove il collo di bottiglia non è il software ma i tempi di risposta del portale SISTER. Playwright per il browser automation, per una gestione di Chromium più affidabile e moderna rispetto a Selenium. Docker per il deploy, per eliminare la complessità di configurazione di Chromium headless sui diversi ambienti.
Ogni richiesta impiega tra i 30 e i 60 secondi - tempo determinato dal portale SISTER, non dall'applicazione. Le richieste vengono accodate internamente per rispettare i limiti di frequenza del sistema.
Perché open source
Questo è il punto centrale dell'articolo e, con ogni probabilità, la ragione per cui vale la pena scriverlo.
visura-api avrebbe potuto essere un servizio chiuso. Sarebbe stato possibile collocarlo dietro un paywall, vendere visure automatizzate a pochi euro l'una, e generare ricavi in un mercato dove gli intermediari applicano tariffe tra i 12 e i 27 euro a documento. Invece è pubblicato su GitHub con licenza AGPL-3.0, leggibile e utilizzabile da chiunque.
La ragione non è idealismo astratto. È la convinzione che questo tipo di strumento debba esistere come infrastruttura condivisa, non come rendita di posizione per chi è arrivato prima a scrivere uno scraper.
I dati catastali sono dati pubblici. Il fatto che siano accessibili solo attraverso un portale privo di API è un limite dell'infrastruttura statale, non una ragione per creare nuovi intermediari. Se domani l'Agenzia delle Entrate esponesse un'API REST del catasto - come sarebbe auspicabile e come prima o poi avverrà - tutti i servizi di intermediazione a pagamento perderebbero ragion d'essere. E con loro, questo stesso progetto. Ma nel frattempo, il costo per accedere a dati pubblici non dovrebbe ricadere sulle spalle di chi li utilizza professionalmente.
C'è anche una ragione pratica. Il flusso di autenticazione SPID cambia da provider a provider, SISTER aggiorna l'interfaccia senza preavviso, i selettori CSS del portale si modificano. Un progetto di questo tipo ha bisogno di manutenzione distribuita. Se un utente opera con un provider SPID diverso e può contribuire l'adattamento, il codice aperto lo rende possibile. Se SISTER modifica un form, chi se ne accorge per primo può aprire una pull request. Il modello open source rende il progetto strutturalmente più resiliente.
Al momento il login automatizzato è compatibile con CIE Sign / Sielte ID. Altri provider SPID richiedono adattamenti specifici, dato che ciascuno ha una propria interfaccia di autenticazione - ed è esattamente il tipo di contributo che si inserisce naturalmente in un contesto open source.
Perché AGPL e non GPL
Una precisazione tecnica sulla licenza, perché è cambiata dalla prima versione del progetto: visura-api è passato da GPL-3.0 ad AGPL-3.0 per chiudere quella che nel mondo open source si chiama "SaaS loophole". La GPL classica obbliga a redistribuire il codice sorgente solo quando il software viene distribuito - ma se lo esegui su un server e lo esponi come servizio via rete, senza mai distribuire binari o codice, tecnicamente non sei obbligato a pubblicare nulla. L'AGPL chiude esplicitamente questa scappatoia (clausola §13, "Remote Network Interaction"): se metti online un servizio che usa visura-api anche solo modificato, devi rendere disponibile il codice sorgente completo della tua opera combinata a chiunque lo usi via rete.
È per questo che esiste anche una licenza commerciale separata, acquistabile da Zornade, per chi vuole integrare visura-api in un prodotto proprietario (SaaS a pagamento, piattaforma interna con CRM/ERP integrati, software on-premise closed-source) senza dover pubblicare il codice sorgente combinato. È lo stesso modello di dual-licensing adottato da progetti come MongoDB o Sentry: open source per l'uso diretto, licenza commerciale per chi vuole costruirci sopra un prodotto chiuso.
Per chi si limita a un uso personale, in locale, sui propri dati - il caso d'uso descritto in questo articolo - l'AGPL non comporta alcun obbligo aggiuntivo rispetto alla GPL: si applica solo a chi ridistribuisce o espone in rete una versione modificata del servizio.
I numeri del repository
Al momento della scrittura (dato rilevato il 6 luglio 2026), il repository conta 663 stelle e 83 fork su GitHub, con 14 issue aperte - numeri che per un tool verticale così specifico (automazione di un singolo portale della PA italiana) segnalano un uso reale e continuativo, non un esperimento abbandonato.
Prerequisito: attivare l'accesso a SISTER
Un passaggio spesso sottovalutato: prima di poter usare visura-api (o SISTER stesso) serve richiedere l'attivazione del servizio dall'Area Personale del sito dell'Agenzia delle Entrate, cercando "SISTER" tra i servizi disponibili. È un'operazione una tantum, gratuita, ma non immediata: senza quell'adesione preventiva nessuna automazione - per quanto ben scritta - può funzionare, perché l'accesso stesso al portale è negato a monte.
L'evoluzione recente: verso uno stack stateless
Il changelog del progetto racconta anche una scelta architetturale interessante per chi valuta di adottarlo: le versioni più recenti hanno rimosso completamente la dipendenza da PostgreSQL/SQLAlchemy, insieme al modulo database.py e agli endpoint che ne dipendevano (consultazione sezioni via database, statistiche aggregate). Il servizio oggi è interamente stateless: ogni richiesta vive di sé stessa, senza stato persistente lato server. Per chi deve orchestrare visura-api dentro un'infrastruttura containerizzata più ampia, significa un deploy più semplice (nessun database da gestire, backuppare, migrare) a fronte di una responsabilità in più lasciata al chiamante: la persistenza dei risultati, se serve, va gestita a valle.
Altre correzioni recenti riguardano la stabilità in ambiente Docker: la rimozione del flag Chromium --single-process (incompatibile con container, causava crash sporadici al re-init) e una gestione più tollerante della directory di logging delle pagine HTML, con un fallback automatico a /tmp se la directory di default non è scrivibile - un dettaglio che conta quando il servizio gira in container con filesystem in sola lettura.
Cosa non è
È opportuno essere espliciti su un punto: visura-api non è un prodotto dell'Agenzia delle Entrate, non è un servizio certificato, non ha alcun rapporto istituzionale con il catasto. È uno strumento che automatizza un'operazione altrimenti manuale, utilizzando le credenziali dell'utente. La responsabilità sul rispetto dei termini di servizio del portale SISTER resta interamente in capo a chi lo utilizza.
Non è nemmeno una soluzione "no-code": richiede familiarità con Docker, Python, un terminale. È pensato per sviluppatori e team tecnici che necessitano di integrare le visure nei propri flussi di lavoro. Per chi cerca un accesso più immediato ai dati catastali, senza installazioni, la piattaforma Zornade offre accesso gratuito a 85 milioni di particelle catastali arricchite - con interfaccia web, API REST e dataset scaricabili.
Il contesto più ampio
Il sistema catastale italiano necessita di una modernizzazione profonda - un tema discusso da anni nelle sedi istituzionali. Interoperabilità con i sistemi GIS, convergenza con l'anagrafe tributaria, catasto 3D, standard INSPIRE: tutti obiettivi condivisibili, tutti in uno stato di avanzamento che gli operatori del settore conoscono bene.
Nel frattempo, il mercato si è mosso autonomamente. Sono nate piattaforme PropTech che richiedono dati catastali strutturati per alimentare modelli di valutazione. Fondi immobiliari che intendono monitorare i portafogli senza affidarsi a processi manuali. Startup che costruiscono servizi sopra dati che lo Stato produce ma non rende facilmente accessibili in forma programmatica.
visura-api non è la soluzione a tutto questo. È uno strumento funzionale, open source, mantenuto - che affronta un problema specifico che andrebbe idealmente risolto a livello di infrastruttura pubblica. Ma finché quell'infrastruttura non arriva, il vuoto va colmato.
Il codice è disponibile su GitHub. Segnalazioni, contributi per altri provider SPID e pull request sono benvenuti. Per chi invece necessita di dati catastali pronti all'uso - con geometrie, indicatori territoriali, dati demografici - senza dover configurare uno stack Docker, è possibile registrarsi su app.zornade.com gratuitamente.
Domande frequenti
visura-api è gratuito?
Il codice è open source (AGPL-3.0), quindi liberamente scaricabile e utilizzabile. Devi però fornire le tue credenziali SPID e ospitare/eseguire il servizio tu stesso (o pagare una licenza commerciale se lo integri in un prodotto proprietario che espone il servizio via rete).
Che licenza ha visura-api, GPL o AGPL?
AGPL-3.0. Il progetto è passato da GPL a AGPL per chiudere la "SaaS loophole": con AGPL, chi espone il servizio via rete (anche modificato) deve pubblicare il codice sorgente completo dell'opera combinata.
Serve una licenza commerciale per usare visura-api?
Solo se lo integri in un prodotto proprietario chiuso (SaaS a pagamento, piattaforma interna con sistemi closed-source, software on-premise non open). Per uso personale o in locale sui propri dati, l'AGPL non richiede nulla di aggiuntivo.
Quali provider SPID sono supportati?
Al momento il login automatizzato è compatibile con CIE Sign e Sielte ID. Altri provider richiedono adattamenti specifici, essendo un tipo di contributo aperto alla community.
Devo registrarmi da qualche parte prima di usare visura-api?
Sì: devi prima richiedere l'attivazione del servizio SISTER dall'Area Personale del sito dell'Agenzia delle Entrate, cercando "SISTER" tra i servizi disponibili. È un'operazione gratuita e una tantum, ma obbligatoria prima di qualunque automazione.
visura-api è legale?
Utilizza le tue stesse credenziali SPID per automatizzare un'operazione che potresti fare manualmente. Non aggira sistemi di sicurezza, ma la responsabilità sul rispetto dei termini di servizio di SISTER resta interamente dell'utente: il progetto non è affiliato né approvato dall'Agenzia delle Entrate.
Quanto tempo impiega una richiesta di visura?
Tra 30 e 60 secondi per richiesta, tempo determinato dal portale SISTER stesso (non dall'applicazione), che accoda internamente le richieste per rispettare i limiti di frequenza del sistema.