Meet pour les développeurs

L’API REST, les clés et les webhooks sont en lecture seule : rien n’y crée, n’y modifie ni n’y supprime une réunion, un compte rendu ou une action. Une clé ne lit que les réunions dont son propriétaire est propriétaire, hors corbeille ; jamais celles que d’autres membres partagent avec ses équipes.

Les clés d’API

Une clé se crée dans Développeurs › Clés, avec un nom et au moins une permission. Sa valeur s’affiche une seule fois, juste après la création. Elle a la forme rmk_ suivi d’un identifiant public de huit caractères, d’un _ et d’un secret ; seule son empreinte est gardée. Elle se révoque à tout moment, définitivement. Un compte a 20 clés actives au plus.

L’API REST

Adresse de base : https://meet.escouade.io/v1. Authentification : Authorization: Bearer rmk_…. Réponses en JSON, dates en RFC 3339 (UTC). Toute méthode autre que GET reçoit 405. L’API n’envoie pas d’en-têtes CORS : elle s’appelle depuis un serveur, jamais depuis une page web, où une clé ne doit pas vivre.

curl -s https://meet.escouade.io/v1/meetings?limit=5 \
  -H 'Authorization: Bearer rmk_…'

Liste et pagination

GET /v1/meetings rend les réunions les plus récentes d’abord. Paramètres : limit (1 à 100, 20 par défaut), cursor (la valeur next_cursor de la page précédente, telle quelle), status (un statut ci-dessous). next_cursor vaut null à la dernière page.

Une réunion

Jamais : le lien de visio, un chemin de fichier, un identifiant technique interne.

Les statuts

Compte rendu, actions, transcription

• Compte rendu : meeting_id, template, summary, key_points, decisions, open_questions (chacun {"text", "source_seconds"}), chapters ({"title", "summary", "source_seconds"}). Pas encore de compte rendu : 404 not_ready.
• Action : id (clé stable), title, assignee, due (texte libre tel que dit, peut être null), completed, source_seconds.
• Transcription : segments de {"start", "end", "speaker", "text"}, en secondes ; speaker vaut null quand l’intervenant n’est pas connu.

Erreurs et limites

Corps d’erreur : {"error": {"code": "…", "message": "…"}} ; pour un 403, required_scope en plus.

Les webhooks

Les destinations se gèrent dans Développeurs › Webhooks : une adresse HTTPS joignable sur Internet, les événements choisis, 10 destinations au plus par compte.

Le corps ne porte que l’essentiel ; le titre et le contenu se lisent ensuite par l’API, avec une clé :

{"id": "evt_…", "type": "meeting.report_ready", "created_at": "2026-10-20T09:41:07Z",
 "data": {"meeting_id": "…", "status": "report_ready"}}

Vérifier la signature

Les en-têtes suivent la convention Standard Webhooks :

• webhook-id : l’identifiant de l’événement, le même à chaque nouvel essai ;
• webhook-timestamp : l’instant, en secondes Unix ;
• webhook-signature : v1, suivi du HMAC-SHA256, en base64, de {webhook-id}.{webhook-timestamp}.{corps}, avec pour clé le secret whsec_… sans son préfixe, décodé du base64.

Vérifiez en temps constant, refusez un horodatage écarté de plus de 5 minutes, ignorez un webhook-id déjà traité. Le secret s’affiche une fois, à la création de la destination.

import base64, hashlib, hmac, time

def verifier(secret, entetes, corps):
    cle = base64.b64decode(secret.removeprefix("whsec_"))
    message = "%s.%s.%s" % (entetes["webhook-id"], entetes["webhook-timestamp"], corps)
    attendu = base64.b64encode(hmac.new(cle, message.encode(), hashlib.sha256).digest()).decode()
    if abs(time.time() - int(entetes["webhook-timestamp"])) > 300:
        return False
    return any(hmac.compare_digest("v1," + attendu, s) for s in entetes["webhook-signature"].split())

La livraison

Votre point d’arrivée répond 2xx en 10 secondes au plus. Sinon, un nouvel essai part après 30 s, 2 min, 10 min, 30 min, 1 h, 3 h puis 6 h : 8 essais au plus, puis l’événement est marqué abandonné. Un événement livré ou abandonné se renvoie depuis la page, avec le même identifiant. Aucune redirection n’est suivie. Une destination en pause accumule ses événements, qui partent à la reprise.

Le serveur MCP

Adresse : https://meet.escouade.io/mcp, en Streamable HTTP, sans session. Un assistant s’y connecte par OAuth, avec la seule adresse ; un programme, avec une clé rmk_… en Authorization: Bearer.

Vingt et un outils : onze lisent, cinq préparent une action et cinq sont réservés aux vues de l’assistant.

Préparer, puis confirmer

Un assistant connecté par OAuth peut préparer une action ; elle n’est faite qu’une fois confirmée par la personne, dans la vue de l’assistant ou sur une page de Meet. Jamais par une clé d’API, jamais par l’API REST.

Une action préparée attend 10 minutes. Ce qui sort de Meet sans retour possible (un e-mail envoyé, le robot envoyé par un lien collé) ne se confirme que sur la page de Meet. Aucune suppression, aucun paiement, aucun envoi de transcription ou d’enregistrement par ce chemin.

L’autorisation OAuth

Meet suit la partie autorisation de la spécification MCP : OAuth 2.1, clients publics, PKCE S256 obligatoire, enregistrement dynamique et documents de métadonnées de client. La page de consentement liste les permissions en deux groupes, Lire et Agir ; seules les quatre lectures des réunions sont cochées d’office, rien de ce qui agit. Le jeton d’accès vaut une heure et se renouvelle ; Développeurs › Serveur MCP liste les assistants connectés, avec « Révoquer ».

Brancher l’assistant

• Claude : Paramètres › Connecteurs › « Ajouter un connecteur personnalisé », nom « Escouade Meet », adresse https://meet.escouade.io/mcp ; « Se connecter », puis votre compte Escouade, les permissions, « Autoriser ».
• ChatGPT : en mode développeur, un connecteur avec la même adresse et l’authentification OAuth.
• Claude Code :

claude mcp add --transport http escouade-meet https://meet.escouade.io/mcp

Un connecteur déjà branché sur https://robotmeet.fr/mcp continue de fonctionner ; passer à la nouvelle adresse, c’est le rebrancher, puis révoquer l’ancien.