Authentification

Chaque requête API doit porter un identifiant bearer dans l’en-tête Authorization. Deux types d’identifiants existent, avec les mêmes scopes et la même isolation par utilisateur :

• les clés API pour vos propres scripts, serveurs et intégrations ;
• les jetons d’accès OAuth 2.1 pour les applications agissant au nom d’autres utilisateurs Meetingize (assistants IA via le serveur MCP, applications tierces).

Authorization: Bearer mtgz_live_k7Hq2x9a_3bV...

Clés API

Créez des clés dans l’application web, Settings > Developers > Create a key. Les clés ne sont jamais créées ni révoquées via l’API elle-même.

• Format : mtgz_live_<id8>_<secret32>.
• La clé complète est affichée une seule fois. Meetingize ne conserve qu’un hash SHA-256 de celle-ci, plus le préfixe (mtgz_live_k7Hq2x9a) et les 4 derniers caractères pour l’affichage.
• Chaque clé a un nom, des scopes, une date d’expiration optionnelle, une date et une IP de « dernière utilisation », et peut être révoquée à tout moment. La révocation est immédiate.
• Traitez les clés comme des mots de passe : conservez-les côté serveur, dans un gestionnaire de secrets ou une variable d’environnement, jamais dans un navigateur ou une application mobile.

Scopes

Scope	Autorise
read:meetings	lister et rechercher des réunions, détails, compte rendu IA, participants, modèles, personas
read:transcripts	transcriptions (json, md, txt, srt, vtt) ; avec read:meetings, l’export prêt pour LLM
read:documents	lister et télécharger les documents générés (json, md, pdf, docx)
write:documents	générer des documents (jobs asynchrones, facturés à l’usage)
write:meetings	créer des réunions à partir de fichiers audio ou vidéo ou d’URL (facturé à l’usage), mettre à jour leur titre, date, tags et participants, les supprimer
webhooks	gérer les endpoints webhook via l’API, envoyer des tests, lire le journal de livraison
read:usage	consommation actuelle, portefeuille et grand livre

GET /me et GET /jobs fonctionnent avec n’importe quel identifiant valide (un job n’est visible que par son propriétaire). Un appel sans le scope requis répond 403 insufficient_scope.

OAuth 2.1

Meetingize est un serveur d’autorisation OAuth 2.1. C’est ce qu’utilisent les assistants IA lorsque vous connectez le serveur MCP, et toute application peut l’utiliser pour agir au nom d’un utilisateur Meetingize avec son consentement explicite.

Élément	Valeur
Découverte (RFC 8414)	https://app.meetingize.com/.well-known/oauth-authorization-server
Métadonnées de ressource protégée (RFC 9728)	https://app.meetingize.com/.well-known/oauth-protected-resource/api/mcp
Endpoint d’autorisation	https://app.meetingize.com/api/oauth/authorize
Endpoint de jeton	https://app.meetingize.com/api/oauth/token
Enregistrement dynamique de client (RFC 7591)	https://app.meetingize.com/api/oauth/register
Révocation (RFC 7009)	https://app.meetingize.com/api/oauth/revoke
Types de grant	authorization_code (avec PKCE), refresh_token
PKCE	requis, S256 uniquement
Authentification client	none (clients publics), client_secret_post, client_secret_basic
Client ID Metadata Documents	pris en charge : une URL https:// peut être utilisée comme client_id
Durée de vie du jeton d’accès	1 heure, jetons de rafraîchissement 30 jours avec rotation

Déroulement

1. Enregistrez votre client une fois (ou utilisez un Client ID Metadata Document) :

   curl -s -X POST https://app.meetingize.com/api/oauth/register \
     -H "Content-Type: application/json" \
     -d '{"client_name": "My CRM sync", "redirect_uris": ["https://crm.example.com/oauth/callback"],
          "grant_types": ["authorization_code", "refresh_token"], "token_endpoint_auth_method": "none"}'

   Les URI de redirection doivent être en https, en http sur une adresse loopback (localhost, 127.0.0.1) pour les applications natives, ou un schéma à usage privé (myapp://...).

2. Redirigez l’utilisateur vers l’endpoint d’autorisation avec response_type=code, votre client_id, redirect_uri, scope, state, code_challenge (S256) et éventuellement resource. L’utilisateur se connecte à Meetingize si besoin, voit un écran de consentement listant les permissions demandées, et autorise ou refuse.

3. Échangez le code sur l’endpoint de jeton avec le code_verifier :

   curl -s -X POST https://app.meetingize.com/api/oauth/token \
     -d grant_type=authorization_code -d code=... -d redirect_uri=https://crm.example.com/oauth/callback \
     -d client_id=... -d code_verifier=...

4. Appelez l’API avec Authorization: Bearer <access_token> et rafraîchissez-le avec grant_type=refresh_token avant son expiration.

Le paramètre resource (RFC 8707) est accepté pour l’URL du serveur MCP (https://app.meetingize.com/api/mcp) et l’URL de base de l’API ; toute autre valeur est refusée avec invalid_target.

Ce que l’utilisateur contrôle

Les utilisateurs voient chaque application connectée dans Settings > Connected applications, avec les permissions accordées et la dernière utilisation, et peuvent déconnecter n’importe laquelle d’entre elles. La déconnexion révoque immédiatement les jetons d’accès et de rafraîchissement.

Erreurs

Statut	code	Signification
401	missing_credentials	pas d’en-tête Authorization
401	invalid_api_key, invalid_token	identifiant inconnu, malformé ou expiré
401	api_key_revoked, api_key_expired	la clé a été révoquée ou a atteint sa date d’expiration
403	insufficient_scope	l’identifiant n’a pas le scope requis par l’endpoint