Access API: gestire utenti, codici ed eventi delle porte da un altro sistema
Un modo per i sistemi di prenotazione, di gestione dell’edificio o del personale di gestire utenti TapHome, carte, codici PIN e la loro validità, e di ricevere gli eventi di accesso nel momento in cui avvengono.
Perché e come lo useresti
TapHome gestisce già gli accessi: utenti, carte, codici PIN con periodo di validità, piani settimanali e un registro degli accessi. Tutto si configura a mano nell’app TapHome. Per una casa unifamiliare va bene. Diventa un peso quando un altro sistema sa già chi deve entrare, dove e quando.
Prendi una pensione o un gruppo di appartamenti per vacanze con un sistema di prenotazione. Per ogni prenotazione qualcuno deve creare un codice PIN in TapHome, impostarne le date e scegliere le porte e il piano settimanale con cui funziona. Il codice smette di funzionare da solo dopo l’ultimo giorno, ma la configurazione resta manuale, e un errore di battitura significa un ospite davanti a una porta chiusa.
Lo stesso schema si ritrova in una palestra o in uno spazio di coworking che vende abbonamenti e prenotazioni di sale, in un’amministrazione condominiale che tiene l’elenco degli inquilini o in un’azienda in cui il sistema del personale sa chi ci lavora. In ogni caso è l’altro sistema a conoscere la verità e TapHome deve solo seguirlo.
Un soggiorno tipico: la prenotazione crea un codice per le date della prenotazione, l’ospite lo digita sul lettore, la porta si apre e l’evento torna subito al sistema di prenotazione.
| Oggi | Con questa idea | |
|---|---|---|
| Codice ospite | Creato nell’app | Creato dal sistema di prenotazione |
| Utenti e carte | Inseriti nell’app | Sincronizzati da un altro sistema |
| Accesso a una porta | Piano settimanale nell’app | Impostato per prenotazione |
| Chi è entrato | Preso da un’esportazione | Inviato subito |
Il formato dei dati e la forma dell’API non sono decisi.
Cosa sarà possibile
Stiamo raccogliendo requisiti. L’idea ha due parti ed è ancora aperto quale conti di più. Nulla di quanto segue è in programma.
- Gestione degli accessi da un altro sistema. Un sistema esterno creerebbe, modificherebbe e rimuoverebbe in TapHome utenti, carte, codici PIN, la loro validità e i piani settimanali, limitandoli alle porte scelte. Per esempio, il sistema di prenotazione di una pensione darebbe all’ospite un codice per i giorni del soggiorno, e il sistema di una palestra farebbe entrare un socio nella sala prenotata solo nell’orario prenotato.
- Eventi di accesso inviati subito. TapHome comunicherebbe a un altro sistema chi ha usato quale porta e quando, e se l’accesso è stato concesso o negato, proprio nel momento in cui succede. Gli eventi avrebbero una consegna propria che riprova quando l’altro sistema è brevemente irraggiungibile, così nessun evento va perso. Potrebbe alimentare la rilevazione presenze o il monitoraggio di sicurezza.
Cosa non sarà possibile
- Un sistema di sicurezza certificato. L’API non trasformerebbe TapHome in un sistema di sicurezza o di allarme certificato, né lo sostituirebbe dove una legge o un assicuratore lo richiede.
- Dati biometrici in TapHome. TapHome non memorizzerebbe impronte digitali né volti. Se un lettore riconosce da sé una persona, TapHome riceverebbe solo l’identità inviata dal lettore.
- Più sicurezza grazie al solo codice. Un codice creato da un altro sistema resta un codice PIN, che la documentazione del controllo accessi classifica come il livello di sicurezza più basso. Per gli utenti fissi le carte restano la scelta migliore.
- Lettori con cui TapHome non sa comunicare. L’API gestirebbe gli accessi solo in TapHome, non i lettori o i sistemi porta che TapHome non supporta.
- Niente senza l’altra parte. Il sistema esterno deve chiamare l’API o ricevere gli eventi da sé. TapHome non conterrebbe un connettore pronto per ogni prodotto di prenotazione o di gestione del personale.
Come risolverlo oggi
- Gestisci gli accessi a mano. Carte e codici PIN, la loro validità, le porte e i piani settimanali con cui funzionano e il registro degli accessi si gestiscono nell’app TapHome, vedi Sistema di controllo degli accessi. Una carta o un codice vale per giorni interi e smette di funzionare da solo dopo l’ultimo giorno. Funziona con i lettori collegati tramite il Wiegand Gateway.
- Usa la smart rule di accesso. Quando l’accesso è concesso, il trigger di accesso può aprire una porta per un tempo limitato con un impulso e può eseguire azioni aggiuntive solo per le carte scelte, vedi Sistema di controllo degli accessi.
- Apri una porta da un altro sistema. Esponi l’uscita della serratura e impostane il valore tramite la TapHome API, per esempio per far entrare un corriere. L’API non copre utenti di accesso, carte o codici PIN, quindi per quelli serve ancora l’app.
- Scarica il registro degli accessi. Un’esportazione automatica del registro degli accessi elenca a un indirizzo fisso chi, quando, a quale lettore, se l’accesso è stato concesso o negato e perché. È disponibile anche un’esportazione delle presenze. L’altro sistema scarica il file di tanto in tanto, quindi non viene a sapere subito di un ingresso, e il webhook della TapHome API non invia i risultati degli accessi.
- Proteggi la rete. L’API locale e il webhook usano HTTP non cifrato, quindi in un luogo condiviso come una pensione tieni il Core in un suo segmento di rete, vedi TapHome API.
Per saperne di più
- Lettori OSDP in TapHome, un’idea separata sui lettori con comunicazione cifrata e supervisionata.
- Documentazione di TapHome API ed Esportazioni automatiche.
Quale parte useresti per prima e quale sistema collegheresti? Vota questa idea, seguila per gli aggiornamenti e rispondi al sondaggio qui sotto.
Correlati
Cronologia dello stato
- 18 ott 2026 Raccolta interesse Pubblicato
Commenti 1
Accedi con il tuo account TapHome per commentare. Il team approva i commenti prima che vengano pubblicati.
What a gym or studio renting rooms through Glofox would need Example: a trainer books Room 07 in Glofox for 10:00–11:00. TapHome can already prepare the room from the booking: heating or cooling from 9:30, lights and music at 9:55, everything off after 11:00 (there is a community template for it). What is missing is the door: let the trainer into Room 07 from 9:45 to 11:00, nowhere else and at no other time, and report the entry back to Glofox. Glofox decides access only for a whole location (an active membership, or a booking within the next hour). It does not know which door belongs to which room, so the decision "may this person enter Room 07 now" has to be made by TapHome. What would make it possible, most important first: 1. Cards and PIN codes managed from outside. Another system creates, changes, disables and removes a card or PIN code: at least the code, a name, on/off and valid from–to. 2. Validity in minutes, not whole days. A booking is 10:00–11:00, often with "let them in 15 minutes early". 3. A card limited to chosen doors and a time window directly, without a weekly plan prepared by hand in the app. Or at least weekly plans that can be created and assigned from outside. 4. An external ID on the card, such as the member ID in the booking system, so an access event can say whose card it was. 5. The card code and the access decision readable in a script every time a card is presented, an unknown card too. A script could then check the code against the booking system right at the door, with no card syncing at all. 6. Access events sent out with retries: who, when, which door, granted or denied and why. When the other system is briefly unreachable, the event is not lost, and the booking system can record attendance from it. 7. Volume without disruption: around 20 doors, dozens of trainers and hundreds of changes a week, and no change should need a restart of the control unit. 8. Safe writes: which key or script may change cards, a record of who changed what, and an encrypted connection. Two ways it could work: - Sync: the booking system regularly writes cards and their validity into TapHome (points 1–4). Doors keep working during an internet outage, based on the last sync. - Check at the door: when a card is presented, TapHome asks the booking system and opens (point 5). Always up to date, but without internet nobody gets in. Access events going out (point 6) are needed either way. The same base would serve a guesthouse with a booking system or a coworking space.
·
Ancora nessun commento.
·
Il commento originale è stato eliminato.
Le idee descrivono la direzione, non sono impegni. Non pubblichiamo date; le funzionalità rilasciate vengono annunciate nelle note di rilascio.
Accedi con il tuo account TapHome per seguirla. Ti invieremo un'email quando cambia qualcosa; puoi annullare l'iscrizione con un clic.
Conferma del voto in corso…