Access API: zarządzanie użytkownikami, kodami i zdarzeniami drzwi z innego systemu
Sposób, by systemy rezerwacji, zarządzania budynkiem lub kadrowe zarządzały użytkownikami TapHome, kartami, kodami PIN i ich ważnością oraz od razu odbierały zdarzenia dostępu.
Dlaczego i jak to wykorzystasz
TapHome już zarządza dostępem: użytkownikami, kartami, kodami PIN z okresem ważności, planami tygodniowymi i dziennikiem dostępu. Wszystko to ustawia się ręcznie w aplikacji TapHome. Dla jednego domu jednorodzinnego to wystarcza. Robi się uciążliwe, gdy inny system już wie, kto, gdzie i kiedy ma wejść.
Weź pensjonat albo kilka apartamentów wakacyjnych z systemem rezerwacji. Przy każdej rezerwacji ktoś musi utworzyć kod PIN w TapHome, ustawić jego daty i wybrać drzwi oraz plan tygodniowy, z którymi działa. Kod sam przestaje działać po ostatnim dniu, ale konfiguracja wciąż jest ręczna, a jedna literówka oznacza gościa przed zamkniętymi drzwiami.
Ten sam schemat pojawia się w siłowni lub coworkingu, który sprzedaje karnety i rezerwacje sal, w administracji budynku prowadzącej listę najemców albo w firmie, w której system kadrowy wie, kto w niej pracuje. W każdym przypadku prawdę zna inny system, a TapHome musi tylko za nim podążać.
Typowy pobyt: rezerwacja tworzy kod na daty pobytu, gość wpisuje go na czytniku, drzwi się otwierają, a zdarzenie od razu wraca do systemu rezerwacji.
| Dziś | Z tym pomysłem | |
|---|---|---|
| Kod dla gościa | Tworzony w aplikacji | Tworzy system rezerwacji |
| Użytkownicy i karty | Wpisywani w aplikacji | Synchronizowani z innego systemu |
| Dostęp do jednych drzwi | Plan tygodniowy w aplikacji | Ustawiany dla rezerwacji |
| Kto wszedł | Pobierane z eksportu | Wysyłane od razu |
Format danych i postać API nie są przesądzone.
Co będzie możliwe
Zbieramy wymagania. Pomysł ma dwie części i wciąż jest otwarte, która jest najważniejsza. Nic poniżej nie jest zaplanowane.
- Zarządzanie dostępem z innego systemu. System zewnętrzny tworzyłby, zmieniał i usuwał w TapHome użytkowników, karty, kody PIN, ich ważność i plany tygodniowe oraz ograniczał je do wybranych drzwi. Na przykład system rezerwacji pensjonatu dawałby gościowi kod na dni pobytu, a system siłowni wpuszczałby członka do zarezerwowanej sali tylko w zarezerwowanym czasie.
- Zdarzenia dostępu wysyłane od razu. TapHome informowałby inny system, kto i kiedy użył których drzwi oraz czy dostęp został przyznany czy odmówiony, dokładnie w chwili, gdy to się dzieje. Zdarzenia miałyby własne doręczanie, które ponawia próbę, gdy drugi system jest chwilowo niedostępny, więc żadne zdarzenie nie przepadnie. Mogłoby to zasilać ewidencję obecności lub monitoring bezpieczeństwa.
Co nie będzie możliwe
- Certyfikowany system zabezpieczeń. API nie zrobiłoby z TapHome certyfikowanego systemu zabezpieczeń ani alarmowego i nie zastąpiłoby go tam, gdzie wymaga tego prawo lub ubezpieczyciel.
- Dane biometryczne w TapHome. TapHome nie przechowywałby odcisków palców ani twarzy. Jeśli czytnik sam rozpoznaje osobę, TapHome dostawałby tylko tożsamość, którą wyśle czytnik.
- Większe bezpieczeństwo dzięki samemu kodowi. Kod utworzony przez inny system to wciąż kod PIN, który dokumentacja kontroli dostępu ocenia jako najniższy poziom zabezpieczeń. Dla stałych użytkowników lepszym wyborem pozostają karty.
- Czytniki, z którymi TapHome nie potrafi się komunikować. API zarządzałoby dostępem tylko w TapHome, a nie czytnikami czy systemami drzwi, których TapHome nie obsługuje.
- Nic bez drugiej strony. System zewnętrzny musi sam wywoływać API lub odbierać zdarzenia. TapHome nie zawierałby gotowego konektora dla każdego produktu rezerwacyjnego czy kadrowego.
Jak to rozwiązać dzisiaj
- Zarządzaj dostępem ręcznie. Karty i kody PIN, ich ważność, drzwi i plany tygodniowe, z którymi działają, oraz dziennik dostępu zarządza się w aplikacji TapHome, zobacz System kontroli dostępu. Karta lub kod są ważne przez całe dni i same przestają działać po ostatnim dniu. Działa to z czytnikami podłączonymi przez Wiegand Gateway.
- Użyj smart rule dostępu. Gdy dostęp zostanie przyznany, wyzwalacz dostępu może impulsem otworzyć drzwi na ograniczony czas i tylko dla wybranych kart uruchomić dodatkowe akcje, zobacz System kontroli dostępu.
- Otwórz drzwi z innego systemu. Udostępnij wyjście zamka i ustaw jego wartość przez TapHome API, na przykład by wpuścić kuriera. API nie obejmuje użytkowników dostępu, kart ani kodów PIN, więc do nich wciąż potrzebna jest aplikacja.
- Pobieraj dziennik dostępu. Automatyczny eksport dziennika dostępu podaje pod stałym adresem, kto, kiedy, na którym czytniku, czy dostęp został przyznany czy odmówiony i dlaczego. Dostępny jest też eksport obecności. Drugi system pobiera plik co jakiś czas, więc nie dowiaduje się o wejściu od razu, a webhook TapHome API nie wysyła wyników dostępu.
- Zadbaj o bezpieczeństwo sieci. Lokalne API i webhook używają nieszyfrowanego HTTP, więc w miejscu współdzielonym, takim jak pensjonat, trzymaj Core we własnym segmencie sieci, zobacz TapHome API.
Dowiedz się więcej
- Czytniki OSDP w TapHome, osobny pomysł dotyczący czytników z szyfrowaną, nadzorowaną komunikacją.
- Dokumentacja TapHome API i Automatyczne eksporty.
Której części użyłbyś najpierw i jaki system byś podłączył? Zagłosuj na ten pomysł, obserwuj go, by śledzić nowości, i odpowiedz na ankietę poniżej.
Której części Access API użyłbyś najpierw?
Powiązane
Historia statusu
- 18 paź 2026 Badanie zainteresowania Opublikowano
Komentarze 0
Zaloguj się na swoje konto TapHome, aby skomentować. Zespół zatwierdza komentarze przed ich wyświetleniem.
Jeszcze nie ma komentarzy.
·
Oryginalny komentarz został usunięty.
Pomysły wskazują kierunek rozwoju, nie zobowiązania. Nie publikujemy dat; wydane funkcje są ogłaszane w informacjach o wydaniu.
Zaloguj się na swoje konto TapHome, aby obserwować. Wyślemy Ci e-mail, gdy coś się zmieni; możesz wypisać się jednym kliknięciem.
Potwierdzanie głosu…