Aller au contenu principal
Version: 0.2.2

L'API Openbeehive

Openbeehive est API-first et ouvert. Il n'y a pas de backend caché : tout ce que fait l'application — créer des ruchers, enregistrer des inspections, synchroniser des appareils, lire des statistiques — passe par une seule API Connect-RPC publique. Le même contrat qui alimente l'application est disponible pour vous.

Cette ouverture est délibérée. Vos données vous appartiennent ; vous devez donc pouvoir les lire, les scripter, les alimenter depuis vos propres capteurs et les déplacer ailleurs sans demander la permission à qui que ce soit.

Un contrat, deux protocoles

L'API est définie une seule fois sous forme de contrat Protocol Buffers et servie avec Connect-RPC. Cela signifie que chaque endpoint est accessible de deux façons, depuis la même URL :

StyleIdéal pourPage
HTTP + JSON (de type REST)curl, scripts, webhooks, microcontrôleurs, intégrations rapidesREST / HTTP + JSON
gRPC / gRPC-Web / Connectclients typés, streaming, synchronisation à haut volumegRPC

Vous ne choisissez pas un protocole côté serveur — vous le choisissez par requête, grâce aux en-têtes que vous envoyez. Optez pour celui qui est le plus facile pour votre outil.

URL de base

L'API est servie par le même processus que celui qui sert l'application :

  • Service hébergé : https://app.openbeehive.org
  • Auto-hébergé : votre propre origine, par exemple https://bees.example.com (voir Auto-hébergement)

Chaque méthode se trouve à un chemin prévisible :

POST <base-url>/openbeehive.v1.<Service>/<Method>

Par exemple : https://app.openbeehive.org/openbeehive.v1.ApiaryService/ListApiaries.

Services

Le contrat est regroupé en services. Chacun correspond à une partie du domaine que vous connaissez déjà depuis l'application :

ServiceCe qu'il couvre
ApiaryServiceCréer, lire, mettre à jour, supprimer et lister les ruchers
HiveServiceLes ruches, y compris le déplacement d'une ruche entre ruchers
QueenServiceLes reines et l'historique de leur règne
InspectionServiceInspections / visites (température et humidité incluses), URL d'envoi de photos
TreatmentServiceTraitements / le Bestandsbuch (produit, lot, dose, délai d'attente)
TaskServiceTâches et rappels
EventServiceLe flux d'événements / historique en ajout seul
StatsServiceTotaux du tableau de bord et statistiques de miel
SyncServicePull, Push et un Subscribe en streaming — le moteur de synchronisation offline-first

:::note Statut d'implémentation (v0.1.0) ApiaryService et SyncService sont aujourd'hui entièrement câblés côté serveur. Les autres services sont définis dans le contrat et suivent la même forme ; ils sont en cours de remplissage. Consultez le contrat pour la source de vérité actuelle, et les notes de version pour savoir ce qui est en service. :::

Authentification

  • Auto-hébergé, utilisateur unique : lorsqu'aucune connexion n'est configurée, l'API est ouverte à l'instance (vous êtes le seul utilisateur). C'est la configuration la plus simple pour les serveurs domestiques et les scripts. Voir Authentification.
  • Avec la connexion activée / le service hébergé : les requêtes portent une session établie via OIDC ou une clé d'accès (passkey). Envoyez-la sous forme de jeton bearer : Authorization: Bearer <token>. Les jetons d'API programmatiques pour les clients sans surveillance (scripts, capteurs) sont prévus dans la feuille de route — d'ici là, l'auto-hébergement en mode utilisateur unique est la voie sans friction pour l'automatisation.

Comment l'application elle-même l'utilise

L'application est offline-first : elle écrit d'abord dans une base de données locale et le moteur de synchronisation se réconcilie avec le serveur via SyncService.Push / Pull. Les services CRUD (ApiaryService, InspectionService, …) sont les points d'entrée faisant autorité côté serveur, utilisés pour les intégrations directes, l'export et l'automatisation. Les deux vues reposent sur les mêmes données — voir Mode hors ligne et synchronisation et l'architecture pour développeurs.

Ce que vous pouvez construire

  • Récupérer vos données dans un tableur, un notebook ou un tableau de bord BI.
  • Scripter des modifications groupées ou des migrations depuis un autre outil apicole.
  • Alimenter les relevés provenant de trackers automatisés — balances de ruches, capteurs de température et d'humidité — directement dans les inspections. Voir Trackers automatisés.
  • Construire votre propre client, bot ou widget mobile à partir d'un contrat stable et typé.

Prêt pour les détails ? Commencez par REST / HTTP + JSON.