Vue d'ensemble de l'API
Comprendre ce qui est déjà documenté pour l'API OmniLab et par où commencer avant la publication de la référence complète.
Cette page reste volontairement légère tant que la référence API complète, ressource par ressource, est en cours de consolidation. Aujourd'hui, les principaux points d'entrée développeur publics sont l'authentification, l'accès booking, les webhooks, et les patterns d'embarqué.
À quoi sert la surface développeur actuelle
- authentification server-to-server via client credentials
- expériences self-service autour du booking, comme la consultation ou l'annulation des réservations d'un participant
- intégrations événementielles via webhooks
- intégrations spécifiques à un tenant préparées avec les équipes OmniLab
Ce qui n'est pas encore publié
La référence REST complète, ressource par ressource, n'est pas encore publiée dans ce help center. N'assumez donc pas que chaque endpoint interne OmniLab fait partie de la surface externe supportée.
Traitez l'API comme une surface approuvée, pas comme un terrain d'exploration
Utilisez uniquement les endpoints et les flux explicitement confirmés pour votre tenant. Si vous avez besoin d'une couverture plus large, alignez-vous avec l'équipe OmniLab avant de démarrer le développement.
Parcours recommandé pour commencer
- Lire Authentification.
- Noter les URLs de base de production et de staging avant d'écrire du code.
- Construire le premier cas d'usage sur staging.
- Préférer les webhooks à un polling agressif lorsqu'un autre système a besoin de mises à jour rapides.
- Garder les zones non supportées ou pas encore publiées derrière un feature flag côté intégrateur.
Pour aller plus loin
Authentification
Demander et réutiliser un token machine-to-machine.
URLs de base et environnements
Séparer les URLs, credentials, et callbacks selon l'environnement.
Patterns d'intégration courants
Partir des patterns booking, CRM, et analytics les plus fréquents.
Référence API
Voir l'état de la future référence ressource par ressource.