TapHome
Zjišťujeme zájem Integrace

Access API: správa uživatelů, kódů a událostí dveří z jiného systému

Způsob, jak by rezervační, správcovské nebo personální systémy spravovaly uživatele TapHome, karty, PIN kódy a jejich platnost a přijímaly přístupové události hned, jak nastanou.

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.

Proč a jak byste to využili

TapHome už přístup spravuje: uživatele, karty, PIN kódy s dobou platnosti, týdenní plány a záznamy o přístupu. Vše se nastavuje ručně v aplikaci TapHome. Pro jeden rodinný dům to stačí. Prací navíc se to stává, když jiný systém už ví, kdo, kam a kdy má vstoupit.

Vezměte si penzion nebo několik apartmánů s rezervačním systémem. Při každé rezervaci musí někdo vytvořit PIN kód v TapHome, nastavit jeho data a vybrat dveře a týdenní plán, se kterými funguje. Kód po posledním dni přestane fungovat sám, ale nastavení je stále ruční a jeden překlep znamená hosta před zamčenými dveřmi.

Stejný vzor se objevuje ve fitness centru nebo coworkingu, který prodává členství a rezervace místností, ve správě budovy, která vede seznam nájemníků, nebo ve firmě, kde personální systém ví, kdo v ní pracuje. Ve všech případech pravdu drží jiný systém a TapHome ho potřebuje jen následovat.

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.

Typický pobyt: rezervace vytvoří kód na data pobytu, host ho zadá na čtečce, dveře se otevřou a událost jde hned zpět do rezervačního systému.

DnesS tímto nápadem
Kód pro hostaVytvořen v aplikaciVytvoří rezervační systém
Uživatelé a kartyZadané v aplikaciSynchronizované z jiného systému
Přístup k jedněm dveřímTýdenní plán v aplikaciNastaven pro rezervaci
Kdo vstoupilNačteno z exportuOdesláno hned

Formát dat ani podoba API nejsou rozhodnuty.

Co bude možné

Sbíráme požadavky. Nápad má dvě části a stále je otevřené, která je nejdůležitější. Nic níže není naplánováno.

  • Správa přístupu z jiného systému. Externí systém by v TapHome vytvářel, měnil a odstraňoval uživatele, karty, PIN kódy, jejich platnost a týdenní plány a omezil je na vybrané dveře. Například rezervační systém penzionu by dal hostovi kód na dny pobytu a systém fitness centra by pustil člena do rezervované místnosti jen v rezervovaném čase.
  • Přístupové události odcházejí hned. TapHome by jinému systému oznámil, kdo a kdy použil které dveře a zda byl přístup povolen nebo zamítnut, přesně ve chvíli, kdy se to stane. Události by měly vlastní doručování, které to zkusí znovu, když je druhý systém chvíli nedostupný, takže se událost neztratí. Mohlo by to napájet evidenci docházky nebo bezpečnostní dohled.

Co nebude možné

  • Certifikovaný zabezpečovací systém. API by z TapHome neudělalo certifikovaný zabezpečovací ani poplachový systém a nenahradilo by ho tam, kde ho vyžaduje zákon nebo pojišťovna.
  • Biometrické údaje v TapHome. TapHome by neukládal otisky prstů ani obličeje. Pokud čtečka osobu rozpozná sama, TapHome by dostal jen identitu, kterou čtečka pošle.
  • Vyšší bezpečnost jen díky kódu. Kód vytvořený jiným systémem je stále PIN kód, který dokumentace systému řízení přístupu hodnotí jako nejnižší úroveň zabezpečení. Pro stálé uživatele zůstávají lepší volbou karty.
  • Čtečky, se kterými TapHome neumí komunikovat. API by spravovalo přístup jen v TapHome, ne čtečky ani dveřní systémy, které TapHome nepodporuje.
  • Nic bez druhé strany. Externí systém musí API volat nebo události přijímat sám. TapHome by neobsahoval hotový konektor pro každý rezervační či personální produkt.

Jak to řešit dnes

  • Spravujte přístup ručně. Karty a PIN kódy, jejich platnost, dveře a týdenní plány, se kterými fungují, a záznamy o přístupu se spravují v aplikaci TapHome, viz Systém řízení přístupu. Karta nebo kód platí na celé dny a po posledním dni přestane fungovat sám. Funguje se čtečkami připojenými přes Wiegand Gateway.
  • Použijte přístupovou smart rule. Když je přístup povolen, spouštěč přístupu může impulzem otevřít dveře na omezenou dobu a jen pro vybrané karty může spustit další akce, viz Systém řízení přístupu.
  • Otevřete dveře z jiného systému. Vystavte výstup zámku a nastavte jeho hodnotu přes TapHome API, například abyste pustili kurýra. API nepokrývá uživatele přístupu, karty ani PIN kódy, takže na ty je stále potřeba aplikace.
  • Načtěte záznamy o přístupu. Automatický export záznamů o přístupu uvádí na pevné adrese, kdo, kdy, na které čtečce, zda byl přístup povolen nebo zamítnut a proč. K dispozici je i export docházky. Druhý systém si soubor stahuje průběžně, takže se o vstupu nedozví hned, a webhook TapHome API výsledky přístupu neposílá.
  • Chraňte síť. Lokální API a webhook používají nešifrované HTTP, proto na sdíleném místě, například v penzionu, mějte Core ve vlastním segmentu sítě, viz TapHome API.

Více informací

Kterou část byste použili nejdříve a jaký systém byste připojili? Hlasujte pro tento nápad, sledujte ho kvůli novinkám a vyplňte anketu níže.

K čemu byste použili Access API?

Živé výsledky · 0 lidí

Pro odpověď se přihlaste

Související

Historie stavu

  • 18. 10. 2026 Zjišťujeme zájem Zveřejněno

Komentáře 1

Zapojte se do diskuse

Pro komentování se přihlaste svým účtem TapHome. Tým TapHome komentáře před zveřejněním schvaluje.

Martin Kališ TapHome EN 1. 11. 2026

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.

Ideas ukazují směr, nikoli závazky. Termíny nezveřejňujeme; vydané funkce oznamujeme v release notes.