API REST pour Appareils Biométriques : Le Guide Complet du Développeur
Découvrez comment les API REST modernes simplifient l'intégration des appareils biométriques dans vos systèmes ERP et SIRH. Guide complet avec authentification, webhooks et exemples de code prêts pour la production en Python, JavaScript et cURL.
Introduction
Si vous développez un SIRH, un ERP ou un système de contrôle d'accès, vous avez probablement déjà rencontré le mur de l'intégration biométrique. Les SDK sont verrouillés à un système d'exploitation et nécessitent un accès réseau local. Les protocoles propriétaires (comme ceux de ZKTeco) sont bas niveau et fragiles. Interroger des bases de données pour récupérer les pointages est inefficace et introduit des délais. Il y a mieux.
PunchConnect est un middleware cloud API REST qui connecte les appareils biométriques ZKTeco à n'importe quel système logiciel. Les API REST modernes masquent la complexité des appareils, éliminent les barrières réseau et livrent les données en temps réel via des webhooks. Ce guide explique ce qu'est une API REST pour appareils biométriques, comment elle fonctionne, et comment l'intégrer dans votre application — avec des exemples de code prêts pour la production en Python, JavaScript et cURL.
Qu'est-ce qu'une API REST pour appareils biométriques ?
Une API REST biométrique est une couche middleware qui expose des endpoints HTTP pour interagir avec les appareils biométriques. Au lieu d'installer un SDK constructeur ou d'écrire des handlers de protocole bas niveau, votre application envoie des requêtes HTTP standard pour gérer les appareils, inscrire les utilisateurs et recevoir les données de pointage.
Pourquoi REST ?
Les API REST sont :
- Stateless : chaque requête contient toutes les informations nécessaires — pas de gestion de session
- Agnostiques : utilisez n'importe quel langage avec support HTTP (Python, JavaScript, Java, PHP, Go)
- Web-native : fonctionnent à travers les pare-feu et proxys sans configuration réseau spéciale
- Compatible pare-feu : HTTPS standard sur le port 443 — pas de ports UDP personnalisés ni de tunnels VPN
API REST vs autres méthodes d'intégration
| Méthode | Réseau requis | Langages | Complexité | Temps réel |
|---------|--------------|----------|------------|------------|
| API REST | Internet uniquement | Tous | Faible | Webhooks (instantané) |
| SDK constructeur | LAN local | Windows/Linux | Élevée | Polling (retardé) |
| Protocole direct | LAN + redirection de port | Langage du SDK | Très élevée | Implémentation custom |
| Polling BDD | LAN ou VPN | Tous | Moyenne | Polling (retardé) |
Ce qu'une bonne API REST biométrique doit offrir
1. Gestion des appareils : enregistrer, configurer, surveiller et désactiver les appareils à distance
2. Gestion des utilisateurs : ajouter, modifier et supprimer les utilisateurs avec leurs empreintes biométriques (empreinte digitale, visage, paume)
3. Récupération des pointages : webhooks temps réel pour les événements instantanés ou requêtes historiques à la demande
4. Gestion des événements : accès porte, alertes de sécurité, changements d'état des appareils
Endpoints principaux de l'API REST
Une API REST biométrique bien conçue expose généralement ces ressources :
Gestion des appareils
# Enregistrer un nouvel appareil
POST /v1/devices
{
"serial_number": "AKJD193840129",
"name": "Entrée Bureau Principal",
"location": "Bâtiment A, Étage 1"
}
# Obtenir le statut et les informations de stockage
GET /v1/devices/AKJD193840129
# Réponse : { "status": "online", "users": 243, "logs": 15847, "storage": "34%" }
# Désactiver un appareil
DELETE /v1/devices/AKJD193840129Gestion des utilisateurs
# Ajouter un utilisateur avec son empreinte biométrique
POST /v1/users
{
"device_id": "AKJD193840129",
"user_id": "EMP_001",
"name": "Jean Dupont",
"templates": [
{
"type": "fingerprint",
"data": "EMPREINTE_ENCODEE_BASE64",
"index": 0
}
]
}
# Modifier les informations utilisateur
PUT /v1/users/EMP_001
{
"name": "Jean A. Dupont",
"department": "Ingénierie"
}
# Supprimer un utilisateur d'un appareil
DELETE /v1/users/EMP_001?device_id=AKJD193840129Pointages / Logs de présence
Votre serveur reçoit aussi les événements de pointage en temps réel via webhooks (détaillé plus bas).
# Récupérer l'historique des pointages
GET /v1/logs?start_date=2026-03-01&end_date=2026-03-22&user_id=EMP_001Exemple de code : récupérer les logs de pointage
cURL :
Python :
```python
import requests
from datetime import date
API_KEY = "votre_cle_api"
BASE_URL = "https://api.punchconnect.com/v1"
response = requests.get(
f"{BASE_URL}/logs",
headers={"Authorization": f"Bearer {API_KEY}"},
params={
"start_date": "2026-03-01",
"end_date": "2026-03-22",
"user_id": "EMP_001"
}
)
logs = response.json()["data"]
for log in logs:
print(f"{log['user_id']} - {log['punch_type']} à {log['timestamp']}")
```
JavaScript (Node.js / Navigateur) :
```javascript
const API_KEY = 'votre_cle_api';
const BASE_URL = 'https://api.punchconnect.com/v1';
fetch(${BASE_URL}/logs?start_date=2026-03-01&end_date=2026-03-22, {
headers: { 'Authorization': Bearer ${API_KEY} }
})
.then(res => res.json())
.then(data => {
data.data.forEach(log => {
console.log(${log.user_id} - ${log.punch_type} à ${log.timestamp});
});
});
```
curl -X GET "https://api.punchconnect.com/v1/logs?start_date=2026-03-01&end_date=2026-03-22" \
-H "Authorization: Bearer VOTRE_CLE_API"Authentification des API biométriques
L'authentification empêche le contrôle non autorisé des appareils et les fuites de données. Voici trois méthodes courantes :
1. Clés API (recommandé pour serveur à serveur)
La méthode la plus simple et la plus courante. Votre application inclut une clé API statique dans les en-têtes de requête :
Avantages : simple à implémenter, pas de logique de rafraîchissement de token
Inconvénients : doit rester secrète ; si divulguée, accès non autorisé jusqu'à révocation manuelle
Idéal pour : services backend, tâches CRON, intégrations internes
Authorization: Bearer sk_live_abc123def4562. OAuth 2.0 (pour les applications utilisateur)
Accès délégué via des tokens à durée de vie courte et des tokens de rafraîchissement. Les utilisateurs autorisent votre application à accéder à leurs données biométriques sans partager leurs identifiants.
Avantages : permissions granulaires, expiration automatique des tokens
Inconvénients : implémentation complexe, nécessite un flux OAuth
Idéal pour : produits SaaS où les utilisateurs finaux possèdent les appareils
3. Signatures HMAC (pour la vérification des webhooks)
Quand l'API envoie des webhooks à votre serveur, les signatures HMAC prouvent que la requête provient du fournisseur légitime :
import hmac
import hashlib
def verifier_webhook(payload, signature, secret):
"""Vérifier la signature HMAC-SHA256 du webhook."""
expected = hmac.new(
key=secret.encode(),
msg=payload.encode(),
digestmod=hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected, signature)
# Utilisation dans votre handler de webhook
if not verifier_webhook(request.body, request.headers['X-Signature'], WEBHOOK_SECRET):
return {"error": "Signature invalide"}, 401Bonnes pratiques d'authentification
1. Toujours utiliser HTTPS (TLS 1.3 recommandé) pour chiffrer les clés API en transit
2. Rotation des clés API chaque trimestre ou immédiatement en cas de compromission
3. Stocker les clés dans des variables d'environnement, jamais dans le code source
4. Utiliser des clés distinctes pour les environnements de développement, staging et production
5. Surveiller l'utilisation de l'API pour détecter les comportements suspects (volume élevé, localisations géographiques inhabituelles)
Conformité RGPD et données biométriques
L'intégration de données biométriques dans l'Union européenne et dans les pays francophones soumis au RGPD (ou à des régulations similaires en Afrique francophone comme la loi ivoirienne sur les données personnelles) nécessite une attention particulière.
Les données biométriques sont des données sensibles
Le Règlement Général sur la Protection des Données (RGPD) classe les données biométriques dans la catégorie des données sensibles (Article 9). Leur traitement est interdit par défaut, sauf exceptions strictes.
Obligations clés pour les développeurs
| Obligation | Ce que cela implique | Comment l'API REST aide |
|-----------|----------------------|------------------------|
| Consentement explicite | L'employé doit consentir par écrit au traitement biométrique | L'API stocke l'horodatage de consentement par utilisateur |
| Minimisation des données | Ne collecter que les données strictement nécessaires | L'API ne transmet que les templates et pointages, pas les images brutes |
| Droit à l'effacement | L'employé peut demander la suppression de ses données | DELETE /v1/users/EMP_001 supprime templates et logs associés |
| Transfert transfrontalier | Les données ne doivent pas quitter l'UE sans garanties | PunchConnect propose des instances hébergées en Europe (France, Allemagne) |
| Registre des traitements | Documenter tous les traitements de données biométriques | Les logs d'audit de l'API servent de registre technique |
Exemple : supprimer un utilisateur (droit à l'oubli)
import requests
API_KEY = "votre_cle_api"
BASE_URL = "https://api.punchconnect.com/v1"
# Supprimer l'utilisateur et toutes ses données biométriques
response = requests.delete(
f"{BASE_URL}/users/EMP_001",
headers={"Authorization": f"Bearer {API_KEY}"},
params={"delete_logs": True, "delete_templates": True}
)
if response.status_code == 200:
print("Utilisateur et données biométriques supprimés (conformité RGPD)")Spécificités Afrique francophone
En Côte d'Ivoire, au Sénégal et au Cameroun, les régulations de protection des données s'inspirent du RGPD mais avec des différences notables :
- Côte d'Ivoire : loi n°2013-450 relative à la protection des données personnelles, supervision par l'ARTCI
- Sénégal : loi n°2008-12, supervision par la CDP (Commission des Données Personnelles)
- Cameroun : pas encore de loi spécifique, mais le projet de loi sur l'économie numérique inclut la protection des données
Pour les déploiements en Afrique francophone, les API REST cloud offrent un avantage majeur : pas besoin de serveur local pour chaque site. Un seul compte API centralise la gestion de tous les appareils, quel que soit l'emplacement géographique.
Webhooks : événements de pointage en temps réel
Les webhooks éliminent le besoin de polling. Quand un employé pointe sur un appareil biométrique, l'API REST envoie immédiatement un POST HTTP à votre serveur avec les données de pointage.
Anatomie d'un payload webhook de pointage
{
"event": "attendance.punch",
"event_id": "evt_1a2b3c4d5e",
"timestamp": "2026-03-22T08:30:12Z",
"device": {
"id": "DEVICE_12345",
"name": "Entrée Bureau Principal",
"location": "Bâtiment A"
},
"user": {
"id": "EMP_001",
"name": "Jean Dupont"
},
"punch": {
"type": "CheckIn",
"method": "Fingerprint",
"timestamp": "2026-03-22T08:30:12Z",
"temperature": 36.5,
"mask_detected": false
}
}Champs importants à traiter
- `event_id` : identifiant unique pour l'idempotence (stockez-le pour éviter les doublons)
- `user.id` : à mapper avec l'identifiant employé de votre SIRH/ERP
- `punch.type` : valeurs comme CheckIn, CheckOut, BreakIn, BreakOut
- `punch.method` : méthode de vérification utilisée (Fingerprint, Face, Card, Palm, Password)
- `timestamp` : toujours en UTC — convertissez en heure locale pour l'affichage (CET/CEST pour la France, WAT pour l'Afrique de l'Ouest)
- `temperature` : optionnel — présent si l'appareil a un scanner thermique
- `mask_detected` : optionnel — présent si l'appareil détecte le port du masque
Exemple de code : handler de webhook (Node.js Express)
const express = require('express');
const crypto = require('crypto');
const app = express();
app.use(express.json());
const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;
// Vérifier la signature HMAC
function verifierSignature(payload, signature) {
const expected = crypto
.createHmac('sha256', WEBHOOK_SECRET)
.update(JSON.stringify(payload))
.digest('hex');
return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}
app.post('/webhooks/pointage', async (req, res) => {
const signature = req.headers['x-signature'];
// Étape 1 : Vérifier la signature
if (!verifierSignature(req.body, signature)) {
return res.status(401).json({ error: 'Signature invalide' });
}
const event = req.body;
// Étape 2 : Vérifier l'idempotence (éviter les doublons)
const existe = await db.query('SELECT 1 FROM evenements_traites WHERE event_id = ?', [event.event_id]);
if (existe.length > 0) {
return res.status(200).json({ status: 'deja_traite' });
}
// Étape 3 : Traiter le pointage
await db.query(
'INSERT INTO pointages (employe_id, type_pointage, heure_pointage, appareil_id) VALUES (?, ?, ?, ?)',
[event.user.id, event.punch.type, event.punch.timestamp, event.device.id]
);
// Étape 4 : Marquer l'événement comme traité
await db.query('INSERT INTO evenements_traites (event_id) VALUES (?)', [event.event_id]);
// Étape 5 : Répondre avec 200 OK
res.status(200).json({ status: 'recu' });
});
app.listen(3000, () => console.log('Serveur webhook actif sur le port 3000'));Gestion des erreurs et tentatives
Que se passe-t-il si votre serveur est hors ligne ? Les bons fournisseurs d'API renvoient les webhooks avec un backoff exponentiel :
- Tentative 1 : immédiate
- Tentative 2 : +1 seconde
- Tentative 3 : +2 secondes
- Tentative 4 : +4 secondes
- Continue pendant 24 heures maximum
Pourquoi l'idempotence est essentielle : si la tentative 2 réussit mais que le fournisseur n'a pas reçu votre réponse 200 OK (coupure réseau), la tentative 3 enverra le même événement. Utilisez event_id pour détecter et ignorer les doublons.
Conseil production : PunchConnect relance les webhooks échoués pendant 24 heures et fournit un tableau de bord des webhooks où vous pouvez renvoyer manuellement les événements manqués.
Inscription des utilisateurs avec empreintes biométriques
Un défi courant : comment inscrire un utilisateur sur un appareil biométrique quand il n'est pas physiquement présent ? Les méthodes traditionnelles exigent que l'utilisateur se tienne devant l'appareil et pose son doigt plusieurs fois. Les API REST résolvent ce problème avec l'inscription à distance.
L'approche API REST
1. Capturer l'empreinte biométrique localement avec un scanner connecté à votre poste d'inscription
2. Encoder l'empreinte en chaîne base64
3. Envoyer l'empreinte à l'API via une requête POST
4. L'API pousse l'empreinte vers l'appareil — l'utilisateur est inscrit à distance, sans présence physique requise
Exemple de code : ajouter un utilisateur avec empreinte (Python)
import requests
import base64
API_KEY = "votre_cle_api"
BASE_URL = "https://api.punchconnect.com/v1"
# Capturer l'empreinte depuis le scanner local
# En production, utilisez le SDK de votre scanner pour obtenir les données brutes
empreinte_bytes = capturer_empreinte_scanner()
# Encoder en base64
template_b64 = base64.b64encode(empreinte_bytes).decode('utf-8')
# Envoyer à l'API
response = requests.post(
f"{BASE_URL}/users",
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
},
json={
"device_id": "DEVICE_12345",
"user_id": "EMP_001",
"name": "Jean Dupont",
"department": "Ingénierie",
"templates": [
{
"type": "fingerprint",
"data": template_b64,
"index": 0 # Premier doigt
},
{
"type": "fingerprint",
"data": capturer_deuxieme_doigt(),
"index": 1 # Doigt de secours
}
]
}
)
if response.status_code == 201:
print(f"Utilisateur {response.json()['user_id']} inscrit avec succès")
else:
print(f"Erreur : {response.json()['error']}")Éprouvé à grande échelle
PunchConnect utilise exactement cette approche pour alimenter AgriWise, un SIRH agricole gérant 24 000+ employés sur des exploitations distribuées. Le personnel RH inscrit les travailleurs dans les bureaux centraux avec des scanners d'empreintes, et les templates se synchronisent vers les appareils biométriques des sites distants en quelques secondes. Découvrez comment configurer les webhooks temps réel pour recevoir les données de pointage instantanément.
Considérations sur le format des empreintes
Les templates biométriques sont spécifiques au constructeur. Les appareils ZKTeco utilisent leur format propriétaire ; Suprema BioStar utilise un format différent. Privilégiez les API REST qui supportent les templates au standard ISO 19794-2 pour une portabilité maximale, ou vérifiez que l'API supporte le format du constructeur de vos appareils.
Gestion des erreurs et limites de débit
Les intégrations API REST en production doivent gérer les erreurs proprement et respecter les limites de débit pour éviter les interruptions de service.
Codes de statut HTTP courants
Comprendre les codes de statut HTTP est essentiel pour déboguer les intégrations API REST :
| Code | Signification | Action requise |
|------|--------------|----------------|
| 200 OK | Requête réussie | Traiter les données de réponse |
| 201 Created | Ressource créée (utilisateur ajouté, appareil enregistré) | Stocker l'ID de la nouvelle ressource |
| 400 Bad Request | Payload invalide (champ manquant, mauvais format) | Corriger le payload et réessayer |
| 401 Unauthorized | Clé API invalide ou manquante | Vérifier la clé API, la régénérer si nécessaire |
| 429 Too Many Requests | Limite de débit dépassée | Attendre et réessayer avec backoff exponentiel |
| 500 Internal Server Error | Problème côté fournisseur API | Réessayer avec backoff ; contacter le support si persistant |
Logique de retry avec backoff exponentiel
import requests
import time
def requete_api_avec_retry(url, headers, json_data, max_tentatives=5):
"""Requête API avec logique de retry et backoff exponentiel."""
for tentative in range(max_tentatives):
try:
response = requests.post(url, headers=headers, json=json_data, timeout=10)
if response.status_code == 200:
return response.json()
if response.status_code == 429:
# Limite de débit atteinte — attendre et réessayer
attente = 2 ** tentative # 1s, 2s, 4s, 8s, 16s
print(f"Limite de débit atteinte. Nouvelle tentative dans {attente} secondes...")
time.sleep(attente)
continue
if response.status_code >= 500:
# Erreur serveur — réessayer
attente = 2 ** tentative
print(f"Erreur serveur. Nouvelle tentative dans {attente} secondes...")
time.sleep(attente)
continue
# Erreur client (400, 401, 403) — ne pas réessayer
response.raise_for_status()
except requests.exceptions.Timeout:
attente = 2 ** tentative
print(f"Timeout. Nouvelle tentative dans {attente} secondes...")
time.sleep(attente)
raise Exception(f"Échec après {max_tentatives} tentatives")Limites de débit et traitement par lots
La plupart des API REST appliquent des limites de débit pour prévenir les abus :
- Limite standard : 100 requêtes par minute par clé API
- Limite en rafale : 10 requêtes par seconde
Bonne pratique : regroupez les opérations quand c'est possible. Au lieu de faire 50 requêtes individuelles POST /users, faites une seule requête avec un tableau de 50 utilisateurs :
Cela réduit les requêtes de 50 à 1, restant bien en dessous des limites de débit.
POST /v1/users/batch
{
"device_id": "DEVICE_12345",
"users": [
{ "user_id": "EMP_001", "name": "Jean Dupont", "templates": [...] },
{ "user_id": "EMP_002", "name": "Marie Martin", "templates": [...] },
...
]
}FAQ
Ai-je besoin d'une adresse IP fixe pour utiliser une API REST biométrique ?
Non. Les API cloud éliminent les barrières réseau complètement. L'appareil biométrique se connecte en sortant vers la passerelle cloud (HTTPS standard sur le port 443), et vous recevez les données de pointage via des webhooks envoyés à votre serveur. Pas de redirection de port, pas de VPN, pas d'exceptions pare-feu nécessaires côté appareil. C'est l'un des avantages majeurs par rapport aux intégrations SDK traditionnelles qui nécessitent un accès LAN et une IP fixe. Particulièrement pertinent pour les déploiements multi-sites en Afrique francophone où les connexions Internet sont souvent dynamiques.
Puis-je utiliser une API REST avec n'importe quelle marque d'appareil biométrique ?
Cela dépend du fournisseur d'API. Certaines API REST ne supportent que leur propre matériel ; d'autres supportent plusieurs marques. PunchConnect supporte les appareils ZKTeco et les fabricants compatibles (plus de 200 modèles). Vérifiez toujours la liste de compatibilité du fournisseur avant de vous engager. Recherchez les API qui supportent les protocoles de communication standard pour une couverture maximale. Si vous utilisez Odoo comme SIRH, les API REST offrent une intégration transparente sans VPN ni logiciel local.
Quelle est la différence entre une API REST et un SDK ?
Les SDK (Software Development Kits) sont des bibliothèques installées localement qui communiquent directement avec les appareils biométriques via le réseau local. Ils sont spécifiques à une plateforme (DLL Windows, .so Linux), nécessitent des connaissances en C++ ou C#, et ne fonctionnent que sur le réseau local. Les API REST sont des endpoints HTTP hébergés dans le cloud qui fonctionnent avec n'importe quel langage de programmation, depuis n'importe où, sans installation locale. Les API REST abstraient la communication avec les appareils, gèrent la complexité réseau et fournissent des webhooks pour les données en temps réel — ce qui les rend idéales pour les systèmes ERP et SIRH dans le cloud.
Comment sécuriser mes endpoints webhook ?
Suivez ces pratiques :
1. Vérification de signature HMAC : validez chaque webhook entrant avec des signatures HMAC-SHA256 (voir l'exemple de code dans la section Authentification)
2. HTTPS uniquement : n'exposez jamais vos endpoints webhook en HTTP non chiffré
3. Allowlisting IP : restreignez l'endpoint webhook aux requêtes provenant des plages IP du fournisseur API
4. Limitation de débit : implémentez une limitation de débit sur votre endpoint webhook pour prévenir les abus
5. Idempotence : stockez les valeurs event_id pour détecter et rejeter les événements en double
Comment les données biométriques sont-elles protégées au regard du RGPD ?
Les données biométriques sont classées comme données sensibles par le RGPD (Article 9). Pour être conforme : obtenez le consentement explicite et écrit de chaque employé avant l'inscription biométrique, documentez la finalité du traitement dans votre registre, offrez un moyen simple d'exercer le droit à l'effacement (DELETE /v1/users), et assurez-vous que les données sont hébergées dans l'UE ou dans un pays offrant un niveau de protection adéquat. PunchConnect propose des instances hébergées en France et en Allemagne pour les clients soumis au RGPD.
Que se passe-t-il si mon endpoint webhook est hors ligne ?
Les fournisseurs d'API fiables relancent la livraison des webhooks avec un backoff exponentiel. PunchConnect relance les webhooks échoués pendant 24 heures avec des intervalles croissants. Une fois votre serveur rétabli, les événements manqués seront livrés automatiquement. Pour les pannes plus longues, utilisez l'endpoint GET /logs de l'API pour récupérer l'historique des pointages et combler les lacunes. Implémentez toujours des vérifications d'idempotence (stockage des event_id) pour éviter de traiter des événements en double lors de la reprise.
Conclusion
Les API REST pour appareils biométriques modernisent les intégrations de pointage et de contrôle d'accès en éliminant la complexité des SDK, les contraintes d'IP fixe et les délais de polling. Au lieu de se battre avec des SDK spécifiques à une plateforme et des configurations pare-feu, votre application envoie des requêtes HTTP standard et reçoit des événements webhook en temps réel.
Points clés :
- Utilisez les clés API pour l'authentification serveur à serveur ; vérifiez les webhooks avec des signatures HMAC
- Gérez les webhooks avec des vérifications d'idempotence et des retries en backoff exponentiel
- Regroupez les opérations pour respecter les limites de débit (une requête avec 50 utilisateurs vs 50 requêtes)
- L'inscription à distance fonctionne à grande échelle : 24 000+ employés sur AgriWise
- Utilisez toujours HTTPS et stockez les clés API dans des variables d'environnement
- Conformité RGPD : consentement explicite, droit à l'effacement, hébergement UE
Pourquoi PunchConnect :
- Éprouvé en production : propulse AgriWise avec 24 000+ employés sur des sites distribués
- Configuration en 5 minutes : enregistrez votre appareil, obtenez une clé API, commencez à recevoir les données en temps réel
- Webhooks temps réel : latence <100 ms, disponibilité 99,5%, retry automatique pendant 24 heures
- Pas d'IP fixe nécessaire : les appareils se connectent en sortant ; vous recevez les données via webhooks
- Conforme RGPD : hébergement EU disponible, suppression complète des données sur demande
- Tarification transparente : 200 $/appareil unique, 50 $/an renouvellement — sans frais cachés
Prêt à connecter vos appareils biométriques sans la complexité des SDK ? Essayez PunchConnect gratuitement pendant 7 jours — sans carte bancaire. Connectez votre premier appareil en moins de 5 minutes et commencez à recevoir les données de pointage en temps réel via webhooks.
Comment ça fonctionne
1. L'appareil enregistre le pointage → L'employé pose son doigt sur le scanner ou présente son visage
2. La passerelle cloud capture l'événement → L'appareil communique avec la passerelle du fournisseur API (invisible pour l'utilisateur)
3. La passerelle envoie un POST à votre URL webhook → Votre serveur reçoit le payload JSON
4. Votre serveur traite et répond → Insertion en base, déclenchement de workflows, réponse
200 OK