API REST Zebra ZC350

Pourquoi une API REST pour la Zebra ZC350 ?

La Zebra ZC350 est une excellente imprimante de cartes, mais son pilotage standard ne l'est pas. Quiconque veut intégrer l'imprimante dans son propre workflow se heurte en pratique à trois frictions opérationnelles : un poste Windows par imprimante, un câble USB entre le poste et le matériel, et une pile pilote fournisseur (CardStudio plus Silex SX Virtual Link) à installer et maintenir par poste. Acceptable pour une seule réception ; un cauchemar opérationnel pour un déploiement corporate ou multi-sites.

ConoCard propose une alternative au bon niveau : un serveur HTTP qui pilote l'imprimante via IP. Un appel POST avec les données de carte souhaitées, et le serveur s'occupe de l'impression, l'encodage, la lecture sans contact de l'UID et l'enregistrement dans 2N Access Commander, en renvoyant du JSON. Pas de pilote, pas d'USB, pas d'installations par poste.

L'endpoint principal : POST /api/issue

Un endpoint couvre 90% du besoin opérationnel. Vous transmettez ce qui doit figurer sur la carte, pour qui la carte est destinée, et facultativement quelle imprimante (en configuration multi-imprimante). Le serveur fait le reste.

Authentification

Tous les appels nécessitent un bearer-token dans l'en-tête Authorization. Les tokens sont comparés en temps constant (pas de fuites de timing). Le service est secure by default : sans token configuré, ConoCard refuse de démarrer.

Authorization: Bearer your-token-here

Corps de requête (exemple)

{
  "guest": {
    "name": "Jane Doe",
    "reference": "booking-1234"
  },
  "validity": {
    "from": "2026-06-01T15:00:00Z",
    "until": "2026-06-05T11:00:00Z"
  },
  "printer": "192.168.1.42"
}

Réponse (JSON)

{
  "status": "issued",
  "uid": "04A5B6C7D8E9",
  "printed_at": "2026-05-30T13:42:18Z",
  "registered_in": "2n-access-commander",
  "audit_id": "01HXYZ..."
}

Exemples de code

curl

curl -X POST https://conocard.local/api/issue \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"guest":{"name":"Jane Doe"},"printer":"192.168.1.42"}'

Python (requests)

import requests, os

r = requests.post(
    "https://conocard.local/api/issue",
    headers={"Authorization": f"Bearer {os.environ['CONOCARD_TOKEN']}"},
    json={
        "guest": {"name": "Jane Doe"},
        "printer": "192.168.1.42",
    },
    timeout=30,
)
r.raise_for_status()
print(r.json()["uid"])

PHP

// guzzlehttp/guzzle
$client = new GuzzleHttp\Client();
$resp = $client->post('https://conocard.local/api/issue', [
  'headers' => ['Authorization' => 'Bearer ' . $token],
  'json'    => ['guest' => ['name' => 'Jane Doe'], 'printer' => '192.168.1.42'],
]);
$uid = json_decode($resp->getBody(), true)['uid'];

Journal d'audit : JSON-Lines directement vers votre SIEM

Chaque émission de carte — succès et échec — est écrite dans un journal d'audit append-only au format JSON-Lines. Une ligne par événement, directement ingérable par Splunk, ELK, Microsoft Sentinel ou tout autre SIEM. Pas de parseurs, pas de conversions de schéma.

{"ts":"2026-05-30T13:42:18Z","event":"issue.success","uid":"04A5B6C7D8E9","printer":"192.168.1.42","source":"api/jane.doe"}
{"ts":"2026-05-30T13:43:02Z","event":"issue.error","reason":"printer_unreachable","printer":"192.168.1.43"}

Plusieurs imprimantes depuis un seul serveur

Une instance peut piloter plusieurs ZC350 simultanément, via un plan de contrôle partagé avec démultiplexage par IP source. En pratique : configurez l'IP de l'imprimante par requête, ou prédéfinissez un mappage dans la configuration du service. Pas de relation un-pour-un entre serveur et imprimante.

Pour les scénarios multi-sites, on exécute généralement une instance par site (dans une VM Linux ou serveur Windows), ou une instance centrale avec connectivité VPN. Un tableau de bord central multi-sites est sur la roadmap.

API REST ConoCard vs. la pile Zebra

Questions fréquentes