ConoCard
Netzwerk-native Kartenausgabe für die Zebra ZC350 — treiberlos, inklusive kontaktloser UID-Auslesung, ein Server für mehrere Drucker, jedes OS.
Was ist ConoCard?
ConoCard löst ein ganz spezifisches hartes Problem: die treiberlose Ansteuerung der Zebra ZC350 über das Netzwerk, von jedem OS aus — inklusive kontaktloser UID-Auslesung in derselben Session. Genau dort, wo Zebras Standard-Stack Sie zu einer Windows-Arbeitsstation pro Drucker und einem USB-Kabel zwingt und wo Alternativen wie Silex SX Virtual Link Hersteller-spezifische Treiber-Installationen pro Maschine verlangen.
Eine Ausgabe läuft als End-to-End-Flow in einem REST-Aufruf: POST /api/issue → der Server druckt das Design, encodiert den Chip, liest die UID kontaktlos und registriert sie als neue Karte im 2N Access Commander (oder via Webhook in einem anderen Zutrittskontrollsystem oder PMS). Die Antwort ist JSON mit UID und Status — direkt im System, das den Aufruf initiiert hat, verwendbar. Die API ist Bearer-Token-authentifiziert, und jede Ausgabe landet in einem Append-only JSON-Lines Audit-Log, direkt von einem SIEM einlesbar.
Unter der Haube ein statisches Rust-Binary ohne Runtime, GC oder unsafe-Blocks: dieselbe Codebase kompiliert und läuft auf Linux (verifiziert auf Ubuntu 24.04) und Windows, und bedient mehrere Drucker gleichzeitig über eine gemeinsame Control-Plane mit Source-IP-Demux. Keine Kernel-Treiber-Installationen, keine Wartung pro Arbeitsstation, kein USB-Tether.
Funktioniert mit der Zebra ZC350
ConoCard ist um einen spezifischen Kartendrucker gebaut: die Zebra ZC350. Wir steuern sie vollständig über das Netzwerk an, durch eine Reimplementierung des Silex SX-200 USB-over-IP-Protokolls — ohne Zebras eigenen Treiberstack oder CardStudio. Hier der aktuelle v1-Stand:
| Drucker | v1-Status | Treiberlos über IP | Kontaktlose UID-Auslesung |
|---|---|---|---|
| Zebra ZC350 (mit Silex-Chip) | Unterstützt | Ja | Ja |
| Zebra ZC300 (mit Silex-Chip) | Scoping pro Deal | Voraussichtlich ja | Voraussichtlich ja |
| Zebra ZC100 | Scoping pro Deal | Zu verifizieren | Kein NFC-Encoder |
| Magicard, Evolis, IDP Smart | Auf Anfrage | Auf Anfrage | Auf Anfrage |
Die ZC300- und ZC100-Varianten mit Netzwerk-Option nutzen denselben Silex-Chip wie die ZC350; ein Funktionieren ist daher wahrscheinlich, aber ohne physische Verifizierung nicht garantiert. Fordern Sie für konkrete Deals ein gescoptes Projekt an.
Zebra ZC350 REST API
Die vollständige REST-Spezifikation mit curl-, Python- und PHP-Beispielen.
Zebra CardStudio-Alternative
Serverseitig statt eines Tools pro Arbeitsstation — wenn CardStudio knirscht.
ZC350 + 2N Access Commander
End-to-End-Ausgabe: drucken, encodieren, UID-Auslesung, Registrierung in einem Aufruf.
Software im Vergleich
Ehrlicher Vergleich vs CardStudio, FARGO Connect, CardExchange, Entrust und Silex.
Was es tut — was heute solide ist
Treiberlose ZC350-Ansteuerung
Vollständige Ansteuerung der Zebra ZC350 über IP — ohne Hersteller-Treiberstack, ohne USB-Tether, ohne lokale Arbeitsstation pro Drucker. Live auf dem physischen Drucker bewiesen.
Kontaktlose UID-Auslesung
Die UID der ausgegebenen Karte wird in derselben Session kontaktlos zurückgelesen und ist direkt in der API-Response verfügbar. Keine separaten Lesegeräte, kein zusätzlicher Schritt.
Vollständige Ausgabe in einem REST-Aufruf
POST /api/issue → Drucken, Encoden, UID-Lesen und Registrieren im 2N Access Commander erfolgen serverseitig in einem Flow. JSON zurück mit UID und Status.
2N Access Commander-Registrierung
Die ausgelesene UID wird direkt als neue Karte im 2N Access Commander registriert — der Benutzer hat innerhalb Sekunden Zugang.
REST API mit Bearer-Token-Auth
Secure by default: der Service verweigert den Start ohne konfiguriertes Token und vergleicht Tokens in konstanter Zeit. Keine offenen Netzwerke erforderlich, kein separater Reverse-Proxy nur für die Authentifizierung.
Audit-Logging — JSON-Lines
Append-only Protokoll jeder Ausgabe (Erfolg und Fehler) mit UID, Timestamp und Quelle. Direkt von einem SIEM einlesbar — keine Parser, keine Schema-Konvertierungen.
Webhook-Output zu anderen Systemen
Generischer Webhook hinter derselben Integrationsschicht (AccessSystem-Trait): neben 2N können Sie jedes HTTP-fähige System speisen — Salto, Dormakaba, HID, Nedap, ein PMS oder eigene Tools.
Ein Server → mehrere Drucker
Gemeinsame Control-Plane mit Source-IP-Demux: eine Instanz kann mehrere ZC350 gleichzeitig bedienen. Keine 1-zu-1-Beziehung zwischen Server und Drucker.
Cross-Platform: Linux und Windows
Ein statisches Rust-Binary, das auf beiden kompiliert und läuft. Verifiziert auf Ubuntu 24.04 und Windows; 87 Tests grün auf jedem. TLS eingebaut.
Rust — produktionssicher
Speichersicher, keine Runtime, kein GC, und null unsafe in der Codebase. Keine DLL-Hölle, keine JVM, kein Interpreter.
REST API als Integrationsfläche
HR-System, Besucher-Management, Rezeptions-App, PMS oder Script — alles, was HTTP spricht, kann eine Ausgabe anfordern. Keine UI-Verknüpfung erforderlich.
Deploybar als eigenständiges Binary
Laufen Sie auf einer Linux-VM, einem Windows-Server, einem Raspberry Pi/Mini-PC oder als systemd/Windows-Dienst. Keine Client-Installationen auf Arbeitsstationen, keine Kernel-Treiber-Installationen.
Für wen — vier Use-Cases, eine Engine
Dieselbe Rust-Engine wird auf vier verschiedene Arten eingesetzt. Was in Ihrer Situation den Unterschied macht, ist nicht welche "Edition" Sie kaufen, sondern wie wir es deployen, anbinden und abrechnen.
Enterprise IT & Casinos
Serverseitige Ansteuerung in einem Rechenzentrum oder Corporate-VM. 2N Access Commander end-to-end, Audit-Log an SIEM, Bearer-Token-Auth für Compliance-Anforderungen, Multi-Drucker pro Server für große Bestände. Keine Arbeitsstation-Installationen.
Hospitality & Ferienvermietung
Self-Check-in via Ihr PMS: eine neue Buchung triggert via Webhook eine Kartenausgabe ohne Front-Desk. Eine kleine Linux-Box im Technikraum (Raspberry Pi oder Mini-PC) genügt. Hotels, Serviced Apartments und Boutique-Ketten.
Integratoren & 2N-Partner
Serverseitige ZC350-Flotten über mehrere Kunden oder Standorte verwalten. REST + Webhook zur Anbindung an eigenes Monitoring, Ticketing oder Provisioning. Uniform über Standorte, multi-tenant deploybar.
Workflow-Bauer & MSPs
Kartenausgabe als API-Aufruf in HR-Onboarding, Besucher-Management, Ticketing oder eigene Apps. Alles, was HTTP spricht, kann eine Ausgabe anfordern — keine UI-Verknüpfung erforderlich. Webhook-Output für nachgelagerte Systeme.
Stack & Integrationen
Tech-Stack
Rust · plattformübergreifendes Binary · REST API · TLS
Was heute solide funktioniert
Auf der Roadmap
Wir sind explizit darüber, was bereits funktioniert und was noch kommen muss. Die Architektur (AccessSystem/GuestSource-Traits, ccp-issue-Use-Case-Schicht) macht die meisten der Punkte unten klein. Möchten Sie ein Feature priorisiert? Sprechen Sie uns an — wir planen mit konkreten Deals.
Andere Drucker-Modelle
Magicard, Evolis, IDP Smart — auf Anfrage gescopt pro konkretem Deal (typisch 4 bis 8 Wochen). Die Drucker-Schicht ist ein Trait, also erweiterbar ohne den Core anzufassen.
Spezifische PMS-Adapter
Webhook-Anbindung funktioniert heute mit jedem PMS, das HTTP spricht; vorgebackene Adapter für Lodgify, Smoobu, Hospitable und andere sind Scoping-Arbeit pro konkretem Hospitality-Deal.
SSO / SAML / OIDC / RBAC
Auf Anfrage für Deployments, in denen dies eine Akzeptanzanforderung ist. Bearer-Token-Auth ist in v1 integriert; SSO kommt für Enterprise-Umgebungen darauf.
Multi-Site-Management-Dashboard
Zentraler Überblick über Instanzen an mehreren Standorten. Heute läuft Multi-Site als eine Instanz pro Standort oder via VPN.
Aktiver SIEM-Push & Compliance-Reporting
Das Audit-Log ist bereits JSON-Lines und daher SIEM-einlesbar (Splunk, ELK, Sentinel). Auf der Roadmap: aktiver Push-Export und fertige Templates für NEN 7510 / ISO 27001.
Häufig gestellte Fragen
Welcher Drucker wird aktuell unterstützt?
In v1 ausschließlich die Zebra ZC350. Wir steuern sie vollständig über IP an, ohne Hersteller-Treiberstack, inklusive kontaktloser UID-Auslesung. Andere Modelle (Magicard, Evolis, IDP) auf Anfrage; für konkrete Deals ist ein gescoptes Projekt möglich — typisch 4 bis 8 Wochen.
Welches Zutrittskontrollsystem wird aktuell unterstützt?
2N Access Commander end-to-end: eine Ausgabe registriert die UID direkt als neue Karte. Zusätzlich gibt es einen generischen Webhook-Output hinter derselben Integrationsschicht — damit können Sie jedes HTTP-fähige System ansteuern (Salto, Dormakaba, HID, Nedap, ein PMS oder eigene Tools).
Funktioniert es für Hotels und Ferienvermietung?
Ja. Ein typisches Hospitality-Deployment koppelt das PMS (Buchungssystem) per Webhook an ConoCard, sodass eine neue Buchung automatisch eine Karte erzeugt ohne Front-Desk. Die PMS-Verbindung scopen wir pro Deal — die Webhook-Schicht ist generisch, spezifische PMS-Adapter erstellen wir auf Anfrage.
Wie verläuft eine Ausgabe technisch?
Ein authentifizierter REST-Aufruf: POST /api/issue mit Bearer-Token im Header und Kartendaten im Body. Der Server sendet den Druckauftrag über IP zum Drucker, encodiert den Chip, liest die UID kontaktlos zurück, registriert sie im 2N Access Commander (und optional via Webhook in einem anderen System) und liefert JSON mit UID und Status zurück. Keine lokale Arbeitsstation, kein USB-Kabel.
Auf welchen Betriebssystemen läuft es?
Ein statisches Rust-Binary, das sowohl auf Linux (Ubuntu 24.04 verifiziert) als auch auf Windows kompiliert. 87 Tests grün auf beiden. Keine Runtime-Abhängigkeiten, kein GC, und null unsafe in der Codebase. TLS eingebaut.
Wie sieht es mit Authentifizierung und Audit-Logging aus?
Beides in v1 integriert. Bearer-Token-Authentifizierung ist secure by default: der Service verweigert den Start ohne konfiguriertes Token und vergleicht Tokens in konstanter Zeit. Audit-Logging schreibt jede Ausgabe (Erfolg und Fehler) als Append-only JSON-Lines mit UID, Timestamp und Quelle — direkt von einem SIEM einlesbar ohne Parser oder Schema-Konvertierungen.
Was mit SIEM-Export, SSO oder Compliance-Reporting (NEN 7510 / ISO 27001)?
Das Audit-Log ist bereits JSON-Lines und daher von Splunk, ELK und Microsoft Sentinel einlesbar. Auf der Roadmap: ein aktiver Push-Export und fertige Templates für NEN 7510 / ISO 27001. SSO/SAML/OIDC kommt auf die bestehende Bearer-Token-Auth für Enterprise-Umgebungen.
Wie verhält sich das zu Zebra CardStudio?
CardStudio ist ein Desktop-Tool pro Arbeitsstation, mit USB-Tether und ohne API. ConoCard ist serverseitig und netzwerk-nativ, über REST ansteuerbar — ein Server ersetzt das Muster von Treiberstacks pro Arbeitsstation. Mehr zur CardStudio-Alternative →
Ist es multi-site nutzbar?
Ein Server bedient mehrere Drucker via Source-IP-Demux. In einem Multi-Site-Szenario läuft eine Instanz pro Standort oder eine zentrale Instanz mit VPN-Anbindung. Ein zentrales Multi-Site-Management-Dashboard ist auf der Roadmap.
Wie sieht das Deployment aus?
Ein statisches Rust-Binary, keine Runtime, keine Kernel-Treiber-Installationen. Laufen Sie es in einer Linux-VM, auf einem Windows-Server, auf einem Raspberry Pi/Mini-PC oder als systemd/Windows-Dienst. Es gibt keine separate Client-Installation auf Arbeitsstationen.
Siehe auch
Mehr über ConoCard erfahren?
Planen Sie eine Demo oder fordern Sie ein Angebot an. Wir denken gerne mit Ihnen mit — Enterprise, Hospitality oder Integrator.
Demo planen →