Der manuelle Workflow — und was daran kaputt ist
Die traditionelle Art, eine Zutrittskarte mit einem Zebra ZC350 und 2N Access Commander auszugeben, ist eine Folge von Einzelschritten, oft verteilt auf zwei Personen und drei Bildschirme:
- Rezeptionist öffnet das Drucker-Tool (CardStudio) auf einer Windows-Arbeitsstation mit USB-Kabel zum ZC350.
- Rezeptionist tippt Name und Gültigkeit ein, klickt auf Drucken.
- Die Karte kommt aus dem Drucker; der Rezeptionist legt sie auf ein separates NFC-Lesegerät.
- Der NFC-Reader zeigt die UID; der Rezeptionist tippt sie ab.
- IT-Mitarbeiter (oder Rezeptionist mit Admin-Rechten) öffnet 2N Access Commander im Browser.
- Die UID wird einem Benutzerdatensatz zugeordnet; Berechtigungen werden konfiguriert.
- Erst dann kann der Benutzer tatsächlich die Tür öffnen.
Insgesamt: 6 bis 8 Handlungen, zwei Tools, zwei Personen und eine UID, die manuell übertragen wird — mit entsprechender Fehlerquote. Für ein Hotel mit 200 Buchungen pro Monat, ein Corporate mit täglichem Onboarding oder ein Casino mit Besucherpässen: ein operativer Engpass.
Was ConoCard hier verändert
ConoCard verwandelt diese 6-8 Schritte in einen authentifizierten HTTP-Aufruf. POST /api/issue erledigt alles, was vorher manuell passierte — serverseitig, gemessen in Sekunden.
Der End-to-End-Flow
POST /api/issue mit Bearer-Token und den Karten-/Gastdaten.Insgesamt: ein HTTP-Aufruf. Innerhalb von Sekunden hat der Benutzer Zugang und der Audit-Trail ist vollständig. Kein manuelles UID-Abtippen, kein sequenzielles Tool-Wechseln.
UID-Lifecycle im 2N Access Commander
ConoCard schreibt nicht nur "eine UID" in 2N — es verwaltet den gesamten Lifecycle:
- Ausgabe: neue Karte wird einem Benutzer mit dem angegebenen Gültigkeitszeitraum und Berechtigungen zugeordnet.
- Verlängerung: bestehende Karte kann über einen zweiten API-Aufruf aufgefrischt werden, ohne eine neue Karte zu drucken.
- Widerruf: ein separater Endpoint (auf der Roadmap für v1.x) widerruft die UID in 2N und fügt einen Logeintrag hinzu.
- Audit-Log: jedes Ereignis (Ausgabe, Verlängerung, Fehler, Widerruf) landet im JSON-Lines-Log mit UID, Timestamp und Quelle — direkt von Ihrem SIEM für Compliance-Reporting einlesbar.
In der Praxis: drei Use-Cases
Hotel & Ferienvermietung
Eine neue Buchung im PMS (z.B. Lodgify oder Smoobu) triggert über Webhook einen POST /api/issue-Aufruf. Innerhalb von Sekunden kommt die Karte aus dem Drucker im Technikraum, mit der UID bereits im 2N registriert. Gast holt sie an einem Schlüsselkasten oder Front-Desk-losen Pickup ab. Keine Rezeption, kein UID-Abtippen.
Corporate IT & Besucher-Management
Ein Besucher-Management-System schickt bei jeder vorangekündigten Visite einen API-Aufruf an ConoCard. Der Rezeptionist muss nur die Karte überreichen — alles vom Druck bis zur 2N-Registrierung erfolgt serverseitig. Audit-Trail an SIEM für Compliance-Reporting. Bereitstellung für 100 Mitarbeiter in 1 Stunde statt einem Tag.
Casinos & Members-only
Member-Cards und Mitarbeiterausweise über mehrere Standorte, mit zentralem Management und konsistentem Design. Eine ConoCard-Instanz pro Standort, oder eine zentrale Instanz mit VPN. Alle Ausgaben landen im 2N Access Commander und im Audit-Log — was bei Compliance-Audits den Unterschied macht.
Integrator-Deployment & 2N-Partner
Als 2N-Partner können Sie ConoCard als Add-on zu Access Commander-Installationen anbieten, bei denen physische Karten benötigt werden. Eine Linux-Box beim Kunden, angeschlossen an deren bestehende ZC350-Flotte. Multi-Tenant-deploybar für Sie als Integrator.
Für 2N-Partner: ConoCard ist als Kartenausgabe-Schicht neben Access Commander gedacht. Wir sehen das als natürliche Erweiterung des 2N-Stacks — ähnlich wie IP Verso / IP Force die Interaktionsseite abdecken. Nehmen Sie Kontakt auf für Partnership-Möglichkeiten.
Was Sie zum Starten brauchen
- Zebra ZC350 mit Netzwerk-Option (Silex SX-200-Chip an Bord — Standard bei Netzwerk-Modellen)
- 2N Access Commander über REST API innerhalb Ihres Netzwerks erreichbar
- Eine Linux-VM, ein Windows-Server oder ein Raspberry Pi, um das ConoCard-Binary zu betreiben
- Bearer-Token für die ConoCard-API (selbst zu konfigurieren)
- API-Credentials für Ihren 2N Access Commander
Kein Hersteller-Treiberstack, keine CardStudio-Lizenzen, keine Arbeitsstation-Installationen. Ein typisches Initial-Setup ist in einem halben Arbeitstag einsatzbereit.
Häufig gestellte Fragen
Welche Version von 2N Access Commander wird unterstützt?
Die aktuelle stabile Version von 2N Access Commander wird über die offizielle REST API unterstützt. Für spezifische Versionsfragen oder Legacy-Deployments: melden Sie sich, wir testen auf Anfrage.
Brauche ich eine Conocido-Cloud?
Nein. ConoCard läuft vollständig innerhalb Ihres eigenen Netzwerks. Der Dienst spricht lokal mit dem ZC350 über IP und mit Ihrem 2N Access Commander REST-Endpoint. Kein externer Cloud-Zwischenlayer, keine Daten verlassen Ihr Netzwerk.
Was passiert, wenn 2N Access Commander offline ist?
Die ZC350-Ausgabe erfolgt trotzdem, und die ausgegebene UID wird im Audit-Log erfasst. Die 2N-Registrierung wird erneut versucht, sobald Access Commander wieder erreichbar ist, oder Sie erhalten einen strukturierten Fehler zurück und können den Flow selbst behandeln.
Kann ich auch andere Zutrittskontrollsysteme anbinden?
Ja. Neben 2N Access Commander end-to-end gibt es einen generischen Webhook-Output hinter derselben Integrationsschicht. Damit können Sie Salto, Dormakaba, HID, Nedap oder eigene Tools parallel zu 2N speisen.
Funktioniert es mit IP Verso, IP Force oder IP Style?
Das sind physische Entry-Units und betreffen das Karten-Drucken selbst nicht, aber wohl den Zutrittsfluss. Über 2N Access Commander kennen sie die Karte, die ConoCard registriert — keine separate Anbindung pro Entry-Unit nötig.
Kann das von der Access-Commander-Box selbst gestartet werden?
Ja. Wenn Ihre 2N-Installation eine eigene UI-Schicht (oder eine Companion-App) hat, kann diese die ConoCard REST API direkt aufrufen. So initiieren Sie eine neue Karte von jedem Standort, an dem eine 2N-Unit steht.