Access API: manage users, codes and door events from another system
A way for booking, building or HR systems to manage TapHome users, cards, PIN codes and their validity, and to receive access events as they happen.
Why and how you would use it
TapHome already manages access: users, cards, PIN codes with a validity period, weekly plans and an access log. All of it is set up by hand in the TapHome app. That is fine for one family house. It becomes a chore when another system already knows who should get in, where and when.
Take a guesthouse or a set of holiday apartments with a booking system. For every booking someone has to create a PIN code in TapHome, set its dates and choose the doors and the weekly plan it works with. The code stops working on its own after its last day, but the setup is still manual, and one typo means a guest standing in front of a locked door.
The same pattern appears in a gym or a coworking space that sells memberships and room bookings, in a building administration that keeps a list of tenants, or in a company where the HR system knows who works there. In each case the other system holds the truth and TapHome only needs to follow it.
A typical stay: the booking creates a code for the dates of the reservation, the guest enters it at the reader, the door opens, and the event goes straight back to the booking system.
| Today | With this idea | |
|---|---|---|
| Guest code | Created in app | Created by booking system |
| Users and cards | Entered in app | Synced from another system |
| Access to one door | Weekly plan in app | Set per booking |
| Who entered | Fetched from an export | Sent at once |
The data format and the form of the API are not decided.
What will be possible
We are collecting requirements. The idea has two parts, and it is still open which one matters most. Nothing below is scheduled.
- Access management from another system. An outside system would create, change and remove users, cards, PIN codes, their validity and weekly plans in TapHome, and limit them to chosen doors. For example, a guesthouse booking system would give a guest a code for the dates of the stay, and a gym system would let a member into the booked room only during the booked time.
- Access events going out at once. TapHome would tell another system who used which door and when, and whether access was granted or denied, right when it happens. The events would have their own delivery that tries again when the other system is briefly unreachable, so an event is not lost. This could feed attendance records or security monitoring.
What will not be possible
- A certified security system. The API would not turn TapHome into a certified security or alarm system, and it would not replace one where a law or an insurer asks for it.
- Biometric data in TapHome. TapHome would not store fingerprints or faces. If a reader recognises a person itself, TapHome would only get the identity the reader sends.
- Stronger security from a code alone. A code created by another system is still a PIN code, which the access control documentation rates as the lowest level of security. For permanent users, cards remain the better choice.
- Readers TapHome cannot talk to. The API would manage access in TapHome only, not readers or door systems that TapHome does not support.
- Anything without the other side. The outside system must call the API or receive the events itself. TapHome would not contain a ready-made connector for every booking or HR product.
How to solve it today
- Manage access by hand. Cards and PIN codes, their validity, the doors and weekly plans they work with and the access log are managed in the TapHome app, see Access control. A card or a code is valid for whole days and stops working on its own after its last day. It works with readers connected through the Wiegand Gateway.
- Use the access smart rule. When access is granted, the access trigger can open a door for a limited time with an impulse, and it can run extra actions only for chosen cards, see Access control.
- Open a door from another system. Expose the lock output and set its value through the TapHome API, for example to let a courier in. The API does not cover access users, cards or PIN codes, so those still need the app.
- Fetch the access log. An automated export of the access log lists who, when, at which reader, whether access was granted or denied and why, at a fixed address. An attendance export is available too. The other system fetches the file from time to time, so it does not learn about an entry at once, and the TapHome API webhook does not send access results.
- Keep the network safe. The local API and the webhook use plain HTTP, so on a shared site such as a guesthouse keep the Core on its own network segment, see TapHome API.
Learn more
- OSDP card readers in TapHome, a separate idea about readers with encrypted, supervised communication.
- TapHome API and Automated exports documentation.
Which part would you use first, and which system would you connect: vote for this idea, follow it for updates and answer the poll below.
Which part of an Access API would you use first?
Related
Status history
- Oct 18, 2026 Gathering interest Published
Comments 0
Sign in with your TapHome account to comment. The team approves comments before they appear.
No comments yet.
·
The original comment was deleted.
Ideas describe direction, not commitments. We do not publish dates; released features are announced in the release notes.
Sign in with your TapHome account to follow. We email you when something changes; unsubscribe in one click.
Confirming your vote…