The manual workflow — and what's broken about it
The traditional way to issue an access card with a Zebra ZC350 and 2N Access Commander is a sequence of separate steps, often split across two people and three screens:
- Receptionist opens the printer tool (CardStudio) on a Windows workstation with a USB cable to the ZC350.
- Receptionist types in name and validity, clicks print.
- The card comes out of the printer; the receptionist puts it on a separate NFC reader.
- The NFC reader shows the UID; the receptionist types it across.
- IT staff (or receptionist with admin rights) opens 2N Access Commander in a browser.
- The UID is linked to a user record; permissions are configured.
- Only then can the user actually open the door.
In total: 6 to 8 actions, two tools, two people, and a UID that's typed across manually — with the corresponding error rate. For a hotel with 200 bookings per month, a corporate with daily onboarding, or a casino with visitor passes: an operational bottleneck.
What ConoCard changes
ConoCard turns those 6-8 steps into one authenticated HTTP call. POST /api/issue does everything that used to happen manually — server-side, measured in seconds.
The end-to-end flow
POST /api/issue with bearer token and the card / guest data.Total: one HTTP call. Within seconds the user has access and the audit trail is complete. No manual UID copying, no sequential tool-hopping.
UID lifecycle in 2N Access Commander
ConoCard doesn't just write "a UID" to 2N — it manages the entire lifecycle:
- Issuance: a new card is linked to a user with the specified validity period and permissions.
- Renewal: an existing card can be refreshed via a second API call without printing a new card.
- Revocation: a separate endpoint (on the roadmap for v1.x) revokes the UID in 2N and adds a log entry.
- Audit log: every event (issuance, renewal, error, revocation) lands in the JSON-Lines log with UID, timestamp and source — directly ingestible by your SIEM for compliance reporting.
In practice: three use cases
Hotel & short-term rental
A new booking in the PMS (Lodgify, Smoobu, etc.) triggers a POST /api/issue call via webhook. Within seconds the card comes out of the printer in the utility closet, with the UID already registered in 2N. Guest picks it up from a key safe or front-desk-less pickup. No front desk, no manual UID typing.
Corporate IT & visitor management
A visitor management system sends an API call to ConoCard for every pre-announced visit. The receptionist only has to hand the card over — everything from printing to 2N registration happens server-side. Audit trail to SIEM for compliance reporting. Provisioning 100 employees in 1 hour instead of a day.
Casinos & members-only
Member cards and employee badges across multiple locations, with central management and consistent design. One ConoCard instance per location, or a central instance over VPN. All issuances land in 2N Access Commander and in the audit log — which makes the difference during compliance audits.
Integrator deployment & 2N partners
As a 2N partner you can offer ConoCard as an add-on to Access Commander installations where physical cards are needed. One Linux box at the customer, hooked up to their existing ZC350 fleet. Multi-tenant deployable for you as the integrator.
For 2N partners: ConoCard is designed to sit next to Access Commander as a card-issuance layer. We see this as a natural extension to the 2N stack — similar to how IP Verso / IP Force handle the entry interaction side. Get in touch about partnership opportunities.
What you need to get started
- Zebra ZC350 with the network option (Silex SX-200 chip on board — standard on the network models)
- 2N Access Commander reachable via REST API inside your network
- One Linux VM, Windows server or Raspberry Pi to run the ConoCard binary
- Bearer token for the ConoCard API (configurable)
- API credentials for your 2N Access Commander
No vendor driver stack, no CardStudio licences, no workstation installs. A typical initial setup is operational in half a working day.
Frequently asked questions
Which version of 2N Access Commander is supported?
The current stable version of 2N Access Commander is supported via its official REST API. For specific version questions or legacy deployments, let us know — we test on request.
Do I need a Conocido cloud?
No. ConoCard runs entirely inside your own network. The service talks locally to the ZC350 over IP and to your 2N Access Commander REST endpoint. No external cloud middleman, no data leaving your network.
What happens if 2N Access Commander is offline?
The ZC350 issuance still happens, and the issued UID is captured in the audit log. The 2N registration is retried as soon as Access Commander is reachable again, or a structured error is returned so you can handle it at flow level.
Can I also connect other access-control systems?
Yes. In addition to 2N Access Commander end-to-end there's a generic webhook output behind the same integration layer. You can feed Salto, Dormakaba, HID, Nedap or in-house tooling alongside 2N.
Does it work with IP Verso, IP Force or IP Style?
Those are physical entry units — they don't touch card printing itself, but they do touch the access flow. Via 2N Access Commander they know about the card ConoCard registers — no separate hook per entry unit.
Can issuance be initiated from the Access Commander box itself?
Yes. If your 2N installation has its own UI layer (or a companion app), it can call the ConoCard REST API directly. That way you can initiate a new card from any location where a 2N unit lives.