Access API: Benutzer, Codes und Türereignisse aus einem anderen System verwalten
Eine Möglichkeit für Buchungs-, Gebäude- oder Personalsysteme, TapHome-Benutzer, Karten, PIN-Codes und deren Gültigkeit zu verwalten und Zugangsereignisse sofort zu empfangen.
Warum und wofür Sie es nutzen würden
TapHome verwaltet den Zugang bereits: Benutzer, Karten, PIN-Codes mit Gültigkeitsdauer, Wochenpläne und ein Zugangsprotokoll. All das wird von Hand in der TapHome-App eingerichtet. Für ein Einfamilienhaus reicht das. Mühsam wird es, wenn ein anderes System schon weiß, wer wann wo hinein darf.
Nehmen Sie eine Pension oder mehrere Ferienwohnungen mit einem Buchungssystem. Für jede Buchung muss jemand in TapHome einen PIN-Code anlegen, seine Daten einstellen und die Türen und den Wochenplan wählen, mit denen er gilt. Der Code hört nach seinem letzten Tag von selbst auf zu funktionieren, aber die Einrichtung bleibt Handarbeit, und ein Tippfehler bedeutet einen Gast vor verschlossener Tür.
Dasselbe Muster gibt es in einem Fitnessstudio oder Coworking-Space, der Mitgliedschaften und Raumbuchungen verkauft, in einer Hausverwaltung mit einer Mieterliste oder in einer Firma, deren Personalsystem weiß, wer dort arbeitet. In jedem Fall hält das andere System die Wahrheit, und TapHome muss ihm nur folgen.
Ein typischer Aufenthalt: Die Buchung erstellt einen Code für die Daten der Reservierung, der Gast gibt ihn am Leser ein, die Tür öffnet sich, und das Ereignis geht direkt zurück an das Buchungssystem.
| Heute | Mit dieser Idee | |
|---|---|---|
| Gastcode | In der App angelegt | Vom Buchungssystem angelegt |
| Benutzer und Karten | In der App eingegeben | Aus anderem System synchronisiert |
| Zugang zu einer Tür | Wochenplan in der App | Je Buchung festgelegt |
| Wer eingetreten ist | Aus einem Export geholt | Sofort gesendet |
Datenformat und Form der API sind nicht entschieden.
Was möglich sein wird
Wir sammeln Anforderungen. Die Idee hat zwei Teile, und es ist noch offen, welcher wichtiger ist. Nichts unten ist eingeplant.
- Zugangsverwaltung aus einem anderen System. Ein externes System würde in TapHome Benutzer, Karten, PIN-Codes, deren Gültigkeit und Wochenpläne anlegen, ändern und entfernen und sie auf gewählte Türen beschränken. Zum Beispiel würde das Buchungssystem einer Pension einem Gast einen Code für die Tage des Aufenthalts geben, und das System eines Fitnessstudios würde ein Mitglied nur zur gebuchten Zeit in den gebuchten Raum lassen.
- Zugangsereignisse gehen sofort hinaus. TapHome würde einem anderen System mitteilen, wer wann welche Tür benutzt hat und ob der Zugang gewährt oder abgelehnt wurde, genau in dem Moment, in dem es geschieht. Die Ereignisse hätten eine eigene Zustellung, die es erneut versucht, wenn das andere System kurz nicht erreichbar ist, damit kein Ereignis verloren geht. Das könnte eine Zeiterfassung oder eine Sicherheitsüberwachung speisen.
Was nicht möglich sein wird
- Ein zertifiziertes Sicherheitssystem. Die API würde TapHome nicht zu einem zertifizierten Sicherheits- oder Alarmsystem machen und keines ersetzen, wo ein Gesetz oder ein Versicherer es verlangt.
- Biometrische Daten in TapHome. TapHome würde keine Fingerabdrücke oder Gesichter speichern. Wenn ein Leser eine Person selbst erkennt, erhielte TapHome nur die Identität, die der Leser sendet.
- Mehr Sicherheit allein durch einen Code. Ein von einem anderen System erstellter Code bleibt ein PIN-Code, den die Dokumentation der Zugangskontrolle als niedrigste Sicherheitsstufe einstuft. Für ständige Benutzer bleiben Karten die bessere Wahl.
- Leser, mit denen TapHome nicht kommunizieren kann. Die API würde nur den Zugang in TapHome verwalten, nicht Leser oder Türsysteme, die TapHome nicht unterstützt.
- Nichts ohne die andere Seite. Das externe System muss die API selbst aufrufen oder die Ereignisse selbst empfangen. TapHome würde keinen fertigen Konnektor für jedes Buchungs- oder Personalprodukt enthalten.
Wie man es heute löst
- Zugang von Hand verwalten. Karten und PIN-Codes, ihre Gültigkeit, die Türen und Wochenpläne, mit denen sie gelten, und das Zugangsprotokoll werden in der TapHome-App verwaltet, siehe Zugangskontrollsystem. Eine Karte oder ein Code gilt für ganze Tage und hört nach dem letzten Tag von selbst auf zu funktionieren. Das funktioniert mit Lesern, die über das Wiegand Gateway angeschlossen sind.
- Die smart rule für den Zugang nutzen. Wenn der Zugang gewährt wird, kann der Zugangsauslöser eine Tür mit einem Impuls für begrenzte Zeit öffnen und nur für gewählte Karten zusätzliche Aktionen ausführen, siehe Zugangskontrollsystem.
- Eine Tür aus einem anderen System öffnen. Geben Sie den Ausgang des Schlosses frei und setzen Sie seinen Wert über die TapHome API, zum Beispiel um einen Kurier hereinzulassen. Die API deckt Zugangsbenutzer, Karten und PIN-Codes nicht ab, dafür braucht es weiterhin die App.
- Das Zugangsprotokoll abrufen. Ein automatischer Export des Zugangsprotokolls listet unter einer festen Adresse auf, wer wann an welchem Leser war, ob der Zugang gewährt oder abgelehnt wurde und warum. Ein Anwesenheitsexport ist ebenfalls verfügbar. Das andere System holt die Datei von Zeit zu Zeit ab, erfährt von einem Eintritt also nicht sofort, und der Webhook der TapHome API sendet keine Zugangsergebnisse.
- Das Netzwerk schützen. Die lokale API und der Webhook nutzen unverschlüsseltes HTTP, halten Sie den Core an einem gemeinsam genutzten Ort wie einer Pension daher in einem eigenen Netzwerksegment, siehe TapHome API.
Mehr erfahren
- OSDP-Leser in TapHome, eine eigene Idee zu Lesern mit verschlüsselter, überwachter Kommunikation.
- Dokumentation zu TapHome API und Automatische Exporte.
Welchen Teil würden Sie zuerst nutzen, und welches System würden Sie anbinden? Stimmen Sie für diese Idee ab, folgen Sie ihr für Neuigkeiten und beantworten Sie die Umfrage unten.
Wofür würden Sie eine Access API nutzen?
Verwandt
Statusverlauf
- 18.10.2026 Interesse wird gesammelt Veröffentlicht
Kommentare 1
Melden Sie sich mit Ihrem TapHome-Konto an, um zu kommentieren. Das Team gibt Kommentare frei, bevor sie erscheinen.
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.
·
Noch keine Kommentare.
·
Der ursprüngliche Kommentar wurde gelöscht.
Ideen zeigen die Richtung, keine Zusagen. Wir nennen keine Termine; veröffentlichte Funktionen kündigen wir in den Release Notes an.
Melden Sie sich mit Ihrem TapHome-Konto an, um zu folgen. Bei Änderungen senden wir Ihnen eine E-Mail; abmelden mit einem Klick.
Ihre Stimme wird bestätigt...