Éditeurs partenaires

Vous éditez un logiciel de gestion scolaire, et vos clients sont des établissements. Ce guide s'adresse à vous : il explique comment ouvrir un établissement MeetingHub pour chacun d'eux, brancher votre logiciel sur son emploi du temps et ses feuilles de présence, et faire entrer ses apprenants dans les cours sans quitter votre application.

Une clé d'éditeur partenaire

L'exploitant du service vous remet une clé qui commence par mhp_. Elle ouvre la même porte que toutes les autres, /api, et se présente de la même façon :

Authorization: Bearer mhp_Q3x9LmPa_…

Gardez-la sur votre serveur. Elle permet d'ouvrir des établissements à votre nom : elle ne doit jamais arriver dans un navigateur.

Elle vous ouvre les établissements que vous avez ouverts, et eux seuls : un autre répond 404, comme s'il n'existait pas. Commencez par GET /api/me : la réponse liste vos établissements, et ce que la clé vous permet d'y faire.

Les données des apprenants

Votre clé d'éditeur ne rend aucune donnée personnelle d'apprenant : ni nom, ni adresse, ni présence nominative. La mesure d'usage compte, elle ne nomme pas.

Les clés d'établissement que vous posez suivent la même règle par défaut : elles ne peuvent ni lire les feuilles de présence nominatives (attendance:read), ni déposer de listes d'inscrits (roster:write). L'exploitant lève cette restriction pour vous une fois l'accord de sous-traitance signé. Jusque-là, une demande qui les contient est refusée en 403 ; et si l'accord vous est retiré, vos clés perdent ces deux portées dès leur requête suivante.

En six étapes

1. Ouvrir un établissement. POST /api/institutions, avec le courriel de son premier responsable : il en devient le Promoteur, et reçoit un lien d'activation pour choisir son mot de passe — aujourd'hui, c'est vous qui le lui transmettez, la réponse le rend dans admin.link. Commencez par un établissement d'essai ("sandbox": true) : ses salles sont bornées à 10 personnes, le reste est identique. Gardez l'id de la réponse : c'est le :institutionId des adresses suivantes.
2. Déclarer ses centres. POST /api/institutions/:institutionId/centres, un appel par centre ou campus.
3. Poser une clé d'établissement. POST /api/institutions/:institutionId/keys. La clé mhk_… est rendue une seule fois. C'est elle que votre logiciel utilise ensuite, sur le même /api, pour l'emploi du temps, les listes d'inscrits et les feuilles de présence de cet établissement : voir Déposer l'emploi du temps.
4. Poser vos webhooks. POST /api/partner/webhooks : un webhook vaut pour tous vos établissements, y compris ceux que vous ouvrirez ensuite. Voir Webhooks pour la signature et les réessais.
5. Faire entrer les apprenants. Voir Intégrer une salle.
6. Mesurer l'usage. GET /api/partner/usage?month=2026-10 rend, par établissement, ce qu'il a consommé : de quoi facturer vos clients.

Intégrer une salle

Au moment où la personne clique « rejoindre le cours » dans votre application, votre serveur demande un lien d'entrée :

POST /api/institutions/:institutionId/entries
{ "room": "ABCD2345", "displayName": "Awa Ngono" 
}

La réponse contient une adresse, à ouvrir dans une iframe :

<iframe src="https://reunion.exemple.cm/app/?room=ABCD2345&entree=…"
        allow="camera; microphone; display-capture; fullscreen"
        style="width: 100%; height: 100%; border: 0"></iframe>

• Le lien vaut pour cette salle, deux heures par défaut, douze au plus. Il remplace la connexion : dans une iframe, le cookie de session ne part pas.
• Le nom affiché est celui que vous signez ; la personne ne peut pas le changer.
• Le lien tient lieu de politique d'entrée et de mot de passe. L'horaire du cours, le verrou, la salle d'attente et les exclusions s'appliquent.
• "host": true fait entrer la personne comme animateur.
• La page ne se laisse encadrer que par les origines que l'exploitant a enregistrées pour vous. Donnez-lui les vôtres avant le premier essai : sans elles, la demande de lien est refusée en 409.

Si l'exploitant a enregistré votre marque, la salle prend votre nom et votre couleur.

Si vous utilisiez /api/partner

Les anciennes adresses /api/partner/… répondent encore, comme alias dépréciés de /api : chaque réponse porte l'en-tête Deprecation: true et un en-tête Link vers la route qui la remplace. Elles rendent déjà les réponses de /api — institutions et non plus organisations, centres et non plus sites. Elles disparaîtront à la prochaine version : la table de correspondance est dans la référence.

Et ensuite

La référence des éditeurs partenaires décrit chaque route, chaque champ et chaque refus. La collection Postman meetinghub-integrateur.postman_collection.json reprend toutes les routes qu'une clé d'éditeur atteint, prêtes à l'emploi.