Hermetry propose trois moyens pour que vos propres systèmes fonctionnent avec votre organisation, ainsi qu’une API distincte pour les appareils. Cette section couvre les trois premiers.
| Interface | Sens | Qui l’utilise | Connexion |
|---|---|---|---|
| API REST de gestion | Votre système appelle Hermetry | ERP, MES, systèmes de tickets, scripts, rapports | Clé d’API |
| Webhooks | Hermetry appelle votre système | Tout ce qui doit réagir à des événements : un appareil qui passe hors ligne, une alarme qui s’ouvre, une commande qui se termine | Un secret de signature que vous vérifiez |
| Serveurs MCP | Un assistant IA appelle Hermetry | Assistants IA compatibles avec MCP | Clé d’API ou connexion (OAuth) |
| API pour appareils | Les appareils envoient des données et reçoivent des commandes | Appareils et passerelles | Jeton d’appareil, nom d’utilisateur et mot de passe MQTT, ou certificat |
L’API pour appareils est documentée avec les appareils : MQTT, API HTTP pour appareils et Topics et charges utiles MQTT. N’utilisez pas de clé d’API sur un appareil, et n’utilisez pas de jeton d’appareil dans une intégration.
Ce que vous pouvez faire avec l’API de gestion
Avec une clé d’API, vous pouvez faire depuis du code tout ce qu’un membre peut faire dans l’application, dans les limites des permissions que vous accordez à la clé :
- lister, créer, modifier et supprimer des appareils et des profils d’appareils, et renouveler les identifiants des appareils,
- lire et écrire des attributs, lire les dernières valeurs et l’historique de la télémétrie,
- envoyer des commandes aux appareils et lire leurs résultats,
- lister, acquitter et résoudre des alarmes, et remplacer les règles d’alarme d’un profil,
- construire et lire l’arborescence des sites et des actifs, et y placer des appareils,
- enregistrer des micrologiciels, lancer des déploiements et modifier les réglages des appareils,
- gérer les passerelles et les appareils LoRaWAN.
L’API REST ne dispose d’aucune route pour écrire de la télémétrie. Les mesures proviennent des appareils (MQTT ou HTTP) ou des flux.
Un premier appel
- Ouvrez API Keys et créez une clé avec le préréglage Read only du module devices. Voir Authentification.
- Retrouvez l’identifiant de votre organisation (
tenantId) dans la barre d’adresse de l’application :https://<your host>/tenant/<tenantId>/admin/.... - Appelez la liste des appareils :
curl -s "https://<your host>/tenant/<tenantId>/api/iot/devices?pageSize=5" \
-H "Authorization: Bearer sk_live_…"La réponse est { "devices": [...], "total": 42 }.
Dans cette section
Pour bien démarrer :
- Authentification : clés d’API, permissions, réseaux, expiration, rotation.
- Bases de l’API REST : chemins, listes, pagination, tri, filtres et conventions.
- Erreurs et limites de débit : le corps d’erreur, chaque code de statut et les limites qui renvoient
429.
Références des routes :
- API des appareils et des profils
- API de télémétrie et d’attributs
- API des commandes
- API des alarmes
- API des sites et des actifs
- API des micrologiciels et des réglages des appareils
- API LoRaWAN
Événements :
- Webhooks : créer, signer, relancer, tester.
- Référence des événements webhook : chaque événement IoT avec un exemple de charge utile.
Assistants IA :
- Assistants IA (MCP) : ce qu’un assistant peut faire et ce qu’il ne peut jamais faire.
- Connecter un assistant IA
- Clés MCP et applications connectées
- Référence des outils MCP
- Réglages et sécurité MCP
Avant de construire une intégration
- Donnez à chaque intégration sa propre clé, avec uniquement les permissions dont elle a besoin. Voir Durcissement des clés d’API.
- Attendez-vous à recevoir
429et respectezRetry-After. - Traitez les identifiants comme des UUID opaques. Ne les construisez jamais vous-même.
- Privilégiez les webhooks au polling pour suivre les changements : la connexion d’un appareil, une alarme, le résultat d’une commande.
- Les clés d’API et les webhooks sont gérés par les administrateurs. La rotation du secret de signature d’un webhook nécessite le rôle Owner.