TapHome
Érdeklődés felmérése Integráció

Access API: felhasználók, kódok és ajtóesemények kezelése egy másik rendszerből

Lehetőség arra, hogy foglalási, épületkezelő vagy HR-rendszerek kezeljék a TapHome felhasználókat, kártyákat, PIN-kódokat és érvényességüket, és azonnal megkapják a belépési eseményeket.

A building, an attendance clock and a booking calendar connect through an API to TapHome access control: users, cards and codes go in, access events come out, and TapHome works with the reader and the door.
A building, an attendance clock and a booking calendar connect through an API to TapHome access control: users, cards and codes go in, access events come out, and TapHome works with the reader and the door.

Miért és hogyan használnád

A TapHome már kezeli a beléptetést: felhasználókat, kártyákat, érvényességi idővel rendelkező PIN-kódokat, heti terveket és belépési naplót. Mindezt kézzel kell beállítani a TapHome alkalmazásban. Egy családi háznál ez rendben van. Teherré válik, amikor egy másik rendszer már tudja, ki, hová és mikor léphet be.

Vegyünk egy panziót vagy több nyaralólakást foglalási rendszerrel. Minden foglaláshoz valakinek létre kell hoznia egy PIN-kódot a TapHome-ban, be kell állítania a dátumait, és ki kell választania az ajtókat és a heti tervet, amelyekkel működik. A kód az utolsó napja után magától megszűnik működni, de a beállítás továbbra is kézi, és egy elírás azt jelenti, hogy a vendég zárt ajtó előtt áll.

Ugyanez a minta jelenik meg egy edzőteremben vagy coworking irodában, amely tagságot és teremfoglalást árul, egy épületkezelőnél, amely bérlőlistát vezet, vagy egy cégnél, ahol a HR-rendszer tudja, ki dolgozik ott. Minden esetben a másik rendszer ismeri az igazságot, és a TapHome-nak csak követnie kell.

A booking creates a code through the API, the guest enters it at the reader, the door opens, and the access event goes back to the booking system through the API.
A booking creates a code through the API, the guest enters it at the reader, the door opens, and the access event goes back to the booking system through the API.

Egy tipikus tartózkodás: a foglalás kódot hoz létre a foglalás napjaira, a vendég beüti az olvasón, az ajtó kinyílik, és az esemény azonnal visszamegy a foglalási rendszerbe.

MaEzzel az ötlettel
VendégkódAz alkalmazásban létrehozvaA foglalási rendszer hozza létre
Felhasználók és kártyákAz alkalmazásban megadvaMásik rendszerből szinkronizálva
Hozzáférés egy ajtóhozHeti terv az alkalmazásbanFoglalásonként beállítva
Ki lépett beExportból lekérveAzonnal elküldve

Az adatformátum és az API formája nincs eldöntve.

Mi lesz lehetséges

Követelményeket gyűjtünk. Az ötletnek két része van, és még nyitott, melyik a fontosabb. Az alábbiak közül semmi sincs ütemezve.

  • Beléptetés kezelése egy másik rendszerből. Egy külső rendszer létrehozná, módosítaná és törölné a TapHome-ban a felhasználókat, kártyákat, PIN-kódokat, érvényességüket és a heti terveket, és a kiválasztott ajtókra korlátozná őket. Például egy panzió foglalási rendszere kódot adna a vendégnek a tartózkodás napjaira, egy edzőterem rendszere pedig csak a foglalt időben engedné be a tagot a foglalt terembe.
  • A belépési események azonnal kimennek. A TapHome közölné egy másik rendszerrel, ki és mikor használta melyik ajtót, és hogy a belépést engedélyezték vagy elutasították, pontosan abban a pillanatban, amikor megtörténik. Az eseményeknek saját kézbesítésük lenne, amely újrapróbálkozik, ha a másik rendszer rövid ideig nem érhető el, így egy esemény sem vész el. Ez táplálhatna jelenléti nyilvántartást vagy biztonsági felügyeletet.

Mi nem lesz lehetséges

  • Tanúsított biztonsági rendszer. Az API nem tenné a TapHome-ot tanúsított biztonsági vagy riasztórendszerré, és nem helyettesítene ilyet ott, ahol törvény vagy biztosító megköveteli.
  • Biometrikus adatok a TapHome-ban. A TapHome nem tárolna ujjlenyomatokat vagy arcokat. Ha egy olvasó maga ismeri fel a személyt, a TapHome csak az olvasó által küldött azonosítót kapná meg.
  • Nagyobb biztonság pusztán egy kódtól. Egy másik rendszer által létrehozott kód továbbra is PIN-kód, amelyet a beléptetőrendszer dokumentációja a legalacsonyabb biztonsági szintnek tekint. Állandó felhasználóknak a kártya marad a jobb választás.
  • Olvasók, amelyekkel a TapHome nem tud kommunikálni. Az API csak a TapHome-on belüli beléptetést kezelné, nem azokat az olvasókat vagy ajtórendszereket, amelyeket a TapHome nem támogat.
  • Semmi a másik fél nélkül. A külső rendszernek magának kell hívnia az API-t vagy fogadnia az eseményeket. A TapHome nem tartalmazna kész csatlakozót minden foglalási vagy HR-termékhez.

Hogyan oldható meg ma

  • Kezeld a beléptetést kézzel. A kártyákat és PIN-kódokat, érvényességüket, az ajtókat és heti terveket, amelyekkel működnek, valamint a belépési naplót a TapHome alkalmazásban kezeled, lásd Hozzáférés-ellenőrző rendszer. Egy kártya vagy kód egész napokra érvényes, és az utolsó napja után magától megszűnik működni. A Wiegand Gateway eszközön át csatlakoztatott olvasókkal működik.
  • Használd a beléptető smart rule-t. Engedélyezett belépéskor a belépési indító esemény impulzussal korlátozott időre kinyithat egy ajtót, és csak a kiválasztott kártyáknál futtathat további műveleteket, lásd Hozzáférés-ellenőrző rendszer.
  • Nyiss ajtót egy másik rendszerből. Oszd meg a zár kimenetét, és állítsd be az értékét a TapHome API segítségével, például hogy beengedj egy futárt. Az API nem kezeli a beléptetés felhasználóit, kártyáit és PIN-kódjait, ezekhez továbbra is az alkalmazás kell.
  • Kérd le a belépési naplót. A belépési napló automatikus exportja egy állandó címen sorolja fel, ki, mikor, melyik olvasónál lépett be, a belépést engedélyezték vagy elutasították, és miért. Jelenléti export is elérhető. A másik rendszer időnként letölti a fájlt, így egy belépésről nem azonnal értesül, és a TapHome API webhookja nem küld belépési eredményeket.
  • Védd a hálózatot. A helyi API és a webhook titkosítatlan HTTP-t használ, ezért közös helyen, például egy panzióban, tartsd a Core-t saját hálózati szegmensben, lásd TapHome API.

Tudj meg többet

Melyik részt használnád először, és melyik rendszert csatlakoztatnád? Szavazz erre az ötletre, kövesd a frissítésekért, és válaszolj az alábbi kérdőívre.

Mire használnád az Access API-t?

Élő eredmények · 0 fő

Jelentkezz be a válaszadáshoz

Kapcsolódó

OSDP olvasók: titkosított, felügyelt beléptetés RS-485-önÉrdeklődés felmérése

Állapottörténet

  • 2026. okt. 18. Érdeklődés felmérése Közzétéve

Hozzászólások 1

Csatlakozz a beszélgetéshez

Jelentkezz be a TapHome-fiókoddal a hozzászóláshoz. A csapat jóváhagyja a hozzászólásokat, mielőtt megjelennének.

Bejelentkezés Ingyenes fiók létrehozása
Martin Kališ TapHome EN 2026. nov. 1.

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.

Az ötletek irányvonalakat írnak le, nem kötelezettségvállalásokat. Nem teszünk közzé dátumokat; a kiadott funkciókat a kiadási megjegyzésekben jelentjük be.