ConoCard
An API for card printers — without the driver circus.
What is ConoCard?
ConoCard solves one very specific, hard problem: driverless control of the Zebra ZC350 over the network, from any OS — including contactless UID read-back in the same session. Exactly where Zebra's standard stack forces you into one Windows workstation per printer on a USB cable, and where alternatives like Silex SX Virtual Link demand a proprietary driver install on every machine.
An issuance runs as an end-to-end flow in a single REST call: POST /api/issue → the server prints the design, encodes the chip, reads the UID contactlessly and registers it as a new card in 2N Access Commander (or via webhook into another access-control system or PMS). The response is JSON with UID and status — usable immediately by the system that made the call. The API is Bearer-token authenticated, and every issuance lands in an append-only JSON-Lines audit log, ingestible straight into a SIEM.
Under the hood, a static Rust binary with no runtime, GC or unsafe blocks: the same codebase compiles and runs on Linux (verified on Ubuntu 24.04) and Windows, and serves multiple printers concurrently through a shared control plane with source-IP demux. No kernel-driver installs, no per-workstation maintenance, no USB tether.
Works with the Zebra ZC350
ConoCard is built around one specific card printer: the Zebra ZC350. We drive it fully over the network through a reimplementation of the Silex SX-200 USB-over-IP protocol — without Zebra's own driver stack or CardStudio. Here's the current v1 status:
| Printer | v1 status | Driverless over IP | Contactless UID read-back |
|---|---|---|---|
| Zebra ZC350 (with Silex chip) | Supported | Yes | Yes |
| Zebra ZC300 (with Silex chip) | Scoping per deal | Likely yes | Likely yes |
| Zebra ZC100 | Scoping per deal | To be verified | No NFC encoder |
| Magicard, Evolis, IDP Smart | On request | On request | On request |
The ZC300 and ZC100 variants with the network option use the same Silex chip as the ZC350; working is therefore likely, but not guaranteed without physical verification. Request a scoped project for concrete deals.
Zebra ZC350 REST API
The full REST specification with curl, Python and PHP examples.
Zebra CardStudio alternative
Server-side instead of a tool per workstation — when CardStudio grinds.
ZC350 + 2N Access Commander
End-to-end issuance: print, encode, UID read-back, registration in one call.
Software compared
Honest comparison vs CardStudio, FARGO Connect, CardExchange, Entrust and Silex.
What it does — what's solid today
Driverless ZC350 control
Full control of the Zebra ZC350 over IP — no vendor driver stack, no USB tether, no local workstation per printer. Proven live on the physical printer.
Contactless UID read-back
The UID of the issued card is read back contactlessly in the same session and returned directly in the API response. No separate readers, no extra step.
Full issuance in one REST call
POST /api/issue → printing, encoding, UID read and registration in 2N Access Commander happen server-side in a single flow. JSON back with UID and status.
2N Access Commander registration
The read UID is registered directly as a new card in 2N Access Commander — the user has access within seconds.
REST API with Bearer-token auth
Secure by default: the service refuses to start without a configured token and compares tokens in constant time. No open networks required, no separate reverse proxy just for authentication.
Audit logging — JSON-Lines
Append-only record of every issuance (success and failure) with UID, timestamp and source. Ingestible straight into a SIEM — no parsers, no schema conversions.
Webhook output to other systems
Generic webhook behind the same integration layer (AccessSystem trait): besides 2N you can feed any HTTP-speaking system — Salto, Dormakaba, HID, Nedap, a PMS or in-house tooling.
One server → multiple printers
Shared control plane with source-IP demux: one instance serves multiple ZC350s concurrently. No 1-to-1 relationship between server and printer.
Cross-platform: Linux and Windows
One static Rust binary that compiles and runs on both. Verified on Ubuntu 24.04 and Windows; 87 tests green on each. TLS built in.
Rust — production-grade
Memory-safe, no runtime, no GC, and zero unsafe in the codebase. No DLL hell, no JVM, no interpreter.
REST API as integration surface
HR system, visitor management, reception app, PMS or script — anything that speaks HTTP can request an issuance. No UI coupling required.
Deployable as a standalone binary
Run on a Linux VM, a Windows server, a Raspberry Pi/mini-PC or as a systemd/Windows service. No client installs on workstations, no kernel-driver installs.
For whom — four use cases, one engine
The same Rust engine is deployed in four different ways. What makes the difference in your situation isn't which "edition" you buy, but how we deploy, connect and bill it.
Enterprise IT & casinos
Server-side control in a data center or corporate VM. 2N Access Commander end-to-end, audit log to SIEM, Bearer-token auth for compliance requirements, multiple printers per server for large estates. No workstation installs.
Hospitality & holiday rentals
Self-check-in via your PMS: a new booking triggers card issuance over a webhook, with no front desk. A small Linux box in the utility room (Raspberry Pi or mini-PC) is enough. Hotels, serviced apartments and boutique chains.
Integrators & 2N partners
Manage server-side ZC350 fleets across multiple customers or sites. REST + webhook to connect your own monitoring, ticketing or provisioning. Uniform across sites, multi-tenant deployable.
Workflow builders & MSPs
Card issuance as an API call in HR onboarding, visitor management, ticketing or your own apps. Anything that speaks HTTP can request an issuance — no UI coupling required. Webhook output to downstream systems.
Stack & integrations
Tech stack
Rust · cross-platform binary · REST API · TLS
What is solid today
On the roadmap
We're explicit about what already works and what still has to come. The architecture (AccessSystem/GuestSource traits, ccp-issue use-case layer) keeps most of the items below small. Want a feature prioritised? Get in touch — we plan around concrete deals.
Other printer models
Magicard, Evolis, IDP Smart — scoped on request per concrete deal (typically 4 to 8 weeks). The printer layer is a trait, so extensible without touching the core.
Specific PMS adapters
Webhook integration works today with any PMS that speaks HTTP; pre-baked adapters for Lodgify, Smoobu, Hospitable and others are scoping work per concrete hospitality deal.
SSO / SAML / OIDC / RBAC
On request for deployments where this is an acceptance requirement. Bearer-token auth ships in v1; SSO comes on top for enterprise environments.
Multi-site management dashboard
Central overview of instances across several sites. Today multi-site runs as one instance per site or over VPN.
Active SIEM push & compliance reporting
The audit log is already JSON-Lines and therefore SIEM-ingestible (Splunk, ELK, Sentinel). On the roadmap: active push export and ready-made templates for NEN 7510 / ISO 27001.
Frequently asked questions
Which printer is supported right now?
In v1, only the Zebra ZC350. We drive it fully over IP, with no vendor driver stack, including contactless UID read-back. Other models (Magicard, Evolis, IDP) on request; for concrete deals a scoped project is possible — typically 4 to 8 weeks.
Which access-control system is supported right now?
2N Access Commander end-to-end: an issuance registers the UID directly as a new card. On top of that there's a generic webhook output behind the same integration layer — letting you drive any HTTP-speaking system (Salto, Dormakaba, HID, Nedap, a PMS or in-house tooling).
Does it work for hotels and holiday rentals?
Yes. A typical hospitality deployment connects the PMS (booking system) to ConoCard over a webhook, so a new booking generates a card automatically with no front desk. We scope the PMS connection per deal — the webhook layer is generic, and we build specific PMS adapters on request.
How does an issuance work technically?
One authenticated REST call: POST /api/issue with a Bearer token in the header and card data in the body. The server sends the print job to the printer over IP, encodes the chip, reads the UID back contactlessly, registers it in 2N Access Commander (and optionally via webhook into another system) and returns JSON with UID and status. No local workstation, no USB cable.
Which operating systems does it run on?
One static Rust binary that compiles on both Linux (Ubuntu 24.04 verified) and Windows. 87 tests green on both. No runtime dependencies, no GC, and zero unsafe in the codebase. TLS built in.
What about authentication and audit logging?
Both built into v1. Bearer-token authentication is secure by default: the service refuses to start without a configured token and compares tokens in constant time. Audit logging writes every issuance (success and failure) as append-only JSON-Lines with UID, timestamp and source — ingestible straight into a SIEM without parsers or schema conversions.
What about SIEM export, SSO or compliance reporting (NEN 7510 / ISO 27001)?
The audit log is already JSON-Lines and therefore ingestible by Splunk, ELK and Microsoft Sentinel. On the roadmap: an active push export and ready-made templates for NEN 7510 / ISO 27001. SSO/SAML/OIDC comes on top of the existing Bearer-token auth for enterprise environments.
How does this compare to Zebra CardStudio?
CardStudio is a per-workstation desktop tool, with a USB tether and no API. ConoCard is server-side and network-native, drivable over REST — one server replaces the pattern of per-workstation driver stacks. More on the CardStudio alternative →
Can it be used multi-site?
One server serves multiple printers via source-IP demux. In a multi-site scenario you run one instance per location or a central instance with a VPN link. A central multi-site management dashboard is on the roadmap.
What does deployment look like?
One static Rust binary, no runtime, no kernel-driver installs. Run it in a Linux VM, on a Windows server, on a Raspberry Pi/mini-PC or as a systemd/Windows service. There's no separate client install on workstations.
See also
Want to know more about ConoCard?
Book a demo or request a quote. We're happy to think along — enterprise, hospitality or integrator.
Book a demo →